[Live-devel] Interpreting Presentation Time

[Ross Finlayson]

> Sorry if this is a stupid question, but I can't fully understand how Live555's Presentation Times are to be applied, *aside* from synchronizing parallel media streams.

That's correct.  The presentation time indicates the time of each frame, relative to other frames of the same media type, and to frames of other media type(s) (if any).  They are used to render each frame at the appropriate time (again, relative to other frames of the same media type, and to frames of other media type(s) (if any)).


>  Is there any way to use these presentation times to determine the receiver's time offset from the server?

No.  Although the presentation times are generated by the server, they are not 'absolute' times, because you don't know what 'absolute' clock, if any, the server's clock is synchronized to.


> I'm still a bit mystified about how (or whether) it's possible to relate presentation times as computed for afterGettingFrame() to absolute time, as the server understands it.

It's not possible (without extensions to RTP/RTCP that we don't currently support).  But it's rarely something that you really need.  (See below.)


>  This would help calculate round-trip latency or ask the server to skip ahead when the client falls behind due to network or other delays.

Do you really need to know much time the receiver/player is behind the sender?  You usually shouldn't - unless you have *multiple* receivers (e.g., in the same room) that you need to keep synchronized with each other.  (As I noted above, there are RTP/RTCP extensions - currently being standardized by the IETF - to handle this situation, but it's not something that I plan to support any time soon, and it's rarely something that people really need.)


>  I know that SR's and RR's have something to do with it

Our *server* uses its received "RR" packets (from each receiver) to estimate the round-trip time to the receiver (note the function "RTPTransmissionStats::roundTripTime()").  However, this functionality is not available to receivers.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130219/4bdd3c01/attachment.html>