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/CAPUDrwf81y1vEohWApCuVQRM4Mc9CrH7_MuMdEGWcr8Va0k-jQ%40mail.gmail.com.

Reply via email to