alvestrand
commented
1 year ago This was heavily discussed when we had the "shape of the API" discussion. The consensus was that we would go with MediaStreamTrackProcessor because it was able to process any kind of MediaStreamTrack, and VideoTrackGenerator / AudioTrackGenerator because the type of input data was different.
We have implementations, we have code that uses this. I don't see a reason to reopen this issue.
MediaStreamTrackProcessor usefulness is very limited. It also does not match VideoTrackGenerator. First MediaStreamTrackProcessor name is agnostic of audio vs. video which is not great with regards to the debate on audio support.
Second its usefulness as a construct is unclear to me given there is only a getter for the ReadableStream object. It seems like we would create a MediaStreamTrackProcessor, to get a ReadableStream and the MediaStreamTrackProcessor would be GCed right away.
It seems we could replace the API to something like: partial interface MediaStreamTrack { ReadableStream createVideoReadableStream(VideoReadableStreamOptions options); }
That does not mean there would not be a MediaStreamTrackProcessor object in the spec or in implementations. There is a need for such an object to represent the source of the ReadableStream and to be the sink of the track. But I do not see a use for exposing this object to JavaScript, as it does not seem to serve any other purpose than getting the ReadableStream.