Hi,
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
Hi,
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 webrtcbin).
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
Hi,
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.
Hi,
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?
Hi,
The source code of gst-v4l2 is in
https://developer.nvidia.com/embedded/linux-tegra
L4T Driver Package (BSP) Sources
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.
Hi,
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.
First is:
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
Then once:
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
Hi,
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 webrtcbin.
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?
Hi,
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.