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
<https://github.com/orgs/mdn/discussions/248> and this bug I filed on
Chrome Status a year ago
<https://github.com/GoogleChrome/chromium-dashboard/issues/2801>.)
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
<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,
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
<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
<https://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33>
Specification
https://www.w3.org/TR/webcodecs/#dom-videoframe-copyto
<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
<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
<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
<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
<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
<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
<mailto: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/221f4af8-b6b4-4d36-9225-3a8594dc5b14n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/221f4af8-b6b4-4d36-9225-3a8594dc5b14n%40chromium.org?utm_medium=email&utm_source=footer>.
--
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/c6cdcdbd-1a21-4202-95b1-78eca60d0c5f%40gmail.com.
