[vlc-devel] commit: Remove non-sensical NPT c omputation code from c9569b35. ( Rémi Den is- Courmont )
finlayson at live555.com
Mon Jul 21 14:27:52 CEST 2008
>>>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
I'll take a look at this once you've updated the code to handle the
second issue (and come out with a new binary version that I can try)
- because I suspect that the problem may be related to your handling
of the second issue.
>>>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.)
>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).
No - what you get from the RTP stream are presentation times, and
that is *all* you get from the RTP stream. (Note, however, that
these presentation times are not necessarily monotonic - e.g., if the
stream is MPEG-2 streams with B-frames.) These presentation times
were generated by the server's clock; *however*, there is no
guarantee that these times are aligned at all with the receiver's
'wall-clock time'. I.e., there is no guarantee that the server is
generating times that are in sync with 'real world time'. (Even
though the times included in RTCP reports are in the Network Time
Protocol (NTP) time *format*, they are not guaranteed to actually be
NTP-synced times. This is apparently what is happening with your
QTSS stream, if you've found that the received presentation times are
not aligned with VLC's wall clock.)
>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
But that time just ends up becoming the presentation time that gets
delivered to you!
Please don't try to overthink things :-) What you get from LIVE555
library is presentation times - so that's what you should use. If,
however, you want to ensure that the received presentation times are
aligned with your 'wall clock', then you can do this (using code
similar to the pseudo code that I included in my last message).
>And then we should update this PCR value only when we receive RTCP
>reports (can we find out when those are received?).
Yes. Again, see the pseudo-code that I included in my last message.
>(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)
You don't have to worry about this at all! The LIVE555 library code
handles (and reorders) out-of-order RTP packets automatically. Code
- like VLC - that uses this library should not have to care about RTP
sequence numbers (or RTP timestamps, for that matter).
Again, I think you're overthinking things :-) The LIVE555 RTP client
library delivers to you an ordered stream of data frames, each with a
presentation time, and that's what you should use. (If, however, you
really want to use a PCR instead, then you're going to have to look
inside the MPEG data to get it (the same as if you were reading from
a file), because RTP doesn't give you PCRs.)
Live Networks, Inc.
More information about the vlc-devel