Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we document in the spec that there is no consensus on whether supporting MediaStreamTrackProcessor for audio? #92

Open
youennf opened this issue Jan 19, 2024 · 6 comments

Comments

@youennf
Copy link
Contributor

youennf commented Jan 19, 2024

Should we document in the spec that there is no consensus on whether supporting MediaStreamTrackProcessor for audio?

@youennf
Copy link
Contributor Author

youennf commented Jan 19, 2024

The spec says:

Note: There is no WG consensus on whether or not audio use cases should be supported.

It is precise about audio track generator.
But it is not precise about MediaStreamTrackProcessor.
It might be good to add a note similar to the one done for VideoTrackGenerator.

@youennf
Copy link
Contributor Author

youennf commented Jan 29, 2024

I uploaded #104 which partially fixes the issue.
What remains is what to do when MediaStreamTrackProcessor constructor is given an audio track.
The spec should probably say something, safari current implementation throws.

@jan-ivar, @alvestrand, thoughts?

@youennf
Copy link
Contributor Author

youennf commented Jan 29, 2024

I guess audio track throwing may be already allowed since it might not be considered as an invalid track.
This could be tackled in #94.

@guidou
Copy link
Contributor

guidou commented Jan 30, 2024

We should reopen this debate. In Chrome, MSTP for audio is used 3X more than MSTP for video.
I don't see any argument not to support it. The real-time one is not valid, because a lot of the applications (presumably all of the ones currently using it) do not need to run on a real-time thread (in fact, for many such applications a real-time thread would be worse than a worker thread).

@youennf
Copy link
Contributor Author

youennf commented Jan 30, 2024

We should reopen this debate

That is a different issue, that we can tackle on with WG discussions.

The issue here is specifically about representing in the spec the current state of discussions, nothing less, nothing more. This is more editorial than anything else (except the part to represent lack of audio support).

@guidou
Copy link
Contributor

guidou commented Jan 30, 2024

That is a different issue, that we can tackle on with WG discussions.

The issue here is specifically about representing in the spec the current state of discussions, nothing less, nothing more. This is more editorial than anything else (except the part to represent lack of audio support).

Absolutely. I commented on the wrong issue. I agree that the spec should reflect that and your PR LGTM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants