[Live-devel] RTSP Seek problems

[Ross Finlayson]

At 06:23 AM 1/26/05, you wrote:
> > > One other is that the currently given timestamps makes difficult
> > > (and not generic) the way to compute the position in stream when
> > > playing.
> >
> > That's not the purpose of the "RTP timestamp".  The purpose of the RTP
> > timestamp is to indicate the *presentation time* of the stream, which
> > is a continuous variable (even if the stream was generated by seeking
> > within a file).  In any case, I can't redefine what the RTP timestamp
> > means, nor can I change what RTP timestamps servers include in their
> > outgoing RTP packets.  Get real :-)
>
>It seems that you misunderstood me.
>
>If I could have the RTP Timestamp in the same time that the "Presentation 
>Timestamp", I would be able to do a SIMPLE substraction to have the 
>"current playing position" (for the seek bar in VLC).

No.  Once again: The "RTP timestamp" and the "presentation time" are 
(effectively) the same thing - they tell the receiver when to *render* the 
audio or video frame.  They are not supposed to have anything to do with 
any 'seeking' that may (or may not) have occurred - at the server end.

However, from your graphs, it seems that you are apparently using a RTSP 
server that changes the "RTP timestamp" (and thus "presentation time") to 
match the seek operations.  THIS IS WRONG!  RFC 3550, section 5.1 
specifically says that the RTP timestamp "MUST be derived from a clock that 
increased monotonically and linearly in time".

It turns out, therefore that the RTSP server (the "QuickTime Streaming 
Server", aka. "Darwin Streaming Server") that you are using for your 
testing is broken.  (My copy of the "Darwin Streaming Server" also has the 
same bug.  I'm going to report this bug to Apple.)

To handle buggy servers like this, media players (including VLC) will need 
to reset their mapping between the stream's reported presentation time and 
the actual 'wall clock' time - when they receive the first data following a 
'seek' operation.

> > There is such a function:
> >          RTPSource::curPacketRTPTimestamp()
> > which tells you the RTP timestamp of the most recently-received RTP
> > packet.  However, once again, you *do not need* this; it gives you no
> > useful information.
>
>Does this function give the "RTP timestamp" of the frame that is being 
>processed in the AfterGettingFunc or give the lastest "RTP timestamp" 
>received in the LIVE buffers ?

I'm not going to tell you :-), because you should not be using that 
function anyway.  (Instead, always use the "presentation time".)  If that 
function ends up being used in VLC's "livedotcom.cpp", I'll see that it 
gets taken out.  (The function may end up getting removed from future 
versions of the LIVE.COM code anyway.)


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>