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/> *Артур Хайруллин* / Системный программист a...@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 <finlay...@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@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
