Should we add captureTimestamp senderCaptureTimeOffset to the RTCEncodedXXXFrameMetadata if abs-capture-time is used?

[murillo128]

In the https://w3c.github.io/webrtc-extensions/ we define the captureTimestamp and senderCaptureTimeOffset at contribution source level, however this information is available on a per frame level too.

I believe it would be interesting to be able to expose the same both values in the RTCEncodedAudioFrameMetadata and RTCEncodedVideoFrameMetadata when the abs capture time header extension is used.

Related: PR 137

[tonyherre]

+1 would be great to have. I'd say it should ~always be exposed for locally captured frames, like how we have for requestVideoFrameCallback, and exposed for remote frames if and only if the abs-capture-time is sent.

@Orphis FYI

[stefanholmer]

It would also be useful to add the receiveTime on the receiver-side, in the same way we do for requestVideoFrameCallback.

[guidou]

cc @tonyherre

[dontcallmedom-bot]

This issue had an associated resolution in WebRTC Interim, May 21st – 21 May 2024 (Issue 225: Add captureTimestamp senderCaptureTimeOffset to the encoded frame metadata):

RESOLUTION: next step on issue 225 is to review the PR