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

[Ross Finlayson]

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

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

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