Add rtp timestamp and capture time to RTCEncodedVideoFrameMetadata

[nisse-work]

Add both RTP timestamp and captureTime to RTCEncodedVideoFrameMetadata. On the send side, the capture time should equal the timestamp of the corresponding unencoded VideoFrame. On the receive side, it is best effort.

---

Preview | Diff

[nisse-work]

Not sure what type and name to use for best consistency. VideoFrame uses the name "timestamp" and the "long long" type, https://w3c.github.io/webcodecs/#dom-videoframe-timestamp. While VideoFrameMetadata use name "captureTime" and type "DOMHighResTimeStamp", see https://wicg.github.io/video-rvfc/#dom-videoframemetadata-capturetime.

[fippo]

I wonder if we should have rtpTimestamp and payload type at the root level which frees up names like timestamp for metadata...

[nisse-work]

I really don't have an informed opinion on naming (and typing). It's not clear to me why we have RTCEncodedVideoFrame.type and .timestamp, and all other metadata in RTCEncodedVideoFrameMetadata.

So I'll adapt to anything the w3c experts say.

[alvestrand]

what clock is the capture timestamp in? (in particular for remotely-sourced frames or frames from files)?

[nisse-work]

That's a very good question. For consistency, I'd prefer that it's whatever goes in https://w3c.github.io/webcodecs/#dom-videoframe-timestamp on correspponding unencoded frame, but docs aren't crystal clear on what clock that uses. It is marked as "nullable" there, so perhaps it's not provided in all cases?

[alvestrand]

Need to investgate:

• What we can do to align with webcodecs
• Whether the packetizer needs this information

[aboba]

Both capture time and RTP timestamp are provided in the RVFC specification (for VideoFrame).

[alvestrand]

Perhaps Tony Herre can pick this up?

[Orphis]

@tonyherre

[tonyherre]

I finally got round to opening #173 as essentially an adoption of this PR, incorporating the RVFC references.