gst-rtsp-server shared media not working as expected

[Alan]

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> 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
>
> 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/20210727/0add7a33/attachment.htm>