AW: gst-rtsp-server shared media not working as expected

Wed Jul 28 03:49:41 UTC 2021

Hi,
you might like to try
GST_DEBUG_BIN_TO_DOT_FILE_WITH_TS((GstBin*)m_pRtph264pay->object.parent->parent, GST_DEBUG_GRAPH_SHOW_ALL, "rtsp-piece");
Or similar
Gruesse

Von: gstreamer-devel <gstreamer-devel-bounces at lists.freedesktop.org> Im Auftrag von Alan via gstreamer-devel
Gesendet: Mittwoch, 28. Juli 2021 04:43
An: Nirbheek Chauhan <nirbheek.chauhan at gmail.com>
Cc: Alan <dartagnan64b at gmail.com>; Discussion of the development of and with GStreamer <gstreamer-devel at lists.freedesktop.org>
Betreff: Re: gst-rtsp-server shared media not working as expected

Hi Nirbheek, thanks for your help so far, you've been very informative!

One last thing, is there a way to dump the rtsp rtpbin pipeline graph with GST_DEBUG_BIN_TO_DOT_FILE_WITH_TS()? I am interested in the behind the scene pipeline that connects to the "pay%d" elements (not my rtspmedia pipeline which I can dump in media-config) .

Thanks a bunch!

On Wed, Jul 21, 2021 at 11:20 AM Nirbheek Chauhan <nirbheek.chauhan at gmail.com<mailto:nirbheek.chauhan at gmail.com>> wrote:
Hi Alan,

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.

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.

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:

https://github.com/sdroege/rtsp-server<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsdroege%2Frtsp-server&data=04%7C01%7C%7Ce0e13b4ff5924e386dd508d9517a1ce5%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637630407175546154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=NhgtEnIlnPw0fD%2Bc5IX%2FvHRnemI9cYqFOVrH8DjsFKA%3D&reserved=0>

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:

https://github.com/sdroege/rtsp-server/blob/master/examples/simple_server.rs<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsdroege%2Frtsp-server%2Fblob%2Fmaster%2Fexamples%2Fsimple_server.rs&data=04%7C01%7C%7Ce0e13b4ff5924e386dd508d9517a1ce5%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637630407175546154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=v1f3JtXoLwImtMU5%2BfOSktlsv42fqg0NUdSBouHy8VQ%3D&reserved=0>

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:

GST_DEBUG_CATEGORY_INIT (rtsp_media_debug, "rtspmedia", 0, "GstRTSPMedia")

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

Cheers,
Nirbheek

On Wed, Jul 21, 2021 at 10:17 AM Alan <dartagnan64b at gmail.com<mailto:dartagnan64b at gmail.com>> wrote:
Nirbheek, thanks for replying.

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.

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://127.0.0.1:8554/test<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A8554%2Ftest&data=04%7C01%7C%7Ce0e13b4ff5924e386dd508d9517a1ce5%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637630407175556108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=uT6ykH3S8XJLpAnPN7FHCilRG4W38HmPrnLD5oneiNg%3D&reserved=0>" protocols=4 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! autovideosink, I get one RTSP client  pausing and one dropping out. Console logs showed:

rtsp client 2:
rtspsrc gstrtspsrc.c:3567:on_timeout_common:<rtspsrc0> source 651c0106, stream 651c0106 in session 0 timed out

rtsp client 3:
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

1) There seems to be a few bugs here. Are they filed and any plans of fixing these?

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

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.
Thank you!

On Tue, Jul 13, 2021 at 6:50 AM Nirbheek Chauhan <nirbheek.chauhan at gmail.com<mailto:nirbheek.chauhan at gmail.com>> wrote:
Hi Alan,

You would need to look at the GST_DEBUG logs of gst-rtsp-server to
figure out what RTSP commands are being sent on connect / disconnect
by VLC and rtspsrc. If I remember correctly, VLC uses live555 which
has a sub-par RTSP client implementation and it may just be doing the
wrong thing. For instance, it may be sending a Range header in the
PLAY request that forces the server to seek to the beginning of the
file.

As for rtspsrc, it actually sends a PAUSE request when stopping, so
you need to intercept that using the "before-send" signal. See also:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/908<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fgstreamer%2Fgst-plugins-good%2F-%2Fmerge_requests%2F908&data=04%7C01%7C%7Ce0e13b4ff5924e386dd508d9517a1ce5%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637630407175556108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ZzNNivuBssc%2Bm4J2WPYQsYRuQMKW51FjbriKtFePpWM%3D&reserved=0>
where I had to revert my attempt at fixing this. I am sure there are
other bugs there too, but they should be fixable.

You may also like to use gstreamer master for rtspsrc. There have been
a number of fixes for shared RTSP playback and seeking there
(multicast, udp, etc).

Cheers,
Nirbheek

On Mon, Jul 12, 2021 at 12:15 PM Alan via gstreamer-devel
<gstreamer-devel at lists.freedesktop.org<mailto:gstreamer-devel at lists.freedesktop.org>> wrote:
>
> Hello,
>
> 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).
>
> Is this a bug or as designed?
>
> Steps to reproduce:
> 1) ./test-launch "( filesrc location=input.mp4 ! qtdemux name=d ! tee name=t ! queue ! h264parse config-interval=-1 ! rtph264pay pt=96 name=pay0 )"
> 2) start VLC Player and connect to rtsp://127.0.0.1:8554/test<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A8554%2Ftest&data=04%7C01%7C%7Ce0e13b4ff5924e386dd508d9517a1ce5%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637630407175566063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=kQib6Z9Q8%2BOcq%2FAYwavPE4UqFFvzRKtLgn6vnjA%2FqDs%3D&reserved=0> and wait for video to stream a few minutes
> 3) start another instance of VLC Player and connect to rtsp://127.0.0.1:8554/test<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A8554%2Ftest&data=04%7C01%7C%7Ce0e13b4ff5924e386dd508d9517a1ce5%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637630407175566063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=kQib6Z9Q8%2BOcq%2FAYwavPE4UqFFvzRKtLgn6vnjA%2FqDs%3D&reserved=0>, 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.
>
> 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://127.0.0.1:8554/test<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A8554%2Ftest&data=04%7C01%7C%7Ce0e13b4ff5924e386dd508d9517a1ce5%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637630407175576021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=TN5IPh183S6eKlAsX46I5Ga6QVnXWP8FWWVKUKsSkNw%3D&reserved=0> ! ... 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.
>
> Thanks
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org<mailto:gstreamer-devel at lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fgstreamer-devel&data=04%7C01%7C%7Ce0e13b4ff5924e386dd508d9517a1ce5%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637630407175576021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=4z%2BLzs0OzCwEAVDBpoGEIlAM0Zw2xMdVJSZVhBimfs8%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210728/c55f7117/attachment-0001.htm>