Gstreamer pipeline not entering playing state with nvtee

I am having trouble working with the nvtee element. Using a regular tee, both branches work, Using an nvtee with a single branch, it works, Using an nvtee with two branches, neither work (but, the first branch should still work even if the second hasn’t started. Any thoughts as to why? There is nearly no documentation or examples for nvtee.

I understand that the branch of the nvtee from the “vid_src” branch will not play until receiving the “start recording” signal on the nvtee. But the branch attached to “pre-src” should run regardless.

I’m working in C (just so you know these aren’t gst-launch pipelines)

This works (nothing attached to the other branches of nvtee):

nvarguscamerasrc → capsfilter → nvtee
nvtee (pre-src) → queue → videorate → capsfilter → nvvidconv → capsfilter → nvjpegenc → jpegparse → appsink

This does not enter the playing state:

nvarguscamerasrc → capsfilter → nvtee
nvtee (pre-src) → queue → videorate → capsfilter → nvvidconv → capsfilter → nvjpegenc → jpegparse → appsink
nvtee (vid-src) → fakesink

This works (using regular tee, also has worked with a more complicated second branch):

nvarguscamerasrc → capsfilter → tee
tee → queue → videorate → capsfilter → nvvidconv → capsfilter → nvjpegenc → jpegparse → appsink
tee → fakesink

As mentioned, it appears the problem is that as soon as anything is attached to the vid-src branch of the nvtee, the branch attached to the pre-src is unable to enter the playing state.

However, this old pipeline (from a previous developer) does work (and the pre-src branch enters playing even if the vid-src has not yet been started):

nvarguscamerasrc → capsfilter → nvtee
nvtee (pre-src) → nvvidconv → capsfilter → omxh264enc → capsfilter → h264parse → mpegtsmux → hlssink
nvtee (vid-src) → nvvidconv → nvjpegenc → framerate → capsfilter → multifilesink

Please let me know any thoughts, thanks.

Hi,
Please use tee plugin if it works in your use-case. Generally we use tee in gst-launch-1.0. The nvtee plugin is specific to nvgstcapture app.

Hi,
I made some progress, I got the pipeline to run by setting the “async” property of the appsink element to false, though I don’t fully understand what impact this has.
We are using the nvtee so that we can have one branch (from pre-src) continuously running, while the other branch (from vid-src) can be turned on and off using the “start-capture” and “stop-capture” signals. What would you suggest as an alternative to this technique that could use the regular tee? Thanks,

Hi @scrawford,

It seems you have some synchronisation issues in the sinks. Do you need that vid-src saves all the buffers while it is “off”? If not, you may use a valve to drop all the buffers while in stop-capture and turn the valve “on” when using start-capture. If you need to save buffers, you may need to use queues with a large num-buffers and with a leaky criterion.

Regards,
Leon

Hi,
Thanks for your comment, I’m not familiar with the valve but will look into it.
In the meantime I remembered another question related to this: I want to keep processing in the GPU as much as possible, and am therefore using nv elements as much as possible such as nvvidconv, nvjpegenc instead of the generic gstreamer ones. Will the use of framerate or of tee cause memory copying from GPU to CPU or back? They’re not nvidia elements, but, they can sink and src video/x-raw(memory:NVMM) and are such basic operations that I hope they won’t have an impact.

Yes, tee and valve should work with NVMM memory buffers. For nvjpegenc, better have your video frames in NVMM memory with I420 format.

Hi,
As Honyey_Patouceul mentions, there is no extra memory copy in using tee.

If you use Jetpack4.5.1(r32.5.1) or later version, we have NVIDIA plugins open source. For further use-cases, you may check the source code and apply customization to rebuild the plugins. The source code is in
https://developer.nvidia.com/embedded/l4t/r32_release_v5.1/r32_release_v5.1/sources/t186/public_sources.tbz2