- From: chcunningham via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 May 2021 04:05:01 +0000
- To: public-webrtc-logs@w3.org
Answering just the questions for WebCodecs. @sandersdan @dalecurtis > 6. Unclear memory I/O design given that a VideoFrame may be in GPU memory #34 (Funny hat: GPU→CPU→GPU?) VideoFrame is ([will be](https://github.com/whatwg/html/pull/6589)) a CanvasImageSource. GPU:CPU copies are not required to do funny hats (e.g. use canvas drawImage() or webGL texImage2d()). Similar to ImageBitmap, WebCodecs does not describe the precise location of VideoFrame backing memory (GPU, CPU, shared, ...). This should not be required to define its observable behavior. > 1. VideoFrame seems optimized for WebCodecs, not funny hats, re copies — Is there room to question immutable VideoFrames vs e.g. lockable mutable ones when frames are not in GPU? Please see above. > 2. Pixel formats seem underspecified, w3c/webcodecs#165 and w3c/webcodecs#200 vs. e.g. earlier discarded ideas. The proposed use of fourcc style pixel formats is widely used across existing codec APIs (e.g. FFmpeg). See: https://www.fourcc.org/yuv.php. We will soon provide more verbose definitions for the each format as described in the linked issues. We will additionally extend the list to include other formats (e.g. RGBA, NV12, ...) -- GitHub Notification of comment by chcunningham Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/38#issuecomment-842808300 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 May 2021 04:05:13 UTC