On Wed, Aug 23, 2023 at 12:26 PM Jonathan Hao <p...@chromium.org> wrote:
> Thanks for the clarification! > > On Tue, Aug 22, 2023 at 9:20 PM Eugene Zemtsov <ezemt...@google.com> > wrote: > >> A transfer list is consistent with the approach taken by structuredClone >> <https://developer.mozilla.org/en-US/docs/Web/API/structuredClone> and >> postMessage >> <https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage>. >> And it's already a part of the WebCodecs spec. >> > Can you clarify if this was in response to my questions or to Jonathan's? > >> >> On Tue, Aug 22, 2023 at 7:36 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> >>> >>> On Tuesday, August 22, 2023 at 11:08:24 AM UTC+2 Jonathan Hao wrote: >>> >>> Hi Eugene, >>> >>> Just to double check. Once an ArrayBuffer is transferred and detached, >>> any further access will result in some sort of TypeError, right? >>> >>> Thanks, >>> Jonathan >>> >>> On Wednesday, August 16, 2023 at 10:22:00 PM UTC+1 Eugene Zemtsov wrote: >>> >>> Contact emailsezemt...@google.com >>> >>> Explainerhttps://gist.github.com/Djuffin/1c8fac486ca9f402be85074166e8 >>> 9a16 >>> >>> Specificationhttps://www.w3.org/TR/webcodecs/#dictdef-videoframeinit >>> >>> Summary >>> >>> This will allow detaching array buffers and using corresponding buffers >>> inside VideoFrame, ImageDecoder, EncodedVideoChunk, EncodedAudioChunk, >>> AudioData without a copy. >>> >>> Blink componentBlink>Media>WebCodecs >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EWebCodecs> >>> >>> TAG reviewNone >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> None >>> >>> >>> *Gecko*: N/A (https://www.w3.org/2023/05/30-mediawg-minutes.html#t01) >>> Change is too small to justify this effort. The change was discussed and >>> approved by the w3c media working group. >>> >>> *WebKit*: N/A (https://www.w3.org/2023/05/30-mediawg-minutes.html#t01) >>> Change is too small to justify this effort. The change was discussed and >>> approved by the w3c media working group. >>> >>> >>> I somewhat share Youenn's concerns about the API shape, but I'm not >>> familiar with the examples this is supposed to be consistent with. Would it >>> be possible to explore different API shapes in the explainer? (e.g. a >>> boolean that detaches the input buffer after init would be my first choice) >>> Typically we defer such questions to a TAG review. I'd hate to introduce >>> significant delay at this point, but it might be possible to expedite this >>> specific question and get it in front of them. >>> >>> >>> >>> *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 >>> >>> >>> Debuggability >>> >>> None >>> >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?No >>> >>> Flag name on chrome://flagsNone >>> >>> Finch feature nameNone >>> >>> Non-finch justificationNone >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://crbug.com/1446808 >>> >>> Estimated milestonesShipping on desktop120Shipping on Android120 >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5075602045927424 >>> >>> -- >>> 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/CAL5BFfVcyRWBnxT9Y9yb5Wq6VK_oUEzjejSUbLwQwJOv%3DcYVGg%40mail.gmail.com.
