Hi Tony, Please make a chromestatus.com entry for this change, we need them for all changes to the platform, so they can be tracked in release notes and elsewhere. (And as Yoav mentioned, it's why this intent was missed during our API owners triage process.)
As for signals: please file one for Gecko and Webkit, thanks. On Wed, May 31, 2023 at 12:47 AM 'Tony Herre' via blink-dev < [email protected]> wrote: > Bubbling this up as I suspect it has fallen through the process again. > > Is there any further information or actions I need to take here to unblock? > > Thanks > Tony > > Den fre 12 maj 2023 11:35Tony Herre <[email protected]> skrev: > >> Re TAG, the original review for this API was >> https://github.com/w3ctag/design-reviews/issues/531. >> >> Re signals, looks like this would have been better expressed as "no >> signal" from other UAs to capture the formal stance, with just a note about >> informal support in the WG. >> I would suggest it wouldn't be worth requesting due to the "Change is >> too small to justify this effort" >> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.t7vajzawd07s> >> caveat in the blink-signals doc - please let me know if others disagree and >> I can get this kicked off. >> >> >> Thanks for all the process references! I'll be sure to leave the template >> headings in-place in future Intents, so hopefully will go through a lot >> smoother. >> >> Thanks, >> Tony >> On Thursday, 11 May 2023 at 16:22:25 UTC+2 Yoav Weiss wrote: >> >>> As pointed out, this seems to be missing a bunch of fields from the >>> broader template.. >>> >>> >>> On Thu, May 11, 2023 at 2:20 PM Yoav Weiss <[email protected]> wrote: >>> >>>> >>>> >>>> On Tue, May 2, 2023 at 4:29 PM 'Tony Herre' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected], [email protected] >>>>> >>>>> >>> An explainer is missing, but you provided an inline one above, which is >>> good enough from my perspective. >>> >>> A TAG review checkpoint is also missing. At the same time, we probably >>> don't need to file for one here. >>> >>> >>>> Spec >>>>> https://w3c.github.io/webrtc-encoded-transform/#RTCEncodedVideoFrameMetadata >>>>> particularly >>>>> PR#173 <https://github.com/w3c/webrtc-encoded-transform/pull/173>. >>>>> >>>>> >>>>> Summary >>>>> >>>>> Add a 'timestamp' field to RTCEncodedVideoFrameMetadata containing the >>>>> presentation timestamp of the associated encoded video frame. >>>>> >>>>> Is this feature supported on all six Blink platforms (Windows, Mac, >>>>> Linux, Chrome OS, Android, and Android WebView)? >>>>> >>>>> Yes >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> Positive response from all members at W3C WebRTC WG April 2023 >>>>> Interim, PR landed with no open issues. >>>>> >>>> >>> While I agree that there seems to be general support on the PR, we >>> typically require formal https://bit.ly/blink-signals >>> >>> >>>> >>>>> Ergonomics >>>>> >>>>> Added specifically to align with the timestamp field on the WebCodecs >>>>> <https://www.w3.org/TR/webcodecs/#encodedvideochunk-interface> >>>>> EncodedVideoChunk >>>>> <https://www.w3.org/TR/webcodecs/#encodedvideochunk-interface>, and >>>>> allow matching video frames with the timestamp in the WebCodecs >>>>> VideoFrame <https://www.w3.org/TR/webcodecs/#videoframe-interface> >>>>> object. >>>>> >>>>> Will also provide the same timestamp already exposed in >>>>> requestVideoFrameCallback's 'mediaTime'. >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> Tested internally by RTCEncodedVideoFrame-capture-timestamp-id.html >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/peerconnection/RTCEncodedVideoFrame-capture-timestamp-id.html>, >>>>> upstreaming to WPT tracked in crbug.com/1441888. >>>>> >>>> >>> It seems easier to land WPT directly with a ".tentative" suffix, and >>> then rename them. >>> >>> >>>> >>>>> >>>>> Entry on the feature dashboard >>>>> >>>>> None, small delta to launched API. >>>>> >>>> >>>> I suspect this resulted in this intent not being captured in our >>>> tooling :/ >>>> +Jason Robbins - FYI >>>> >>>>> -- >>>>> 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 on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAArnMxH%2BNJKi80S4822wmjtQUqid8czA9AefCC_fm%3DHk3sTuiw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAArnMxH%2BNJKi80S4822wmjtQUqid8czA9AefCC_fm%3DHk3sTuiw%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 on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAArnMxEzMsTFwiO%3DXYz7bZf4rjuv6mHzUubOrPke6jZ%3DukdpLQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAArnMxEzMsTFwiO%3DXYz7bZf4rjuv6mHzUubOrPke6jZ%3DukdpLQ%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8H-CcAeZap7GOWkhCsxSin%3DJNEc35%3D%2Bz2KDcsRqftukA%40mail.gmail.com.
