VideoFrameMetadata.captureTime: Spec language unnecessarily restricts implementation.

[handellm]

The wording around VideoFrameMetadata.captureTime excludes implementations that can do remote NTP timestamp estimation in the presence of mixers. According to RFC 3550, section 7.3, in the presence of mixers the forwarding of SR reports is forbidden and hence captureTime cannot be computed given this spec's wording that says:

For a remote source, the capture time is estimated using clock synchronization and RTCP sender reports to convert RTP timestamps to capture time as specified in RFC 3550 Section 6.4.1.

There are other ways of estimating the remote capture NTP timestamp, for example through use of the abs-capture-time header extension, that could be used to fill the field.

The spirit from the spec authors wasn't really to restrict the implementation to exclude alternative implementations. Can we fix the wording to include alternative means and thereby increase the usefulness of this field?

For example by changing the wording to something like: "For a remote source, the capture time is estimated using clock synchronization. This is best effort and can use methods like using RTCP SR as specified in RFC 3550 Section 6.4.1, or by other alternative means if use by RTCP SR isn't feasible.".

[tguilbert-google]

This seems good to me. Any objections @smfr or @padenot?

[drkron]

I think that this looks good too!

Since I was part of formulating the original text, I can confirm that the intention from my side was never to restrict the implementation.

[padenot]

No problem with this.

[tguilbert-google]

Thanks for the input!