gst-rtsp-server shared media not working as expected

[Alan]

I also tried to ditch gst_rtsp_media_set_shared(media, TRUE)  and use
appsrc and appsink workaround where I'd get finer control over the media.
My appsrc pipeline is "appsrc name=appsrc is-live=true ! h264parse
config-interval=-1 ! rtph264pay pt=96 name=pay0".  I pump avc/au data into
appsrc using push-sample. It works with multiple rtsp clients however I
still do experience some VLC/gstreamer rtsp clients  pausing and often
reconnecting.  Interesting log lines are:

1) FIXME              default
gstutils.c:4026:gst_pad_create_stream_id_internal:<appsrc:src> Creating
random stream-id, consider implementing a deterministic way of creating a
stream-id
2) FIXME              rtspmedia rtsp-media.c:4549:gst_rtsp_media_suspend:
suspend for dynamic pipelines needs fixing
3) WARN               rtspmedia rtsp-media.c:4582:gst_rtsp_media_suspend:
media 000001E4D817B1B0 was prepared by other client

Is this a dead end road as well without at least fixing the above FIXME
errors?

Thanks

On Wed, Jul 21, 2021 at 12:46 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/83d35ce5/attachment-0001.htm>