[Live-devel] RTSP Seek problems

[Derk-Jan Hartman]

On 26 jan 2005, at 17:20, Ross Finlayson wrote:
> 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.

Hi Ross,

I'm running into this issue atm, and it's annoying the hell out of me :D
I was trying to add a condition to shut down the rtsp session if  
current time is much larger then total length.
However this bug is causing a period of "way beyond total length" for  
several seconds when you seek a considerable amount of time, thus  
resulting in the closing of the stream.

Are there any new developments in this?
You have any idea how we could detect the period that such incorrect  
timestamps are being sent or something?
The only thing i can think of is logging the time of the seek and  
then add yet another condition to "NOT close the stream" if current  
time < last_seektime + 10 seconds....

DJ


>> > 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.)