Hey, I'm curious about the choice of either having rtpTimestamp if it's present in the underlying metadata and not having the field at all if it's not there, as opposed to having the field with some undefined value. Can you comment on this?
I'm not sure if that's a common pattern in this space Thanks, Vlad On Thursday, October 23, 2025 at 1:10:23 PM UTC-4 Dale Curtis wrote: > Also, to clarify your "in concert" remark for other readers, the > complimentary WebCodecs' class to RTCEncodedVideoFrame is > EncodedVideoChunk, not VideoFrame. > > - dale > > On Thu, Oct 23, 2025 at 10:07 AM Dale Curtis <[email protected]> > wrote: > >> I can't speak to RTCEncodedVideoFrame, but on VideoFrame metadata() >> matches the style of our other read-only accessors. >> >> - dale >> >> On Wed, Oct 22, 2025 at 9:46 PM 'Philipp Hancke' via blink-dev < >> [email protected]> wrote: >> >>> This makes a lot of sense but why did this end up as `.metadata()` when >>> >>> https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-getmetadata >>> which it is going to be used in concert with calls it `.getMetadata()`? >>> Guido or Harald might know... >>> >>> Has this shipped in other browsers or could this still be fixed? >>> >>> Am Mi., 22. Okt. 2025 um 23:37 Uhr schrieb 'Anantanarayanan Iyengar' via >>> blink-dev <[email protected]>: >>> >>>> *Contact emails* >>>> [email protected], [email protected] >>>> >>>> *Specification* >>>> >>>> https://www.w3.org/TR/webcodecs-video-frame-metadata-registry/#dom-videoframemetadata >>>> >>>> *Summary* >>>> Adds a VideoFrame.metadata() method that returns a dictionary >>>> containing the rtpTimestamp field, if the underlying VideoFrame has this >>>> field in its native metadata. An empty dictionary is returned otherwise. >>>> Only video frames originating from WebRTC sources will have the >>>> rtpTimestamp metadata attached. Additional metadata fields are already >>>> present in the native implementation and may be exposed to JavaScript over >>>> time, as outlined in the proposed spec: >>>> https://www.w3.org/TR/webcodecs-video-frame-metadata-registry/#dom-videoframemetadata >>>> >>>> *Blink component* >>>> Blink>Media>WebCodecs >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EMedia%3EWebCodecs%22> >>>> >>>> *Web Feature ID* >>>> webcodecs <https://webstatus.dev/features/webcodecs> >>>> >>>> *Motivation* >>>> This feature exposes the rtpTimestamp field on the JavaScript facing >>>> VideoFrame.metadata dictionary when it is present in the underlying native >>>> media::VideoFrameMetadata. It allows applications using >>>> MediaStreamTrackProcessor (e.g., to render decoded WebRTC frames to a >>>> canvas) or WebCodecs (e.g., for custom decoding pipelines) to correlate >>>> each exposed frame with its original RTP transport timestamp. This is >>>> useful for: Media synchronization across tracks Jitter or latency >>>> diagnostics Aligning decoded video with captured or received audio Spec >>>> link: >>>> https://www.w3.org/TR/webcodecs-video-frame-metadata-registry/#dom-videoframemetadata-rtptimestamp >>>> Chromium >>>> implementation CL: >>>> https://chromium-review.googlesource.com/c/chromium/src/+/6499588 Chromium >>>> bug: https://crbug.com/414545889 >>>> >>>> *Initial public proposal* >>>> *No information provided* >>>> >>>> *TAG review* >>>> *No information provided* >>>> >>>> *TAG review status* >>>> Not applicable >>>> >>>> *Risks* >>>> >>>> >>>> *Interoperability and Compatibility* >>>> The feature is additive and backward compatible. Existing WebCodecs and >>>> WebRTC APIs remain unchanged. >>>> No known interop issues. WPT coverage validates expected >>>> behavior. Firefox and WebKit positions are pending. >>>> >>>> *Gecko*: No signal ( >>>> https://github.com/mozilla/standards-positions/issues/1233) Position >>>> request filed on May 19, 2025. Awaiting response. >>>> >>>> *WebKit*: No signal ( >>>> https://github.com/WebKit/standards-positions/issues/497) Position >>>> request filed on May 19, 2025. Awaiting a response from WebKit. >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: >>>> >>>> *WebView application risks* >>>> *Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications?* >>>> None. This feature only exposes additional read only metadata >>>> (rtpTimestamp) on VideoFrame objects that are already surfaced through >>>> WebCodecs and WebRTC pipelines. No changes to existing Android WebView >>>> behavior or APIs. Safe for WebView. >>>> >>>> >>>> *Debuggability* >>>> No impact to DevTools workflows. Feature testing is via JS API >>>> inspection and WPT automation. >>>> VideoFrame metadata inspection (including rtpTimestamp) can be done via >>>> Javascript using MediaStreamTrackProcessor and WebCodecs/WebRTC or >>>> automated via WebDriver BiDi tests. >>>> >>>> *Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>> Yes >>>> >>>> *Is this feature fully tested by **web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>* >>>> *?* >>>> Yes >>>> >>>> https://wpt.fyi/results/webcodecs/videoFrame-metadata-rtpTimestamp.https.html?label=experimental&label=master&aligned >>>> >>>> *Flag name on about://flags* >>>> --enable-blink-features=VideoFrameMetadataRtpTimestamp >>>> >>>> *Finch feature name* >>>> None. Rollout is via milestone 146 stable. No finch experiment planned. >>>> >>>> *Non-finch justification* >>>> The feature is additive and backward compatible. Existing WebCodecs and >>>> WebRTC APIs remain unchanged. >>>> >>>> *Rollout plan* >>>> Will ship enabled for all users >>>> >>>> *Requires code in //chrome?* >>>> False >>>> >>>> *Availability expectation* >>>> Available by default in Chrome 146 for all desktop platforms. Mobile >>>> availability (Android) expected to follow in the same milestone. >>>> >>>> *Adoption expectation* >>>> Expected to be adopted by WebRTC and streaming applications that >>>> correlate decoded VideoFrame metadata with RTP timestamps for >>>> synchronization and telemetry. This includes browser based streaming >>>> clients that use MediaStreamTrackProcessor. >>>> >>>> *Adoption plan* >>>> Ship enabled by default for all users in Chrome 146. Coordinate with >>>> developers via WPT test results and the published ChromeStatus entry. No >>>> developer facing migration required. >>>> >>>> *Non-OSS dependencies* >>>> *Does the feature depend on any code or APIs outside the Chromium open >>>> source repository and its open-source dependencies to function?* >>>> None. The feature is implemented entirely within Chromium’s open source >>>> stack (WebRTC, Blink, and WebCodecs) >>>> >>>> *Estimated milestones* >>>> Shipping on desktop >>>> 146 >>>> Shipping on Android >>>> 146 >>>> Shipping on WebView >>>> 146 >>>> >>>> *Anticipated spec changes* >>>> *Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>> of >>>> the API in a non-backward-compatible way).* >>>> None expected. This feature implements the rtpTimestamp entry in the >>>> WebCodecs VideoFrame Metadata Registry and matches the current registry >>>> text (name, type, and semantics). The registry status is “W3C Draft >>>> Registry,” but any further edits we expect to be editorial or additive. If >>>> a normative change were proposed (e.g., semantics/units' clarification or >>>> constraints), we would align Chromium accordingly and update tests. >>>> >>>> *Link to entry on the Chrome Platform Status* >>>> https://chromestatus.com/feature/5186046555586560?gate=5179324311011328 >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com/>. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH7PR12MB87961707EEA95FF947A2DBC9A6F3A%40PH7PR12MB8796.namprd12.prod.outlook.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH7PR12MB87961707EEA95FF947A2DBC9A6F3A%40PH7PR12MB8796.namprd12.prod.outlook.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJDF4pNvQ_dvZ2FdC89PyETNhQPXWdeB_JCysiPeNLLOQ%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJDF4pNvQ_dvZ2FdC89PyETNhQPXWdeB_JCysiPeNLLOQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc71eb60-8c80-4d92-b528-3fe5a0f8691dn%40chromium.org.
