Please check this and share information:
nVidia encoder crash after several re-launches of the pipeline - #3 by DaneLLL
This can be reproduced with 4.6.1 also but much more rare than with 4.5
We would need your help to share a command(such as gst-launch-1.0) or sample so that we can set up and test to reproduce the issue.
This pipeline receives the data from the network (via
As an example may use reading from file encoded via H265:
gst-launch-1.0 -v filesrc location=/home/lena/sample.mp4 ! h265parse ! queue max-size-buffers=30 max-size-bytes=0 leaky=2 ! nvv4l2decoder ! nvvidconv ! 'video/x-raw(memory:NVMM),width=1920,height=1080' ! nvvidconv ! 'video/x-raw(memory:NVMM),format=RGBA' ! nvvidconv ! 'video/x-raw,format=RGBA' ! queue max-size-buffers=30 max-size-bytes=0 leaky=2 ! nv3dsink
Do you hit the issue in video streaming only? The command is to play local video file and if the file is good, it can be run successfully. In your use-case, it looks like the stream is broken so decoder cannot get information about the resolution and fails.
BTW, I have re-flashed my Xavier with JP 4.6 (previous time there were unmet dependencies, now everything is fine).
So now I sometimes - after many reconnections - receive another error:
NvRmChannelSubmit: NvError_IoctlFailed with error code 22 NvRmPrivFlush: NvRmChannelSubmit failed (err = 196623, SyncPointIdx = 32, SyncPointValue = 0) fence_set_name ioctl failed with 22 NvDdkVicExecute Failed nvbuffer_transform Failed gst_nvvconv_transform: NvBufferTransform Failed
The previous one looks to be gone.
UPD: reproduced that old issue once.
If you hit the issue in streaming, please apply this patch and rebuild libgstnvvideo4linux2.so for a try:
Jetson/L4T/r32.6.x patches - eLinux.org
[gstreamer]Memory leak in UDP streaming
We have seen the issue in UDP streaming. Not sure if you run UDP. It may be helpful in streaming cases. Please give it a try.
Is that patch for GStreamer 1.14?
I cannot file the corresponding source files.
Could you please share a link?
I tried with this patch.
Now I don’t have that errors any more but the issue still reproduces time to time but with less probability. The only error output it gives:
GStreamer-CRITICAL **: 16:37:52.803: gst_mini_object_unref: assertion 'mini_object != NULL' failed
Looks like it failed to create decoder but I have
GST_DEBUG variable set to
1,videodecoder:3,nvv4l2decoder:3,videoencoder:3,nvv4l2h265enc:3 and there’s nothing encoder or decoder-specific in the output.
The message looks to be warning instead of error. Is it possible the network is not stable ad decoder cannot get valid bitstream, triggering the issue?
I got proper output for this case.
NvRmChannelSubmit: NvError_IoctlFailed with error code 22 NvRmPrivFlush: NvRmChannelSubmit failed (err = 196623, SyncPointIdx = 31, SyncPointValue = 0)
Then for each failed video stream:
NvDdkVicExecute Failed nvbuffer_transform Failed gst_nvvconv_transform: NvBufferTransform Failed
fence_set_name ioctl failed with 22
And finally GStreamer produce several warnings:
fence_set_name ioctl failed with 22 0:02:33.243597680 13683 0x7f7801e540 WARN basesrc gstbasesrc.c:3055:gst_base_src_loop:<nvv4l2camerasrc10> error: Internal data stream error. 0:02:33.243677493 13683 0x7f7801e540 WARN basesrc gstbasesrc.c:3055:gst_base_src_loop:<nvv4l2camerasrc10> error: streaming stopped, reason error (-5) 0:02:33.244510051 13683 0x7f04082590 WARN v4l2allocator gstv4l2allocator.c:1511:gst_v4l2_allocator_dqbuf:<nvv4l2h265enc10:pool:src:allocator> V4L2 provided buffer has bytesused 0 which is too small to include data_offset 0 0:02:33.300546378 13683 0x7f78026a30 ERROR gstrtpfunnel gstrtpfunnel.c:139:gst_rtp_funnel_forward_segment:<rtpfunnel43> Could not push segment
I assume the GStreamer output is related to my video source element, not to the decoder. But as they occur after nVidia error traces they might be related.
UPDATE: it reproduces when there’s 3+ incoming video streams.
Can it be some issue with shared usage of some resource?
Also a GStreamer warning here:
v4l2bufferpool gstv4l2bufferpool.c:1512:gst_v4l2_buffer_pool_dqbuf:<nvv4l2decoder7:pool:src> Driver should never set v4l2_buffer.field to ANY
Here is a python sample for UDP streaming:
#!/usr/bin/env python3 import gi import time gi.require_version('Gst', '1.0') from gi.repository import Gst, GObject, GLib pipeline = None bus = None message = None # initialize GStreamer Gst.init(None) for i in range(1, 5566): print("loop =",i," ") # build the pipeline pipeline = Gst.parse_launch( "udpsrc port=5000 ! application/x-rtp,encoding-name=H264,media=video,clock-rate=90000 ! rtph264depay ! h264parse ! nvv4l2decoder ! nvvidconv ! video/x-raw,format=I420 ! fakesink " ) # start playing print("Switch to PLAYING state") pipeline.set_state(Gst.State.PLAYING) time.sleep(8) print("Send EoS") Gst.Element.send_event(pipeline, Gst.Event.new_eos()) # wait until EOS or error bus = pipeline.get_bus() msg = bus.timed_pop_filtered( Gst.CLOCK_TIME_NONE, Gst.MessageType.EOS) # free resources print("Switch to NULL state") pipeline.set_state(Gst.State.NULL) time.sleep(2)
Please modify the string in Gst.parse_launch() to fit your use-case and run the script to reproduce the failure. If you can run it to reproduce the issue, please share the string so that we can set up and try. Would need your help to provide steps in detail.
I modified Gst.parse_launch() with this pipeline:
udpsrc port=5000 ! application/x-rtp,encoding-name=H265,media=video,clock-rate=90000 ! rtph265depay ! h265parse disable-passthrough=TRUE config-interval=10 ! queue max-size-buffers=30 max-size-bytes=0 leaky=2 ! nvv4l2decoder drop-frame-interval=0 ! nvvidconv ! 'video/x-raw(memory:NVMM),width=1920,height=1080' ! nvvidconv right=1920 bottom=1080 ! 'video/x-raw(memory:NVMM),format=RGBA' ! nvvidconv ! 'video/x-raw,format=RGBA' ! queue max-size-buffers=30 max-size-bytes=0 leaky=2 ! fakesink
and I receive an error:
GLib.Error: gst_parse_error: syntax_error (0)
But I can run this pipeline using
gst-launch-1.0 without any issues
I managed to launch the pipeline using this python script. The only difference with our pipeline is
udpsrc element instead of taking the stream from
I launched 4 instances of this script and it looks fine, no error/crash after ~10 attempts.
Does it mean the issue is related to incoming stream?
Is the only difference in source element (
udpsrc instead of
webrtcbin with real video stream) makes the difference?
We don’t have much experience in using webrtcbin. This would need other users to share experience.
Not sure if it helps but you may try this:
NvMMDecNVMEDIACreateParser failed - #5 by DaneLLL
BTW, if use VP9 codec (which means parser is not needed) it looks more stable: still remote video is not received time to time but at least the app does not hang when stopping the pipeline.
And it looks more stable - less probability of video loss - when use only GStreamer elements.
So it looks like this issue is also encoder related, not only decoder.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.