[vlc-devel] commit: Remove non-sensical NPT c omputation code from c9569b35. ( Rémi Denis- Courmont )
hartman at videolan.org
Tue Jul 22 02:41:33 CEST 2008
On 21 jul 2008, at 04:23, Ross Finlayson wrote:
> At 3:13 AM +0200 7/21/08, Derk-Jan Hartman wrote:
>> Issues that I still have:
>> 1: Seeking with QTSS/DSS hosted RTSP sessions doesn't work, because
>> the timestamps act out. (Ross known issue right?)
> No, I'm not aware of any issue here, but perhaps it's related to
> your second point: ???
>> 2: When opening Apple QTSS streams, data is not send at wall time.
>> Since VLC assumes the highest PTS to be the wall time, the streams
>> act weird.
OK, I'm confused, but getting closer. Lets start from the top,
otherwise the mail will be a total mess.
VLC needs 2 things.
PTS: a timestamp for decoder/display
PCR: a timeline that 'steers' our input chain clock to do things at
the right time.
PTS can arrive early (in theory), PCR should not. Basically at RATE 1,
without changes, PCR runs in the same tempo as the cpu time, and in
the same "range" as the pts (numerically).
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
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, with pitch issues in the audio. (VLC thinks, oh, the PCR
is moving fast, we need to play quicker to keep up (I think, not sure)).
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
That leaves RTCP syncs, these are based on the server time, so exactly
what we want. I am now refocusing here.
But, how am I made aware of RTCP syncs ? At these times I need to send
a PCR update, I need to know when they occur and what the timestamp of
that RTCP sync is. I can send (to our core) more between syncs by
constantly adding and subtracting mdate(), but every RTCP sync should
take precedence on such hackery, specifically to find drift between
the server timeline and vlc timeline. Can I verify that an update has
occurred by checking if rtpSource->lastReceivedSSRC() has changed ?
This is required even for normal playback, without doing a single thing.
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 ? Nothing should change after I resume normall ?
But what about seek what happens there ? And behave all the RTSP
servers the same in this respect ? What if there is no RTCP sync
What I have _now_ after taking some of the above into consideration,
and starting with PCR from blank (I literally pulled out all the old
stuff). Whenever I see that hasBeenSynchronizedUsingRTCP() is first
true, I set PCR as the current PTS (or rather the first pts I
encounter in the first sample per track that I parse.)
I only send it "once". This makes the apple streams behave better, but
still not perfect (I suspect due to later RTCP syncs that I'm not
I do the following in the following cases:
Pause: I do nothing. everything stays as it is, allowing VLC to finish
playing it's codec buffers
Play: I reset i_pcr (local pcr) to 0; I sent a RESET_PCR to vlc core;
set the first PTS after I see hasBeenSynchronizedUsingRTCP() is true
again for a track (I'm not ever sure if this reset in liveMedia core
when I pause/play).
Seek: same as with Play.
Play/Pause seems to work, but Seek is continually thrown off course.
(I guess because the PCR needs to change after a few secs or
something, having received a new RTCP sync).
I think i'm at least on a better path now than yesterday, and I will
look at it again tomorrow.
Feedback is once again welcome. Current direction of what I'm thinking
can be seen from the attached patch.
P.S. Also, looking trough the sources of liveMedia I spotted:
setPacketReorderingThresholdTime(). This got me thinking that with all
that "in advance data sending" of QTSS, it might be tripping that
threshold, causing skipped parts (something i'm still seeing with the
new PCR code).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8266 bytes
Desc: not available
-------------- next part --------------
More information about the vlc-devel