LGTM3 On Wed, May 15, 2024 at 6:02 PM Daniel Bratell <bratel...@gmail.com> wrote:
> LGTM2 > > /Daniel > On 2024-05-15 07:13, Domenic Denicola wrote: > > LGTM1. > > I have a small non-blocking request: update your Chrome Status entry to > avoid using ClassName.staticMethod() syntax for what appears to be an > instance method. (See e.g. this related discussion > <https://github.com/orgs/mdn/discussions/248> and this bug I filed on > Chrome Status a year ago > <https://github.com/GoogleChrome/chromium-dashboard/issues/2801>.) This > will avoid a confusing experience for web developers when this information > makes its way into the beta blog post and other documentation. > > On Wednesday, May 15, 2024 at 5:49:30 AM UTC+9 Eugene Zemtsov wrote: > >> By reading an MDN article that I'll update after the launch. >> >> Even now allocationSize() is supposed to be called before copyTo() >> anyway, to figure out the size of the buffer for the output. (see example >> <https://developer.mozilla.org/en-US/docs/Web/API/VideoFrame/copyTo#examples>1, >> example2 >> <https://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33#example> >> ) >> That's why I don't think that it's an ergonomic burden for developers. >> >> On Tue, May 14, 2024 at 1:41 PM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> Ergonomics-wise, it does not seem intuitive to use a method called >>> allocationSize() to feature detect copyTo support, even if the semantics >>> are the same. Besides a very careful reading of the spec, how do we expect >>> developers to know about it? >>> On 5/14/24 4:32 PM, Eugene Zemtsov wrote: >>> >>> In that discussion Marcos Cáceres asked for a synchronous way to detect >>> if format conversion is supported. >>> We have a synchronous call allocationSize() >>> <https://www.w3.org/TR/webcodecs/#dom-videoframe-allocationsize> that >>> throws an unsupported error in cases where format conversion is not >>> supported. >>> I added a WPT test around it in a recent CL >>> <https://chromium-review.googlesource.com/c/chromium/src/+/5530313>. >>> >>> canCopyTo() might be needed if we have more settings in >>> VideoFrameCopyToOptions >>> <https://www.w3.org/TR/webcodecs/#dictdef-videoframecopytooptions> and >>> might want to know which part exactly is causing an error. >>> >>> On Tue, May 14, 2024 at 12:25 PM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> I see that WebKit raised an API concern around detectability >>>> <https://github.com/WebKit/standards-positions/issues/341#issuecomment-2099746809>. >>>> In your reply, you said "we should consider...". Has that consideration >>>> happened, perhaps as follow-up work? :) >>>> On 5/8/24 4:05 PM, Eugene Zemtsov wrote: >>>> >>>> This feature has Privacy, Security, Enterprise, and Debuggability >>>> approvals. Webkit gave a positive signal. >>>> >>>> Any objections or questions from the API owners? >>>> >>>> >>>> >>>> On Wed, May 1, 2024 at 4:26 PM Eugene Zemtsov <ezemt...@google.com> >>>> wrote: >>>> >>>>> I've filed issues for TAG review and firefox and webkit positions. >>>>> >>>>> > Have you looked into other platform APIs that could benefit from >>>>> being able to explicitly specify intermediate format hinting and/or >>>>> transformation? >>>>> I don't think this kind of review can be done for all web APIs by one >>>>> person. It's up to spec editors in each area to identify these small >>>>> changes that improve dev experience and performance. >>>>> >>>>> For media related things: >>>>> - VideoFrame is a versatile tool that can be created from >>>>> HTMLOrSVGImageElement, HTMLVideoElement, HTMLCanvasElement, >>>>> ImageBitmap, >>>>> OffscreenCanvas without a copy. In a way this change extends >>>>> variety of export formats for all of them. >>>>> So lots of things can be exported to RGB bitmaps without a canvas >>>>> now. >>>>> - AudioData has a way to be exported into different sampling formats. >>>>> >>>>> >>>>> >>>>> On Wed, May 1, 2024 at 9:41 AM Mike Taylor <miketa...@chromium.org> >>>>> wrote: >>>>> >>>>>> +1. Would you mind also filing gecko and webkit positions? I expect >>>>>> them to be positive, given the informal signals you have in the spec PRs >>>>>> already - but this also lets them know we're moving ahead with shipping. >>>>>> Thanks - Mike >>>>>> On 5/1/24 11:51 AM, Alex Russell wrote: >>>>>> >>>>>> hey Eugene, >>>>>> >>>>>> This is an exciting an useful addition! Have you looked into other >>>>>> platform APIs that could benefit from being able to explicitly specify >>>>>> intermediate format hinting and/or transformation? It's a place where >>>>>> (had >>>>>> the TAG been consulted) I would have expected to see a larger chain of >>>>>> additions to make this work in other areas, or at least a discussion of >>>>>> why >>>>>> they aren't (or are?) being pursued. Have you looked into that? >>>>>> >>>>>> Best, >>>>>> >>>>>> Alex >>>>>> >>>>>> On Tuesday, April 30, 2024 at 3:51:01 PM UTC-7 Eugene Zemtsov wrote: >>>>>> >>>>>>> > Can you please request reviews for privacy, security, enterprise, >>>>>>> etc in the chromestatus entry? >>>>>>> >>>>>>> Done >>>>>>> >>>>>>> On Mon, Apr 29, 2024 at 7:44 AM Mike Taylor <miketa...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Can you please request reviews for privacy, security, enterprise, >>>>>>>> etc in the chromestatus entry? >>>>>>>> On 4/25/24 6:19 PM, 'Eugene Zemtsov' via blink-dev wrote: >>>>>>>> >>>>>>>> Contact emails ezemt...@google.com >>>>>>>> >>>>>>>> Explainer >>>>>>>> https://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33 >>>>>>>> >>>>>>>> Specification >>>>>>>> https://www.w3.org/TR/webcodecs/#dom-videoframe-copyto >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> VideoFrame.copyTo() can convert pixel data to RGB pixel format >>>>>>>> Converting YUV video frames to RGB is often required for processing >>>>>>>> them in >>>>>>>> libraries like TensorFlow.js and OpenCV.js. Previously the only >>>>>>>> possible >>>>>>>> way to achieve this was rendering the frame on a canvas. Specifying >>>>>>>> VideoFrameCopyToOptions.format and VideoFrameCopyToOptions.colorSpace >>>>>>>> makes >>>>>>>> it possible to convert frames to RGB pixel formats by calling >>>>>>>> VideoFrame.copyTo() without having to use an extra canvas. >>>>>>>> >>>>>>>> Blink component Blink>Media>WebCodecs >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EWebCodecs> >>>>>>>> >>>>>>>> Initial public proposal https://github.com/w3c/webcodecs/issues/92 >>>>>>>> >>>>>>>> TAG review N/A since the change is minor >>>>>>>> >>>>>>>> Risks >>>>>>>> >>>>>>>> >>>>>>>> Interoperability and Compatibility >>>>>>>> >>>>>>>> None >>>>>>>> >>>>>>>> >>>>>>>> *Gecko*: Positive ( >>>>>>>> https://github.com/w3c/webcodecs/pull/754#pullrequestreview-2008590591 >>>>>>>> ) >>>>>>>> >>>>>>>> *WebKit*: Positive TPAC 2023. Media working group session. >>>>>>>> >>>>>>>> *Web developers*: >>>>>>>> https://github.com/w3c/webcodecs/issues/92#issuecomment-1594083978 >>>>>>>> >>>>>>>> *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 >>>>>>>> >>>>>>>> >>>>>>>> Debuggability >>>>>>>> >>>>>>>> None >>>>>>>> >>>>>>>> >>>>>>>> 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-copyTo-rgb.any.js >>>>>>>> >>>>>>>> >>>>>>>> Estimated milestones >>>>>>>> Shipping on desktop 126 >>>>>>>> Shipping on Android 126 >>>>>>>> >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>> https://chromestatus.com/feature/4668827056209920 >>>>>>>> >>>>>>>> -- >>>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK8JDrGyVMDipu_nqd%3DKw_9eE2UMtdbiWjbqac0NquwNmm4DMg%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK8JDrGyVMDipu_nqd%3DKw_9eE2UMtdbiWjbqac0NquwNmm4DMg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Eugene Zemtsov. >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Thanks, >>>>> Eugene Zemtsov. >>>>> >>>> >>>> >>>> -- >>>> Thanks, >>>> Eugene Zemtsov. >>>> >>>> >>> >>> -- >>> Thanks, >>> Eugene Zemtsov. >>> >>> >> >> -- >> Thanks, >> Eugene Zemtsov. >> > -- > 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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/221f4af8-b6b4-4d36-9225-3a8594dc5b14n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/221f4af8-b6b4-4d36-9225-3a8594dc5b14n%40chromium.org?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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c6cdcdbd-1a21-4202-95b1-78eca60d0c5f%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c6cdcdbd-1a21-4202-95b1-78eca60d0c5f%40gmail.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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLPwUKYhT0HaUnOMp64jaAAxnj%3DsqYeC0h4vw2j3TZFzw%40mail.gmail.com.
