I’m sorry, but I’m not sure that I understand your question. However, please
note that LIVE555 programmers should never have to deal with RTP timestamps
directly. Our software automatically uses RTCP to convert presentation times
to RTP timestamps (when transmitting) and back to presentation times (when
receiving). Presentation times are all that you need to think about.
(Therefore, please don’t mention the word “timestamp” again; this will lead to
unnecessary confusion.)
Also, if you haven’t done so already, please read our FAQ; especially these
entries:
http://live555.com/liveMedia/faq.html#separate-rtp-streams
http://live555.com/liveMedia/faq.html#rtcp-synchronization-issue
Finally, if you are receiving a RTSP/RTP/RTCP stream (i.e., if you are a RTSP
client), then it’s perfectly OK for the presentation time of the received
frames (after RTCP synchronization) to be different from ‘wall clock’ time.
This can happen if the sender (i.e., RTSP server) has a clock that is not set
to ‘wall clock’ time. But that’s OK; it’s only the *difference* between
successive presentation times that matters (for proper playback, and
audio/video synchronization).
(If, however, you are writing a RTSP *server* that uses our code, then the
presentation times that it sends (for each of its frames) should be aligned
with the server computer’s ‘wall clock’ time (i.e., the time that you’d get by
calling “gettimeofday()”.)
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
