LGTM1 On Thu, Oct 23, 2025 at 10:10 AM Dale Curtis <[email protected]> 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/CAPUDrwf81y1vEohWApCuVQRM4Mc9CrH7_MuMdEGWcr8Va0k-jQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwf81y1vEohWApCuVQRM4Mc9CrH7_MuMdEGWcr8Va0k-jQ%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/CAOMQ%2Bw_ess8h552Hvd7SmKpJM-R87qJGDejd6mv91od9tk1tyw%40mail.gmail.com.
