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/CAK8JDrEBF9dcFqcGVipYvMOXW4OdcLW7A40Y%2B3ui6XZ%2Br3bTQw%40mail.gmail.com.
