[Live-devel] Presentation timestamp - why wall clock? SR handling question too.

[Derk-Jan Hartman]

On 25 jul 2008, at 22:09, Ross Finlayson wrote:
> It seems that your server is buggy. I've seen this before with some  
> versions of Apple's QuickTime (aka. Darwin) Streaming Server.
>
> Therefore, receivers need to be on the lookout for unusual changes  
> (decreases or large increases) in presentation time, and reset their  
> internally-maintained offset between presentation time and 'wall- 
> clock' time whenever they see this happen. (This is part of the  
> Internet philosophy of "Be conservative in what you send, and  
> liberal in what you accept.")

I was just gonna say that this looks exactly like what i was seeing on  
this stream rtsp://a2047.v1411b.c1411.g.vq.akamaistream.net/5/2047/1411/1_h264_650/1a1a1ae454c430950065de4cbb2f94c226950c7ae655b61a48a91475e243acda3dac194879adde0f/080690210abcn_2a_650.mov

that I was testing in VLC. I have been discussing this case with Ross  
on the vlc-devel mailinglist for the past day and we came to the  
conclusion that it was most likely the server that was incorrect. I  
haven't taken it to the QT mailinglist yet, but I think we should do  
that.

As for approach to deal with it. I simply have NO idea Roland... The  
problem is that it basically affects all data between (in your sample  
208 and 212) to go "bad" which is quite a large gap of course. I you  
have a briljant idea, i'll welcome it :D

DJ