[Bug 648463] pipeline stalls when using gst_rtsp_media_factory_set_shared (factory, TRUE) && vlc

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=648463
  GStreamer | gst-rtsp-server | git

--- Comment #6 from Marc Leeman <marc.leeman at gmail.com> 2011-04-22 14:34:42 UTC ---
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?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.