Created attachment 186476 [details]
debug logging

First an RTSP client from GST is started; followed by an RTSP client from VLC.
the seek has been disabled in rtsp-client.c

Created attachment 186477 [details]
debug logging

GStreamer rtsp client; followed by a VLC rtsp client on test-readme.c

RTSP PLAY from GStreamer:
key: 'Range', value: 'npt=now-'

RTSP PLAY from VLC
key: 'Range', value: 'npt=0.000-'

Should the value 0.000 in
./gst-plugins-base/gst-libs/gst/rtsp/gstrtsprange.c

be recognised as "now"?

RFC 2326              Real Time Streaming Protocol            April 1998
     The syntax conforms to ISO 8601. The npt-sec notation is optimized
     for automatic generation, the ntp-hhmmss notation for consumption
     by human readers. The "now" constant allows clients to request to
     receive the live feed rather than the stored or time-delayed
     version. This is needed since neither absolute time nor zero time
     are appropriate for this case.

Tried to get some feedback on #videolan

16:05 < den_erpe1> Is this correct; I've been trying to make sense of this in RFC 2326
16:05 < den_erpe1> there it says that zero time should not be used for this
16:05 < den_erpe1> (bottom page 16)
16:11 < linkfanel> den_erpe1: it says it's inappropriate for the server to use that for live feeds
16:12 < linkfanel> or that the client shouldn't use that if it's requesting a live stream
16:16 < den_erpe1> the client should not use 'now' or '0.000'?
16:16 < den_erpe1> the vlc client is sending 0.000 on a live source
16:17 < linkfanel> how does vlc know it's a live source?
16:17 < linkfanel> if it's not a live source, then it's perfectly valid to send '0.000'
16:18 < linkfanel> if it's a live source, then it's debatable whether 'now' or '0.000' is the right thing to do
16:18 < den_erpe1> I don't know; how should this be passed in RTSP?
16:19 < linkfanel> what's your issue?
16:20 < linkfanel> zcat stream.gz | vlc -
16:21 < den_erpe1> if it is live; then 0.000 should not be used; that's in the RFC; but you raise a point; how to know if it is live
16:22 < den_erpe1> I have an rtsp server that is acting up when VLC sends the PLAY command; and finally got to the PLAY command
16:22 < linkfanel> BtbN: there's a stream filter to do the decompression, but i don't know if it's supposed to be automatic or how to use it
16:22 < linkfanel> den_erpe1: you can request 0.000 on a live stream
16:23 < linkfanel> it means that you expect the server to have recorded/buffered the stream since its beginning
16:23 < den_erpe1> The "now" constant allows clients to request to
16:23 < den_erpe1> receive the live feed rather than the stored or time-delayed
16:23 < linkfanel> yes
16:23 < den_erpe1> version. This is needed since neither absolute time nor zero time
16:23 < den_erpe1> are appropriate for this case.
16:23 < den_erpe1> http://www.ietf.org/rfc/rfc2326.txt
16:23 < linkfanel> i know that bit
16:24 < den_erpe1> I can fix it on the server side; but I'd like to get more info on this
16:25 < linkfanel> the client can request 0.000, it means that it doesn't want the stream live
16:25 < linkfanel> if the server doesn't support it, the server should return an error
16:25 < den_erpe1> mkay
16:26 < linkfanel> or it may just play nice and interpret 0.000 as meaning now
16:26 < linkfanel> that's what the RTSP server of VLC does
16:26 < ringo> has anyone used vlc to act as an rtsp server for milestone universal driver? I am having aproblem were it is not recognizing the stream.
16:26 < den_erpe1> so, if the server sends out a live stream; and a 0.000 is requested; the server should return an error indicating that it does not support absolute offset
16:26 < linkfanel> that's an acceptable behavior
16:26 < den_erpe1> so, then the client would need to send the 'now-' range as a result
16:27 < linkfanel> well the client should send "now-" if it's really what the user wants
16:27 < linkfanel> the problem is that when the user clicks on play, it doesn't know if the stream is live and what it should request
16:28 < den_erpe1> does VLC does this at this moment; 'cause if this is added to the rtsp server; and the result is no-video; I'm back to square one
16:29 < den_erpe1> so what you're saying is that sending the Range 0.000- or Range now- on the initial play command; it is an arbitrary choice until the client knows better based on the server responses?
16:32 < linkfanel> den_erpe1: that's one way to see it

Would this mean that sending an error when a Range other than now is requested would be good to add to the server instead of doing the seek on the pipeline?

Created attachment 186641 [details] [review]
fixup: ignore seek when live

live555 sends a PLAY command with absolution time values. This causes the pipeline to stall when seeking on a live source and using a shared media rtsp.

This patch does a quick check to see if the media is live; if so; ignore the seek.

An alternative otption is to send an error back when getting a PLAY with absolute time coordinates and let the player figure out what to do next. This is probably cleaner; but might break more.

See RFC 2326

Hm, the SDP is sending 
a=range:npt=now-

so the value of live555 is wrong?

VLC shouln't send 0.000 when the SDP says now-, IMO.

What I wonder is why things would lock up when a seek happens. 

It's possible to seek in what GStreamer considers to be a 'live' source (for example you can seek in rtspsrc and that's a live source). You could possibly also seek when that media is shared (all shared instances get updated video). 

What kind of data is rtsp-server streaming? Maybe it needs some extra flags to mark media a non-seekable? is this with recent -good plugins?

the application is test-readme in the examples subdir in gst-rtsp-server

The issue seems to be the live555 lib; that one parses the sdp and returns a wrong value

from #videolan:
the VLC module retrieves a "starttime" from live555 by doing "p_sys->i_npt_start = p_sys->ms->playStartTime();"
and then this is passed to the PLAY request. Apparently, if there is no range header, p_sys->ms->playStartTime() still returns 0
it seems to me that it would make more sense if playStartTime() return -1, but i don't know the live555 code behind it

Any progress here? What should we do?

Comment on attachment 186641 [details] [review]
fixup: ignore seek when live

Rejected as per Wim's comments

I've been encountering a similar issue.  I'm not sure if it's related or not to this one, and I've opened a new bug for it at https://bugzilla.gnome.org/show_bug.cgi?id=761100, but I'm copying the info here in case it is related.

If a client suddenly loses network connectivity, then it can cause other clients to disconnect or their streams to freeze IF any one client us utilizing UDP.  

This only happens on a shared pipeline, and with UDP as the only set transport.

Steps to reproduce:

1) In gst-rtsp-server/examples/test-video.c, insert "gst_rtsp_media_factory_set_shared(factory, TRUE);" to line 136, and "gst_rtsp_media_factory_set_protocols(factory, GST_RTSP_LOWER_TRANS_UDP);" to line 137.
2) Recompile the gst-rtsp-server examples (navigate to the root directory, and run make)
3) Navigate to the example directory, and run the "test-video" shell script
4) use ifconfig to get your eth0/wlan0 IP address
5) Run the following command in a new terminal: "gst-launch-1.0 rtspsrc location=rtsp://<eth0/wlan0 IP address>:8554/test protocols=0x1 ! fakesink"
6) Open a VLC client, and connect to the localhost IP address - rtsp://127.0.0.1:8554/test
7) In another terminal, execute the following command: "sudo ip link set <eth0/wlan0> down"

This should cause the VLC client to quickly freeze it's current stream.  The gst-launch-1.0 client will take some time before it disconnects, but during that time if you reconnect the VLC client to the localhost IP, the stream will continue.

There appears to be an issue with how UDP handles multiple clients on a shared pipeline.  I can run any combination of UDP and TCP clients, and experience the issue if ANY one client loses their connection, even if that client is a TCP client.  However, if the server is configured to only allow TCP connections, this issue never occurs.

I have uploaded a video showing this to my dropbox here: https://www.dropbox.com/s/2ryew9npz5lja5f/gst-rtsp-server-udp-bug.webm?dl=0

No progress in 7 years, and unclear how to proceed so let's close this.

Please re-open if this is still a problem and needs fixing in GStreamer in some way.

(I also think that there is a semantic difference between 'now' and 0.0 and they could mean different things.)

(Maybe seeking should be disallowed on a shared pipeline with multiple clients connected, if that's not the case already? Didn't check.)