Re: [EXTERNAL] Call for Consensus (CfC) on Adoption of the Insertable Streams API specification

Agreed this sounds like the right path forward.

On Fri, Jun 5, 2020 at 3:55 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
> On Fri, Jun 5, 2020 at 1:46 AM Youenn Fablet <youenn@apple.com> wrote:
>
>> Following on yesterday interim meeting, it seems there is consensus that
>> e2e encryption is of great interest to people interested in insertable
>> streams.
>> We also want in a not-too-far future that web sites will not have to do
>> their own crypto to implement it.
>>
>> Based on that, I think we should make a requirement that insertable
>> streams be able to support native nodes/transforms, at least one dedicated
>> to encrypting media.
>> In parallel to working on insertable streams, or as part of it, we should
>> actually define such a transform, probably based on the SFrame proposal.
>>
>
> This seems like the right course of action
>
> -Ekr
>
> We can hopefully isolate key management like HTMLMediaElement did with EME.
>>
>> I see several advantages:
>> - We can ship features progressively with good confidence that we will
>> not get stuck in a JS-only solution
>> - We lay down a foundation where insertable streams is reusable with a
>> key management system built in the browser (MLS?)
>> - By specifying this specific transform, we will define hooks in the
>> insertable stream spec required for this transform, some of these hooks
>> surfacing at the JS level for proper polyfilling
>>
>> On 3 Jun 2020, at 07:52, Stefan Håkansson LK <
>> stefan.lk.hakansson@ericsson.com> wrote:
>>
>> Thanks Bernard, sounds good. So a follow question could be: couldInsertable
>> Streams somehow provide handles to GPU buffers which could enable WebGPU
>> operations? Just thinking out loud (I should go and do some
>> investigation myself).
>>
>> *From: *Bernard Aboba <Bernard.Aboba@microsoft.com>
>> *Date: *Tuesday, 2 June 2020 at 19:58
>> *To: *Stefan LK <stefan.lk.hakansson@ericsson.com>
>> *Cc: *"public-webrtc@w3.org" <public-webrtc@w3.org>
>> *Subject: *Re: [EXTERNAL] Re: Call for Consensus (CfC) on Adoption of
>> the Insertable Streams API specification
>>
>> On Jun 2, 2020, at 2:00 AM, Stefan Håkansson LK <
>> stefan.lk.hakansson@ericsson.com> wrote:
>>
>>
>>
>> I’d like to see more work to determine if this model is also suitable for
>> accessing raw media, and I’d also like to see overlap/sync vis a vis
>> WebCodecs investigated.
>> Regarding N22: would it be worth looking into whether WebGPU (
>> https://gpuweb.github.io/gpuweb/
>> <https://protect2.fireeye.com/v1/url?k=8f90bc3a-d1307e7c-8f90fca1-86fc6812c361-7251295517553986&q=1&e=daa517f5-5c14-48d2-a604-2f6cad31d9ac&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgpuweb.github.io%252Fgpuweb%252F%26data%3D02%257C01%257CBernard.Aboba%2540microsoft.com%257C8db5a4fef3a94a7679e408d806d32991%257C72f988bf86f141af91ab2d7cd011db47%257C0%257C0%257C637266852299530210%26sdata%3D%252BaA%252FeU2LsVhlpAjFBioVPdLOdsoygrQ3yzN8yo0ui6w%253D%26reserved%3D0>)
>> could be useful?
>>
>>
>> [BA] Excellent points. Raw media is much larger than encoded, so
>> performance is a concern. One thing under discussion in WebCodecs is
>> whether it might be useful to provide handles to GPU buffers which could
>> enable WebGPU operations on raw (or encoded) media.
>>
>> Prototyping of WHATWG stream support in WebCodecs did not go well, and
>> issues relating to WebRTC parity and DRM support have been raised. So at
>> present Insertable Streams is much closer to a “bird in the hand” although
>> we are not sure what songs this bird may be able to sing.
>>
>>
>>