#603: MediaStreamTrack Insertable Media Processing using Streams

Visit on Github.

Opened Jan 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:

  • I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: It would be nice to have a reply by April 8, 2021.
  • The group where the work on this specification is currently being done: W3C WebRTC Working Group
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): W3C WebRTC Working Group
  • Major unresolved issues with or opposition to this specification: There is an open issue about using streams vs. giving stream-like properties to MediaStreamTracks.
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as: 💬 leave review feedback as a comment in this issue and @-notify @guidou and @alvestrand

Discussions

2021-02-22

Minutes

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

Minutes

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-05-31

Minutes

Ken: it's proposed closing

Dan: can we? Plenary

2021-06-28

Minutes

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