[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] alignment of layers issue
Hi
After some excel sheet hacking I have finally come to the point where I believe that the method proposed by Magnus (see below) would actually solve the issue with slow update rate or inaccurate NTP clocks.
Reading RFC3550 (6.4.1) again one could well find the below method embedded in the text and then again one can find another way to implement this especially as the text says
"RTP timestamp: 32 bits
Corresponds .......
......Note that
in most cases this timestamp will not be equal to the RTP
timestamp in any adjacent data packet. Rather, it MUST be
calculated from the corresponding NTP timestamp using the
relationship between the RTP timestamp counter and real time a
maintained by periodically checking the wallclock time at a
sampling instant."
The "in most cases" statement leaves the door open for many alternative implementations. I would here suggest that any new document that describes layer alignment and synchronization makes it very clear what and RTP stack implementation should do.
Regards
Ingemar
Excert from Magnus's email below
=========================================
>Regarding how to generate correct RTCP SR packets this is how you do it:
>At start up of codecs you take one clock value for the media clock TS_O
>and the corresponding system clock NTP_O. This reference is going to be
>used for all layers, i.e. in all RTP Sessions for this media source.
>When sending an RTCP SR at time p, the sender gets the current system
>clock value NTP_P. It doesn't sample the media clock to determine the
>RTP TS value, instead this is calculated based on the reference value.
>TS_P= (NTP_P-NTP_O)/TS_RATE + TS_O
>To determine clock skew you need to regularly sample system clock and
>media clock and use that to determine if you have significant clock skew
>that needs adjustments. This should be low pass filtered and probably
>put on threshold to avoid unnecessary updates. Only when the clock skew
>affects inter media synchronization to such a degree that issues arise
>or the buffer handling becomes problematic should this be updated, i.e.
>at least 20-50 ms error before reacting. Certain applications can take
>much bigger errors before reacting.
>If you have clock skew that becomes an adjustment parameter in the above
>calculation, or an update of the NTP_O TS_O binding.
>When using the above method you will not have an issue that the
>synchronization information in the SR will depend on inaccuracy of the
>system clock.
>Cheers
>Magnus Westerlund
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt