So what if we add two new attributes to RTCEncodedVideoFrameMetadata: * rtpTimestamp (required, representing the uint32_t RTP timestamp) * timestamp (optional, intended to match VideoFrame.timestamp. It's clear to me how that should work on the send side. Less clear on the receive side, could perhaps be conditionally populated depending on presence of absolute capture time extension). Does that make sense? We could then consider deprecating the current timestamp attribute which isn't in the "metadata". -- GitHub Notification of comment by nisse-work Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/135#issuecomment-1152268567 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-configReceived on Friday, 10 June 2022 11:37:59 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:57 UTC