That makes sense thanks. LGTM2
On Wednesday, October 29, 2025 at 12:44:56 PM UTC-4 Dale Curtis wrote: > I'm not sure how that would work for primitive types without an optional > type or requiring a sentinel value specified. Specifying a sentinel value > can be prohibitive since some fields may be carried over from legacy specs. > Can you elaborate? > > See > https://source.chromium.org/chromium/chromium/src/+/main:media/base/video_frame_metadata.h > > for the internal version this is shaped after. Generally the optional type > is also useful for constraining memory usage if the carried type is large. > > - dale > > On Wed, Oct 29, 2025 at 8:15 AM Vladimir Levin <[email protected]> > wrote: > >> 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/ca992157-21e4-438a-9972-5df425978bd6n%40chromium.org.
