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. > > > 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/1c8fac486ca9f402be85074166e89a16 >> >> 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 Statushttps://chromestatus.com/featu >> re/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/CAOC%3DiPJbNkdo3wLR%2B56L1Ceu9yagb_5Otoj7OzJTToX4GNKa7g%40mail.gmail.com.
