Ingemar Johansson S wrote:
But some implementations may like to make an assumption which is not directly given by the statement below.HiAfter 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
I am not sure if this statement is applicable to this.
layer alignment and synchronization makes it very clear what and RTP stack implementation should do.I think we cannot change the RTP stack implemenation here, that has to be the same for all implementations including RTCP for deriving NTP timestamps. But we may give a guideline on the RTP timestamp generation for layered codecs used with session multiplexing, which may be used to "improve" the data alignment process or may make it a little bit easier for some implementations. RTCP with NTP stays and is mandatory to be used, however an layered receiver may also rely on the fact the RTP timestamps are aligned in the different sessions in this particular case.
Could that be a way to go forward? Thomas -- Thomas Schierl -------------- Fraunhofer HHI
Regards IngemarExcert 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_OTo 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.CheersMagnus Westerlund
---- Visit us at MEDICA 2008 / Duesseldorf, Germany / 19 - 22 November 2008 / Hall 16, Booth D55 http://www.medica.de SOCCEREX 2008 / Gauteng, South Africa / 23 - 26 November 2008 / Booth V1-B1 a http://www.soccerex.com _______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www.ietf.org/mailman/listinfo/avt