[vlc-devel] commit: Remove non-sensical NPT c omputation code from c9569b35. ( Rémi Denis- Courmont )
finlayson at live555.com
Mon Jul 21 04:23:33 CEST 2008
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
>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
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 ptsWallClockOffset = 0;
bool haveSeenFirstValidPTS = false;
if (!haveSeenFirstValidPTS &&
/* This is the first RTCP-synched reported PTS => set
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":
Live Networks, Inc.
More information about the vlc-devel