> OK, then I think my mistake is to presume those timestamps are adjusted for > the server's timezone settings. In fact, they must be UTC values, with no > way to determine the timezone they originated from. In retrospect - duh, > that's how you'd expect timestamps to work, and that's probably already > documented somewhere. Let me know if I'm (still) misunderstanding.
Yes, you are still misunderstanding, I think. Clients cannot infer anything from the value of a *single* (RTCP-synchronized) presentation time - because the presentation times come from the server, whose clock does not have to have been synchronized with NTP. (For example, the server might think that it's still the year 1995!) The server *might* have set its presentation times to (NTP-synchronized) UTC, or it might have set its presentation times to some other time zone, or it might have set its presentation times thinking that it's still the year 1995. But the client does not know this (nor does it need to, in almost all cases). Clients can, however, use the *difference* between two frames' presentation times to figure out when (relatively) each frame should be rendered. Also, if the stream contains both audio and video substreams, then the presentation times from the audio and video frames can be used to properly synchronize the audio and video. But anyway, because I'm tired of explaining the same thing over and over again, this will be my - and your - last posting on this topic. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
