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

deprecate isTypeSupported (was: MediaRecorder specification expects to synchronously know the list of supported mime types) #202

Open
youennf opened this issue Jul 31, 2020 · 5 comments
Labels
privacy-needs-resolution Issue the Privacy Group has raised and looks for a response on.

Comments

@youennf
Copy link
Contributor

youennf commented Jul 31, 2020

API surfaces this information in both isTypeSupported and MediaRecorder constructor.
In modern multi-process browser architecture, this is not ideal as this information may only be available asynchronously.

@youennf
Copy link
Contributor Author

youennf commented Jul 31, 2020

Should we deprecate isTypeSupported and use media capabilities API instead?
As of MediaRecorder constructor, I guess it might be fine to create a recorder and error it later on.

@guest271314
Copy link

Are there any known cases where isTypeSupported() reports incorrect values?

@dontcallmedom
Copy link
Member

the discussion on using media capabilities was also mentioned in #93

@jan-ivar
Copy link
Member

jan-ivar commented Feb 6, 2024

Should we deprecate isTypeSupported and use media capabilities API instead?

Yes at this point right?

@jan-ivar jan-ivar changed the title MediaRecorder specification expects to synchronously know the list of supported mime types deprecate isTypeSupported (was: MediaRecorder specification expects to synchronously know the list of supported mime types) Feb 6, 2024
@dontcallmedom-bot
Copy link

This issue had an associated resolution in WebRTC February 2024 meeting – 20 February 2024 (Issue #202 Deprecate isTypeSupported):

RESOLUTION: Make isTypeSupported return a fixed list of answers and mark it as deprecated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
privacy-needs-resolution Issue the Privacy Group has raised and looks for a response on.
Projects
None yet
Development

No branches or pull requests

6 participants