#603: MediaStreamTrack Insertable Media Processing using Streams
Discussions
2021-02-22
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.
2021-04-26
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
2021-06-28
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
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