Add rtp timestamp and capture time to RTCEncodedVideoFrameMetadata #137
Conversation
| @@ -287,6 +287,8 @@ enum RTCEncodedVideoFrameType { | |||
|
|
|||
| dictionary RTCEncodedVideoFrameMetadata { | |||
| long long frameId; | |||
| unsigned long rtpTimestamp; // RTP timestamp. | |||
| DOMHighResTimeStamp captureTime; | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I wonder if we should have rtpTimestamp and payload type at the root level which frees up names like timestamp for metadata...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
what clock is the capture timestamp in? (in particular for remotely-sourced frames or frames from files)?
There was a problem hiding this comment.
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?
|
Need to investgate:
|
|
Both capture time and RTP timestamp are provided in the RVFC specification (for VideoFrame). |
|
Perhaps Tony Herre can pick this up? |
|
I finally got round to opening #173 as essentially an adoption of this PR, incorporating the RVFC references. |
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