[vlc-devel] RTSP client 'trick play' support. When will it ever work??

Rémi Denis-Courmont remi at remlab.net
Thu Jul 9 21:29:28 CEST 2009


Le jeudi 9 juillet 2009 18:06:52 Ross Finlayson, vous avez écrit :
> >Le Thursday 09 July 2009 08:14:33 Ross Finlayson, vous avez écrit :
> >>  So, the real problem is that VLC - in step 2 - is sending a "PLAY"
> >>  command without an end time, despite the fact that the SDP
> >>  description (returned in response to "DESCRIBE") had a range end
> >>  time.  "ms->playEndTime()" *should* be non-zero (because "*ms" was
> >>  created using the SDP description).  Could you please check this??
> >
> >If you want to play from beginning to the end, you should send 0-, not
> > 0-end.
>
> In this sentence, who do you mean by "you"?

I mean a given RTSP User Agent.

> If you mean that the client (VLC) is incorrect in
> how it's sending the "PLAY" request, then that
> contradicts what you say here:

> >Step 3 is correct indeed - but step 2 is correct as well.

Uh? No. I am saying that sending "0-" is the correct way to play from 
beginning to the end. Sending "0-xxx" means play from beginning to offset xxx, 
which is semantically different. See also RFC2326 §10.5:

   (...) the server will first play (...) seconds 30 through the end. (...)

     C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 837
           Session: 12345678
           Range: npt=30-

So at step 2, VLC is behaving correctly. And then at step 3, the server has no 
obligation to specify what the end is either:

   For a on-demand stream, the server replies with the actual range that
   will be played back. (...)

     C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
           CSeq: 833
           Session: 12345678
           Range: smpte=0:10:20-;time=19970123T153600Z

     S->C: RTSP/1.0 200 OK
           CSeq: 833
           Date: 23 Jan 1997 15:35:06 GMT
           Range: smpte=0:10:22-;time=19970123T153600Z

So if client requests 0-, I understand the server should reply 0- as well.

Hence, I infer VLC/live555 should not rely on the PLAY response to determine 
the timespan of a media. That leaves the result of DESCRIBE as the only 
option.

(Ideally, VLC would have some implement some kind of progress bar, even when 
it does not know the length of a _seekable_ media. Currently, it will show the 
length as 00:00 and the UIs will prevent seeking completely.)

-- 
Rémi Denis-Courmont
http://www.remlab.net/




More information about the vlc-devel mailing list