Re: [mediacapture-transform] A review (#38)

> 1. Don’t expose raw realtime media on main thread, since there's a precedent that says this is bad [#23 (comment)](https://github.com/w3c/mediacapture-transform/issues/23#issuecomment-842585817)
We have shown that there are valid use cases for using the API on the main thread and I believe that we have agreed that using the main-thread is discouraged, but forbidding access on the main-thread is not an explicit goal. Either way, we can continue the discussion in #23. 

> 2. Limit to solving video for now, or explain why AudioWorklet is insufficient, to not reinvent it #29
Already explained, and the spec now mentions some use cases for which the proposed API is a better fit. We can continue the discussion in #29.

> 3. Lack of a threading model #27
Closed. No threading model required unless a more specific need is raised.

> 4. Lack of algorithms #36
Fixed.

> 5. Controlling channel mechanism is unclear #24
The mechanism has been removed.

> 6. Unclear memory I/O design given that a VideoFrame may be in GPU memory #34 (Funny hat: GPU→CPU→GPU?)
Already answered. This would be a WebCodecs issue anyway.

> 7. Can one JS document hose a browser's camera capturing ability? #37
> 
Already answered in #37.

> The other issue is that there seem to be massive missing areas in WebCodecs that we rely on:
> 
> 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?
> 2. Pixel formats seem underspecified, [w3c/webcodecs#165](https://github.com/w3c/webcodecs/issues/165) and [w3c/webcodecs#200](https://github.com/w3c/webcodecs/issues/200) vs. e.g. earlier [discarded ideas](https://w3c.github.io/mediacapture-worker/#pixellayout).
> 
Already answered.

> There also appears to be a lack of documentation or working samples to the point where any web developer can use it.
> 

Some working samples:
https://webrtc.github.io/samples/src/content/insertable-streams/audio-processing/
https://webrtc.github.io/samples/src/content/insertable-streams/video-processing/

> This makes it hard to see the big picture or validate whether the overall design addresses the listed use cases (a list that judging by the examples given, does not appear to require interfacing with WebCodecs — is that an omission?)

Not clear to me what this means. Can you file a specific issue with more details about what you mean?

Closing this since only a handful of issues raised by this review remain open and it's easier to continue the discussion in their respective github issues.

-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/38#issuecomment-863948748 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 18 June 2021 10:50:22 UTC