[Live-devel] time difference
Артур Хайруллин
ah at avtodoria.ru
Mon Oct 31 00:14:01 PDT 2016
thank you. Ross! I found the reason it this answer
"But I notice that there's an abrupt change in a stream's presentation
times after the first RTCP "SR" packet has been received. Is this a bug?
No, this is normal, and expected; there's no bug here. This happens because
the first few presentation times - before RTCP synchronization occurs - are
just 'guesses' made by the receiving code (based on the receiver's 'wall
clock' and the RTP timestamp). However, once RTCP synchronization occurs,
all subsequent presentation times will be accurate.
This means is that a receiver should be prepared for the fact that the
first few presentation times (until RTCP synchronization starts) will not
be accurate. The code, however, can check this by calling "RTPSource::
hasBeenSynchronizedUsingRTCP()". If this returns False, then the
presentation times are not accurate, and should not be used for
synchronization. However, once the call to returns True, then the
presentation times (from then on) will be accurate. "
[image: ООО "Автодория"] <http://www.avtodoria.ru/>
*Артур Хайруллин* / Системный программист
ah at avtodoria.ru / +7 904 677 74 46
ООО "Автодория"
+7 843 524 74 12
Казань, Технопарк в сфере высоких технологий "ИТ-парк", Петербургская, 52,
офис 303
www.avtodoria.ru
*Инновации спасают жизни!*
2016-10-29 18:02 GMT+03:00 Ross Finlayson <finlayson at live555.com>:
> 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
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20161031/450075a9/attachment.html>
More information about the live-devel
mailing list