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

[Ross Finlayson]

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: ???

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

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

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

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