gst-rtsp-server shared media not working as expected

Wed Jul 21 15:20:31 UTC 2021

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

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

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> 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" 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> 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
>> 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> 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 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, 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 !
>> ... 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
>> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210721/e2c5a10b/attachment.htm>