W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2022

[mediacapture-transform] Is MediaStreamTrackProcessor needed? (#73)

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Wed, 19 Jan 2022 10:59:08 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-1107955876-1642589947-sysbot+gh@w3.org>
youennf has just created a new issue for https://github.com/w3c/mediacapture-transform:

== Is MediaStreamTrackProcessor needed? ==
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.

Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/73 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 January 2022 10:59:10 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:55 UTC