[vlc-devel] commit: Remove non-sensical NPT computation code from c9569b35. ( Rémi Den is- Courmont )

[Ross Finlayson]

>VLC needs 2 things.
>PTS: a timestamp for decoder/display

OK, but note that the "presentation timestamp" of a frame represents 
the time that it should be displayed, *not necessarily* the time that 
it should be *decoded*.  This difference becomes apparent when you 
have a MPEG-2 video stream that includes B-frames.  In that case, the 
video frames appear (in the RTP stream) in the order that they should 
get delivered to the decoder, but their presentation times will be 
out-of-order (because the B-frames appear in the RTP stream after the 
later-to-display (I or P) frames that they depend on.


>PCR: a timeline that 'steers' our input chain clock to do things at 
>the right time.

I'm not totally sure of the distinction that you're making between 
these two, but I note, once again, that "presentation timestamps" are 
the *only* times that are delivered by RTP/RTCP.  In particular - and 
this is important to understand - the only thing 'RTCP sync' (as you 
call it) does is to give you more accurate presentation times (the 
exact same times that were generated by the server).  So please stop 
asking for 'RTCP sync' times.  You already *have* them - they're the 
presentation times.  THERE IS NOTHING MORE THAT YOU CAN GET FROM THE 
RTP/RTCP STREAM.

Also, as I noted earlier, there's no guarantee that presentation 
times are aligned with wall-clock time.  Now, you mention that you 
also want to maintain separate "PCR" times".  That's fine: You can 
presumably do this by maintaining an offset between presentation time 
and 'PCR time'.  I've already described (in pseudo-code) how you can 
compute this offset initially.  You may want to change this offset 
whenever you do a seek/resume-from-pause etc., as you note here:


>When you look at all the PTS from all the samples, whenever there is 
>a jump in PTS (usually seeking, possibly play/pause in the case of 
>RTSP) it requires a RESET_PCR send to our core to help signal the 
>decoders and demuxers, and then the new PTS (that belongs to this 
>new synced timeline) to be sent as the new PCR

Yes, feel free to do this whenever a seek/pause/play is done.


>We need the PCR to update regularly, so that we can detect drift 
>between server and client.
>Now here we have our current problem in the live555 module. Up until 
>now, we used PTS as PCR. This breaks if a server sends data in a 
>tempo that is faster than "normal playing time", for instance the 
>link below. This causes VLC to process the first 30 secs of this 
>movie in like 10secs

Are you saying that the presentation times delivered for this stream 
are increasing at 3x the rate (per frame) at which they really 
should?  If so, then this is definitely a buggy stream.

Or are you just saying that the server delivers 30 seconds worth of 
data in about 10 seconds?  If so, then that's OK.  Apple's servers 
sometimes do this (burst-transmit the first few seconds of a stream, 
so that the receiving ciient can adequately pre-buffer it).  This is 
OK - it just means that VLC needs to buffer up the data that it's not 
yet ready to play.  But VLC still *decodes/displays* the buffered 
data at the rate given by the RTP-delivered presentation times, which 
should (unless the stream is buggy) cause the stream to play at the 
proper rate.  (This means that VLC's buffer should store not just the 
incoming data, but also their presentation times.)


>So basically, the PTS of samples becomes totally useless here. We 
>need to ignore it in any PCR calc, because if we receive too many 
>samples at once, the PTS will have progressed much faster than the 
>normal timeline.

No, it just means that VLC needs to buffer up the extra data, and 
decode/display it not at the rate at which it arrived, but instead at 
the times given by the frames' presentation times.

Suppose, for example, that when you receive a 1-frame-per-second 
stream, the frames arrive (over RTP) so that - within the first 3 
seconds - you receive 10 frames, with presentation times:
	42,43,44,45,46,47,48,49,50,51
That doesn't mean that you should try to decode/display all 10 frames 
within these 3 seconds.  On the contrary, it just means that you 
should first decode/display frame '42', then (1 second later) frame 
'43', then (1 second later) frame '44', then (1 second later) frame 
'45' etc.


>That leaves RTCP syncs, these are based on the server time, so 
>exactly what we want.

As I explained above, it's the *presentation times* that are based on 
the server time, and 'RTCP syncs' - which we handle in the LIVE555 
library - just make them more accurate.  So I don't want to hear any 
more about 'RTCP syncs' - you get them automatically.


>Next i need to figure out how timestamps change between pause and 
>seek in RTSP. I'm still unclear on that. If I pause, the value of 
>the PTS stays constant right ?

(More precisely, you're asking what happens after you *resume from* a 
pause.)  Most servers (ours, for example) will increase the 
presentation timestamps by an interval that's equal to the length of 
time that you were paused.  I think that's the right thing to do. 
But other servers might not jump the presentation time.  It's 
probably a good idea to recompute your offset between presention time 
and 'PCR time' whenever you resume from a pause.


>  But what about seek what happens there ?

According to the RTP spec, the presentation times must always 
increase in time (except for things like B-frames, as noted above), 
even if you seek backwards in time.  However, some old versions of 
the Darwin/QTSS had a bug whereby they would decrease their 
presentation times after they did a backwards 'seek'.  So again, it's 
probably a good idea to recompute your offset between presention time 
and 'PCR time' whenever you resume from a 'seek'.


>P.S. Also, looking trough the sources of liveMedia I spotted: 
>setPacketReorderingThresholdTime().

Don't worry about this!  This affects only streams in which RTP 
packets get misordered (e.g., by routers) over the network.  This 
almost never happens, but if it does, the LIVE555 library code 
automatically reorders the packets before delivering the data to you.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/