[AVTCORE] Re: New draft: Absolute Capture Timestamp RTP header extension

[Bernard Aboba <[e-mail]>]

I am also interested in seeing this draft advanced.

Some comments:

Section 1

"However, when multiple hops and multiple systems are involved, this task
becomes more difficult; in particular, when one desires to synchronize
media from multiple sources with independent clocks, where the media may
have traveled over multiple network hops between the source and
destination.This memo describes one mechanism for providing more
information to make such synchronization possible."

[BA]  Is the sole use case for this document "lip sync" from a single
source?  Or are other use cases possible too (e.g. synchronized concert)?

As written, this section could be interpreted to apply to a wide range of
RTP topologies described in RFC 7667. Since RTCP termination is mentioned
in Section 3, this does not appear to be the intent.  I'd suggest adding a
paragraph describing the RTP topologies to which this specification applies
(e.g. Section 3.6 and 3.7 of RFC 7667)

Section 3.1.2.1

" Absolute capture timestamp is the NTP timestamp of when the first frame
in a packet was originally captured. This timestamp MUST be based on the
same clock as the clock used to generate NTP timestamps for RTCP sender
reports on the capture system."

[BA] Does this imply that the RTCP SR NTP timestamp from the capturing
system is placed in this field?

Section 3.1.2.2

   Estimated capture clock offset is the sender's estimate of the offset
   between its own NTP clock and the capture system's NTP clock.  The
   sender is here defined as the system that owns the NTP clock used to
   generate the NTP timestamps for the RTCP sender reports on this
   stream.  The sender system is typically either the capture system or
   a mixer.


[BA] In an RTCP-terminating topology wouldn't the mixer/SFM be the
sender?  In what topology would the capture system be the sender?


Section 3.1.3.2

   An intermediate system (e.g. mixer) MAY adjust these timestamps as
   needed.  It MAY also choose to rewrite the timestamps completely,
   using its own NTP clock as reference clock, if it wants to present
   itself as a capture system for A/V-sync purposes.


[BA] Wouldn't this behavior be governed by the topology? For example, an
RTCP-terminating middle box uses its own NTP clock, but presumably a
translator would not.

On Wed, Oct 30, 2024 at 10:57 AM Sergio Garcia Murillo <
[e-mail]> wrote:

> Hi all, as I probably won't be able to make it to next Monday's meeting, I
> would like to express my support for this header extension in advance.
>
> At Dolby Millicast we have been extensively using the non-standard version
> available in Google Chrome extensively, both for calculating e2e delays and
> for synchronization of media and metadata, being much more easy to handle
> that the codec specific counterparts (like the H264 SEI pic timing).
>
> Being able to standardize it would allow us to expose it in the w3c apis
> and make it easier to obtain from javascript.
>
> Best regards
> Sergio
>
> On Fri, Oct 4, 2024 at 10:26 AM Harald Alvestrand <[e-mail]>
> wrote:
>
>> I have now submitted an I-D based on the technology I presented at the
>> last IETF about "absolute" timestamps for RTP.
>>
>> It is here:
>>
>> https://datatracker.ietf.org/doc/draft-alvestrand-avtcore-abs-capture-time/
>>
>> I plan to ask for agenda time in Dublin to discuss the draft.
>> Comments welcome - the source is on github here:
>>
>> https://github.com/alvestrand/id-abs-capture-timestamp
>>
>> Harald
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> To unsubscribe send an email to [e-mail]
>