LGTM3 On Wednesday, November 5, 2025 at 8:08:01 AM UTC-8 Vladimir Levin wrote:
> 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/8eeddf3e-78bf-4da2-a8b0-da0037ba7c11n%40chromium.org.
