In our app we have sending and receiving pipeline (GStreamer-based) and sometimes after mulitple pipeline re-launches (especially when there are multiple received videos) the GStremer output provides the following traces:
0:02:46.010920539 10814 0x7f440044a0 WARN videodecoder gstvideodecoder.c:3772:gst_video_decoder_negotiate_pool:<nvv4l2decoder22> Subclass failed to decide allocation
0:02:46.010944636 10814 0x7f440044a0 WARN videodecoder gstvideodecoder.c:1202:gst_video_decoder_sink_event_default:<nvv4l2decoder22> Failed to negotiate with downstream
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:
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.
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:
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?
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.
#!/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 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?
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.