Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Yoav Weiss (@Shopify)]

LGTM3

On Wed, May 15, 2024 at 6:02 PM Daniel Bratell  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
>  and this bug I filed on
> Chrome Status a year ago
> .) 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
>> 1,
>> example2
>> 
>> )
>> 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 
>> 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()
>>>  that
>>> throws an unsupported error in cases where format conversion is not
>>> supported.
>>> I added a WPT test around it in a recent CL
>>> .
>>>
>>> canCopyTo() might be needed if we have more settings in
>>> VideoFrameCopyToOptions
>>>  and
>>> might want to know which part exactly is causing an error.
>>>
>>> On Tue, May 14, 2024 at 12:25 PM Mike Taylor 
>>> wrote:
>>>
 I see that WebKit raised an API concern around detectability
 .
 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 
 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 
> 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?
>>>

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Daniel Bratell]

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 
 and this bug I filed on 
Chrome Status a year ago 
.) 
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

1,
example2
)

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
 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()
 that
throws an unsupported error in cases where format conversion
is not supported.
I added a WPT test around it in a recent CL
.

canCopyTo() might be needed if we have more settings in
VideoFrameCopyToOptions
 and
might want to know which part exactly is causing an error.

On Tue, May 14, 2024 at 12:25 PM Mike Taylor
 wrote:

I see that WebKit raised an API concern around
detectability

.
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
 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,
         OffscreenCanvaswithout a copy. In a way
this change extends variety of export formatsfor 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
 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
  

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Domenic Denicola]

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 
 and this bug I filed on 
Chrome Status a year ago 
.) 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 
> 1,
>  
> example2 
> 
> ) 
> 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  
> 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() 
>>  that 
>> throws an unsupported error in cases where format conversion is not 
>> supported. 
>> I added a WPT test around it in a recent CL 
>> .
>>
>> canCopyTo() might be needed if we have more settings in 
>> VideoFrameCopyToOptions 
>>  and 
>> might want to know which part exactly is causing an error. 
>>
>> On Tue, May 14, 2024 at 12:25 PM Mike Taylor  
>> wrote:
>>
>>> I see that WebKit raised an API concern around detectability 
>>> .
>>>  
>>> 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  
>>> 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  
 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  
>> wrote:
>>
>>> Can you please request reviews for privacy, security, enterprise, 
>>> etc in the 

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

['Eugene Zemtsov' via blink-dev]

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
1,
example2
)
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  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()
>  that
> throws an unsupported error in cases where format conversion is not
> supported.
> I added a WPT test around it in a recent CL
> .
>
> canCopyTo() might be needed if we have more settings in
> VideoFrameCopyToOptions
>  and
> might want to know which part exactly is causing an error.
>
> On Tue, May 14, 2024 at 12:25 PM Mike Taylor 
> wrote:
>
>> I see that WebKit raised an API concern around detectability
>> .
>> 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 
>> 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 
>>> 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 
> 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 

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Mike Taylor]

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() 
 that 
throws an unsupported error in cases where format conversion is not 
supported.
I added a WPT test around it in a recent CL 
.


canCopyTo() might be needed if we have more settings in 
VideoFrameCopyToOptions 
 and 
might want to know which part exactly is causing an error.


On Tue, May 14, 2024 at 12:25 PM Mike Taylor  
wrote:


I see that WebKit raised an API concern around detectability

.
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
 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,
         OffscreenCanvaswithout a copy. In a way this change
extends variety of export formatsfor 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
 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
 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

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

['Eugene Zemtsov' via blink-dev]

In that discussion Marcos Cáceres asked for a synchronous way to detect if
format conversion is supported.
We have a synchronous call 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
.

canCopyTo() might be needed if we have more settings in
VideoFrameCopyToOptions
 and
might want to know which part exactly is causing an error.

On Tue, May 14, 2024 at 12:25 PM Mike Taylor  wrote:

> I see that WebKit raised an API concern around detectability
> .
> 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  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 
>> 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 
 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
> 
>
> 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
> 

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Mike Taylor]

I see that WebKit raised an API concern around detectability 
. 
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  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,
         OffscreenCanvaswithout a copy. In a way this change
extends variety of export formatsfor 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
 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
 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




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

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

['Eugene Zemtsov' via blink-dev]

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  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  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 
>>> 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
 

 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
 
 ? 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
 

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

['Eugene Zemtsov' via blink-dev]

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  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 
>> 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
>>> 
>>>
>>> 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
>>> 
>>> ? 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
>>> 
>>> .
>>>
>>>
>>
>> --
>> 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 

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Mike Taylor]

+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
 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




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

?

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

.




-- 
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 

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Alex Russell]

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  
> 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 
>> 
>>
>> 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 
>> 
>> ? 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
>>  
>> 
>> .
>>
>>
>
> -- 
> 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/9b2e1d6e-be76-42ce-8e4f-73ebe0409ab2n%40chromium.org.

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

['Eugene Zemtsov' via blink-dev]

> 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  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
> 
>
> 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
> 
> ? 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
> 
> .
>
>

-- 
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/CAK8JDrF_ycwyYKh%2BCOELTG6do4%2BRqZrdvWEC_t62YCptH471sQ%40mail.gmail.com.

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Mike Taylor]

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 




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

?

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 
.


--
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/fd565a0c-88e1-4175-af53-40f173f942e4%40chromium.org.