mavlink
RTSP Videosteam not displaying (Could not create a buffer big enough)
Expected Behavior
RTSP Videosteam is displayed
Current Behavior
Video steam window is flashing with ~1Hz
Problem:
the stream is correctly generated is is able to be streamed with following command:
gst-launch-1.0 rtspsrc location=rtsp://192.168.12.77:8553/stream ! rtph264depay ! h264parse ! avdec_h264 ! autovideosink
if i run the command QGC uses:
gst-launch-1.0 rtspsrc location=rtsp://192.168.12.77:8553/stream latency=17 udp-reconnect=1 timeout=5000000
i get:
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc1: Internal data stream error
full debug info:
GST_DEBUG=2 gst-launch-1.0 rtspsrc location=rtsp://192.168.12.77:8553/stream latency=17 udp-reconnect=1 timeout=5000000
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Pipeline is PREROLLED ...
Prerolled, waiting for progress to finish...
Progress: (connect) Connecting to rtsp://192.168.12.77:8553/stream
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
0:00:00.804016471 32382 0x62c686609060 WARN udpsrc gstudpsrc.c:1637:gst_udpsrc_open:<udpsrc0> warning: Could not create a buffer of requested 524288 bytes (Operation not permitted). Need net.admin privilege?
0:00:00.804039943 32382 0x62c686609060 WARN udpsrc gstudpsrc.c:1647:gst_udpsrc_open:<udpsrc0> have udp buffer of 212992 bytes while 524288 were requested
Progress: (request) SETUP stream 0
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
Redistribute latency...
Progress: (request) Sending PLAY request
Redistribute latency...
Progress: (request) Sent PLAY request
Redistribute latency...
0:00:00.908839767 32382 0x7c36d8029de0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<udpsrc0> error: Internal data stream error.
0:00:00.908852557 32382 0x7c36d8029de0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<udpsrc0> error: streaming stopped, reason not-linked (-1)
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc0:
streaming stopped, reason not-linked (-1)
Execution ended after 0:00:00.085995602
Setting pipeline to NULL ...
0:00:00.909215360 32382 0x62c686609060 WARN default gstrtspconnection.c:1362:writev_bytes: Operation was cancelled
0:00:00.909241316 32382 0x62c686609060 WARN rtspsrc gstrtspsrc.c:6607:gst_rtspsrc_try_send:<rtspsrc0> error: Could not send message. (Received end-of-file)
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not write to resource.
Additional debug info:
../gst/rtsp/gstrtspsrc.c(6607): gst_rtspsrc_try_send (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
Could not send message. (Received end-of-file)
0:00:00.909277564 32382 0x62c686609060 WARN rtspsrc gstrtspsrc.c:9034:gst_rtspsrc_pause:<rtspsrc0> error: Could not send message. (Received end-of-file)
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not write to resource.
Additional debug info:
../gst/rtsp/gstrtspsrc.c(9034): gst_rtspsrc_pause (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
Could not send message. (Received end-of-file)
Freeing pipeline ...
So I assume the problem is that it requests a bigger buffer than it is allowed to. Is there a way to fix this?
Additional info:
OS: Ubuntu 22.04 The problem persists on two different machines.
@DonLakeFlyer @zdanek I think I may have also encountered this issue on a Samsung Tablet
@Claudio-Chies Out of curiosity does it work if you first start the stream and THEN boot the app? I've seen this as a (less than ideal) workaround for the time being
In my case it seems like I'm getting a bunch of GST_PAD_PROBE_TYPE_BUFFER push probes and then they stop and the watchdog timer gets thrown to stop the stream
@ben-draper-ascent no, neither if the stream is already started, or if i start it afterwards.
We switch from Ubuntu 22.04 20.04 on both the client and server side (where the stream is generated). This fixed the issue for me as it works there, but the underlying issue still persists. Should I close this issue?
