Thomas.Schierl at hhi.fraunhofer.de wrote:
Okay, I wasn't aware of the discussion at the Minneapolis meeting (that I haven't attended). Maybe you can just clarify this a little bit better in the draft.Hi Stefan, Stefan Döhla wrote:Hi Thomas, Thomas.Schierl at hhi.fraunhofer.de wrote:Then I think my assumption was correct, that you need to pre-filter the NTP timestamps so that they increase roughly linearly - but at least monotonically with each according RTP timestamp - otherwise it would be possible to align samples from several layers but it is no more guaranteed that they have the timestamps in correct order). And in addition, the SRs must be filtered then as well to correspond to the HDR_EXT timestamps (- what as I understood is a problem in practice where NTP timestamps are often way off).Stefan Döhla wrote:For the same RTP timestamp in SR and RTP packet, the NTP timestamp in the header extension as well as in the SR shall be the same.Hi Thomas, Thomas.Schierl at hhi.fraunhofer.de wrote:Let me rephrase it a little: If I accidentally receive an RTCP SR with the same RTP timestamp as in an RTP packet in either session, would the NTP timestamp be the same?Hi Stefan, Stefan Döhla wrote:Colin, Thomas, all,the draft is describing the proposed header extension and RTCP SR request quite good, however:Isn't the NTP timestamp generation subject to the same problems as in RTCP? I could easily send an RTCP SR as well for every RTP packet within a sampling instance of one (in terms of RTP time), i.e. there could be an RTP packet and an RTCP SR packet containing the same RTP timestamp if I were able to generate them virtually at the same time (just a few ns away). Clearly, this is not datarate-efficient nor sensible, but I don't see a big difference to the proposed approach.So what about the source for the NTP time: Should the NTP time be filtered at the sender before inclusion into the HDR_EXT? Because if not, the NTP timestamp would either be only related to the RTP timeline (bad - then we have two different timelines, one via RTCP, the other in the HDR_EXT) or be jittery (bad because not instantly useful, though the same timeline as RTCP).Here it is important to use the same NTP timestamp value for the same point of synchronization in all the sessions. This is only guaranteed, if such header extensions are used for the same sampling time instance in all the sessions, i.e. using the same NTP wallclock timestamp. I think this is stated in the draft.I agree, if you have such problems with your source wallclock, as we discussed intensively before and during the Minneapolis meeting, you would have to do so. But RFC 3550 anyway requires for the timestamps to be monotonically and linearly increasing. And as also discussed earlier, the linearity of the clock may be the problem in practice. I cannot see a new point here.
Okay. If backwards compatibility is not an issue, then everything's basically fine and most of my points are void. Considering all this, I would also like to see this becoming a WG item.If a stream is re-timestamped by an intermediate device the correspondence would be broken if not the HDR_EXT is also adjusted. Also this device would have to follow the same rules.I guess the answer would be in the same spirit as other answers to backward compatibility with respect to layered codecs: If there is a mixer which does not know about the new layered codec and hence does not know about the new header extensions, such device wouldn't do anything reasonable with the layered media anyway. But this may be a reason for requiring the use of the header ext for timestamp based decoding order recovery in the layered codec drafts.
Cheers - Stefan [snip] -- Dipl.-Ing. Stefan Döhla | Email: stefan.doehla at iis.fraunhofer.de Multimedia Transport | Phone: +49 (0)9131 776 6042 (!NEW!) Audio Department | Fax: +49 (0)9131 776 6099 (!NEW!) Fraunhofer IIS | Am Wolfmantel 33 | 91058 Erlangen, Germany | Web: http://www.iis.fraunhofer.de/amm