[vlc-devel] commit: Remove non-sensical NPT c omputation code from c9569b35. ( Rémi Denis- Courmont )

[Derk-Jan Hartman]

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

rtsp://a2047.v1411b.c1411.g.vq.akamaistream.net/5/2047/1411/1_h264_650/1a1a1ae454c430950065de4cbb2f94c226950c7ae655b61a48a91475e243acda3dac194879adde0f/080690210abcn_2a_650.mov

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.

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

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

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

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...
Name: live555_pcr.patch
Type: application/octet-stream
Size: 8266 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080722/8883e039/attachment.obj>
-------------- next part --------------