#603: MediaStreamTrack Insertable Media Processing using Streams
Discussions
Discussed
Feb 22, 2021 (See Github)
Dan: Reviewing answers to privacy & security questionnaire. Looks good. Do we know what the implementation plan is for any other browser? leaves comment.
Sangwhan: there may be some conflict because webcodecs moved away from streams... I will review.
Comment by @torgo Feb 23, 2021 (See Github)
Thanks for this and thanks for filling out the Privacy & Security questionnaire. 👍🏻. One question: what is the implementer commitment for this beyond Chromium? E.g. is there a Mozilla standards position?
Comment by @guidou Apr 13, 2021 (See Github)
Mozilla has not stated their position yet. So far, the WG considers the use cases this API is trying to support as valid and the main open issues will be discussed in the WG meeting this month. We'll officially request Mozilla's and WebKit's position after that meeting.
Discussed
Apr 26, 2021 (See Github)
Sangwhan: the API itself is similar to the webrtc.. I don't see an issue with the design itself
Dan: could be better at articulating user need... but they do say funny hats in the spec.
Yves: they say in the issue that a major concern is are they using real streams JS level or webRTC streams that are different? Issue of homogenisation of the web platform by avoiding using too many kind of things doing the same thing.
Sangwhan: ongoing problem with webRTC in general. A bunch of stream-like thingies but due to interoperability they can't change it. Early effort to transition over to streams at some point but that project sort of died off.
Yves: Apple arguing that they should use transform streams from the javascript streams. Makes sense. In 'further details' it's the major unresolved issue.
Dan: having multiple things which do the same thing is complicated and creates bloat
Sangwhan: the problem inside webrtc is that the damage has already been done and it's hard to unship these streamlike thingies
Dan: we could say 'ideally we could see convergence happen over time' rather than change this thing now
Yves: they may provide an API that would be compatible with regular streams
Sangwhan: aside from that i don't see why we would keep this open ... I can comment but I have to digest this discussio
Comment by @cynthia Apr 27, 2021 (See Github)
We discussed this in a breakout today - aside from https://github.com/w3c/mediacapture-transform/issues/4 (which we plan to look into and provide our opinion on) the design looks fine. We'll discuss this further in our plenary call this week.
Discussed
May 31, 2021 (See Github)
Ken: it's proposed closing
Dan: can we? Plenary
Discussed
Jun 28, 2021 (See Github)
Sangwhan: I think we did review this
Yves: missing internal discussion in the WG about details, everything else is fine on our side
Dan: already proposed close, close it now
Sangwhan: closing noise
Comment by @cynthia Jun 29, 2021 (See Github)
Discussed in a breakout today, and we're happy to see this move forward. Thanks for bringing this to our attention!
Comment by @jan-ivar Jul 22, 2024 (See Github)
Would the TAG like to re-review this in light of https://github.com/w3ctag/design-principles/pull/404?
There are competing implementations over this.
OpenedJan 27, 2021
HIQaH! QaH! TAG!
I'm requesting a TAG review of MediaStreamTrack Insertable Media Processing using Streams.
We propose an API that allows application-level code to access the raw (unencoded) video or audio data for a MediaStreamTrack object. The idea is to allow Web applications to implement custom sources and sinks, following the source-track-sink paradigm on which the MediaStream spec is based. This will enable applications to 1) connect existing tracks to custom source (e.g., a camera track to a custom codec), 2) create new types of tracks that can be sent to existing sinks (e.g., peer connections), and 3) combine both mechanisms to perform custom processing on existing tracks (e.g., take an existing track, process its raw video frames to add an effect, and create a new track using the processed frames). This API leverages the Stream API and interfaces for raw media data proposed by the WebCodecs API, and is a logical follow-up to WebRTC Insertable Streams, which provides access to encoded data
Further details:
We'd prefer the TAG provide feedback as: 💬 leave review feedback as a comment in this issue and @-notify @guidou and @alvestrand