<div dir="ltr"><div>Hi Alan,</div><div><br></div><div>There's a lot of stuff here that I can't tell off the top of my head because I am not too well-versed with gst-rtsp-server, but I will point out that the Range request is specifically asking for a rewind to 0, so that's what the server is supposed to do in the case of shared media.</div><div><br></div><div>The server is supposed to add the current start/stop using an SDP attribute: a=range:npt=start-stop on DESCRIBE, so that the client can use that as the Range request. If the client wants to "join" playback, it should be requesting `Range: now-` or `Range: now-stop` or use the start from the SDP (best to use "now" to avoid an unwanted seek). However, this is usage-specific, so you should be editing the PLAY request in "before-send" to get the behaviour you require.</div><div><br></div><div><br></div><div>Sebastian (slomo / sdroege) is the expert, but in general, gst-rtsp-server has issues (some are easy to fix, but no one has gotten around to it, and others are harder / impossible to fix). Sebastian has actually been working on a new RTSP server written in Rust to replace it:</div><div><br></div><div><a href="https://github.com/sdroege/rtsp-server">https://github.com/sdroege/rtsp-server</a></div><div><br></div><div>It's not really ready for general use right now, since it doesn't have a gstreamer media factory implementation, but there's a TCP interleaved example, and maybe you can use that to customize things and get things working for your use-case:</div><div><br></div><div><a href="https://github.com/sdroege/rtsp-server/blob/master/examples/simple_server.rs">https://github.com/sdroege/rtsp-server/blob/master/examples/simple_server.rs</a></div><div><br></div><div><br></div><div>As for debug categories, you can look at GST_DEBUG=rtspsrc:6 for the client, and GST_DEBUG=rtsp*:6 for the server. You can generally find debug category names by searching for "GST_DEBUG_CATEGORY" in the sources. For instance:</div><div><br></div><div>GST_DEBUG_CATEGORY_INIT (rtsp_media_debug, "rtspmedia", 0, "GstRTSPMedia")</div><div><br></div><div>This is instantiating "rtspmedia" as the category name to use in the logs, and you can get messages specifically for that by doing GST_DEBUG=rtspmedia:6</div><div><br></div><div>Cheers,</div><div>Nirbheek<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 21, 2021 at 10:17 AM Alan <<a href="mailto:dartagnan64b@gmail.com">dartagnan64b@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
Nirbheek, thanks for replying. <br></div><div><br></div><div>I'm now setting gst_rtsp_media_set_shared(media, TRUE); in "media-configure" signal, not clear when
gst_rtsp_media_factory_set_shared(factory, TRUE) might be needed instead, in either case problems exist. <br></div><div><br></div><div>So when using
gst_rtsp_media_set_shared(media, TRUE) on rtsp server end, and hitting the server with 3 instances of gst-launch-1.0 rtspsrc location="rtsp://<a href="http://127.0.0.1:8554/test" target="_blank">127.0.0.1:8554/test</a>" protocols=4 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! autovideosink, I get one RTSP client pausing and one dropping out. Console logs showed: <br></div><div><br></div><div>rtsp client 2:</div><div>rtspsrc gstrtspsrc.c:3567:on_timeout_common:<rtspsrc0> source 651c0106, stream 651c0106 in session 0 timed out</div><div><br></div><div>rtsp client 3: <br></div><div>videodecoder gstvideodecoder.c:3302:gst_video_decoder_clip_and_push_buf:<avdec_h264-0> Dropping frame due to QoS. start:0:00:50.959420524 deadline:0:00:50.959420524 earliest_time:0:00:50.964597906</div><div><br></div><div>1) There seems to be a few bugs here. Are they filed and any plans of fixing these?</div><div><br></div><div>2) Any specific GST_DEBUG level to use and log lines to look for? (one can easily get lost in GST_DEBUG=5/6/or7</div><div><br></div><div>PS: all this is over TCP, gst_rtsp_media_factory_set_protocols(factory, GST_RTSP_LOWER_TRANS_TCP);, I've included RTSP handshake from VLC and gstreamer, only difference I see is that VLC uses "Range: npt=0.000-" in PLAY whereas gstreamer properly uses "Range: npt=0-598.733333333" since it parses start/end time. <br><br></div><div>Thank you! <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 13, 2021 at 6:50 AM Nirbheek Chauhan <<a href="mailto:nirbheek.chauhan@gmail.com" target="_blank">nirbheek.chauhan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Alan,<br>
<br>
You would need to look at the GST_DEBUG logs of gst-rtsp-server to<br>
figure out what RTSP commands are being sent on connect / disconnect<br>
by VLC and rtspsrc. If I remember correctly, VLC uses live555 which<br>
has a sub-par RTSP client implementation and it may just be doing the<br>
wrong thing. For instance, it may be sending a Range header in the<br>
PLAY request that forces the server to seek to the beginning of the<br>
file.<br>
<br>
As for rtspsrc, it actually sends a PAUSE request when stopping, so<br>
you need to intercept that using the "before-send" signal. See also:<br>
<a href="https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/908" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/908</a><br>
where I had to revert my attempt at fixing this. I am sure there are<br>
other bugs there too, but they should be fixable.<br>
<br>
You may also like to use gstreamer master for rtspsrc. There have been<br>
a number of fixes for shared RTSP playback and seeking there<br>
(multicast, udp, etc).<br>
<br>
Cheers,<br>
Nirbheek<br>
<br>
On Mon, Jul 12, 2021 at 12:15 PM Alan via gstreamer-devel<br>
<<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> I've been experimenting with the gst-rtsp-server test-launch.c example, I noticed that gst_rtsp_media_factory_set_shared(factory, TRUE) is not working as expected. That is, when a second rtsp client connects and requests the video stream, the server restarts the first rtsp client video stream. So both clients end up getting video from the beginning of the stream (file).<br>
><br>
> Is this a bug or as designed?<br>
><br>
> Steps to reproduce:<br>
> 1) ./test-launch "( filesrc location=input.mp4 ! qtdemux name=d ! tee name=t ! queue ! h264parse config-interval=-1 ! rtph264pay pt=96 name=pay0 )"<br>
> 2) start VLC Player and connect to rtsp://<a href="http://127.0.0.1:8554/test" rel="noreferrer" target="_blank">127.0.0.1:8554/test</a> and wait for video to stream a few minutes<br>
> 3) start another instance of VLC Player and connect to rtsp://<a href="http://127.0.0.1:8554/test" rel="noreferrer" target="_blank">127.0.0.1:8554/test</a>, wait for video to stream, the stream starts at the beginning of the input.mp4 and the video stream in step 2 above stops and plays from the beginning of the file.<br>
><br>
> The behavior is the same for rtsp server 1.16.2 and 1.18.4. Oddly, if I start two gst-launch-1.0 rtspsrc location=rtsp://<a href="http://127.0.0.1:8554/test" rel="noreferrer" target="_blank">127.0.0.1:8554/test</a> ! ... instead of VLC Player this works: the second stream plays at time of connection; however, if I start/stop one of the rtsp clients, video freezes and doesn't play for the newly started client (at times, the stream totally ends for both rtsp clients) . So it doesn't seem to be robust or reliable.<br>
><br>
> Thanks<br>
><br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div>
</blockquote></div>