[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:
>> I've being doing some work on the live555 code, because it was in a  
>> dismal state. partially caused by my absence last year.
>
> Many thanks, DJ!
>
>> 1: removes all LIVEMEDIA version checks. It's about time we force  
>> another update here. Versions from this year are much better
>>   (P.S. Ross, do you have a recent VERSION_INT from the last "API  
>> change" ? )
>
> Yes, everyone should be using a version with a  
> LIVEMEDIA_LIBRARY_VERSION_INT > 1214895600 (Versions before this  
> have some bugs that are potentially significant for RTSP clients,  
> such as VLC.)
>
>> 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: ???

It is one of the longest standing RTSP bugs for VLC. You should try  
that rtsp link i gave with 0.8.6 you'll see what i mean :D

>> 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.
>
> A RTP receiver should never assume that presentation timestamps are  
> aligned with wallclock time.  (They generally will be for LIVE555  
> RTSP servers, but even then, that will be true only if the server's  
> 'wall clock' is accurate.)

Actually it is the server's "wall clock" that we are interested in.  
That is what we consider to be the "pcr" (from MPEG) it should be  
linear and help us find clock gaps. And, this value needs to be  
updated once in a while. (To verify that our wall time still follows  
the servers wall clock). So basically I need raw "ntp" timestamps from  
the server (Not PTS, not NPT). They are supposed to be in RTCP reports  
I think, but i'm not sure how to get them from live555.

I think that (from live555) in noteIncomingSR|(), i need this part:
     fSyncTime.tv_sec = ntpTimestampMSW - 0x83AA7E80; // 1/1/1900 ->  
1/1/1970

And then we should update this PCR value only when we receive RTCP  
reports (can we find out when those are received?).
We need this value if we want to distinguish between the packets with  
a PTS highly out of sync and packets with PTS in sync.
(Though we still need to tackle injecting packets which arrive early,  
later into the stream, but that would be a separate issue, i guess we  
could do best effort there based on RTP sequence numbers)

> Perhaps the solution would be for VLC to maintain an offset - for  
> each RTP stream - between the PTS that it reports and 'wall clock  
> time'.  I.e., do something like (pseudocode):
>
> 	int64_t ptsToUse;
> 	int64_t ptsWallClockOffset = 0;
> 	bool haveSeenFirstValidPTS = false;
>
> 	if (!haveSeenFirstValidPTS && tk->sub->rtpSource()- 
> >hasBeenSynchronizedUsingRTCP()) {
> 		/* This is the first RTCP-synched reported PTS => set  
> "ptsWallClockOffset" */
> 		ptsWallClockOffset = gettimeofday() - reportedPTS;
> 		haveSeenFirstValidPTS = true;
> 	}
> 	ptsToUse = reportedPTS + ptsWallClockOffset;
>
> This works because the initial PTSs that are reported before the  
> stream gets RTCP-synchronized are already wall-clock aligned  
> (because they were PTSs that we 'guessed' just from the RTP  
> timestamp alone).

I would prefer to do it properly like mentioned above.

> BTW, if you haven't already done so, you might also try testing RTSP  
> seeking (and scaling, if your VLC version supports it) with MPEG-2  
> Transport Streams served from a "LIVE555 Media Server": http://www.live555.com/liveMedia/transport-stream-trick-play.html

I think i'll do one thing at a time. it's such a mess. :D

DJ