Reconsider isTypeSupported() API

[ddorwin]

static boolean isTypeSupported(DOMString type)

1. Is a static synchronous API
2. Requires one of the following:
   1. Use of an ambiguous codec string in type (something that may not be supported for some codecs)
   2. The application to make many requests until it finds an exact matching codec string.

1: The synchronous nature prevents implementations from performing any meaningful logic, such as querying hardware encoders on-demand (rather than building the required information at startup). (This is becoming a concern for canPlayType().)

The synchronous and static nature prevent implementations from displaying any type of permission prompt or UI or perhaps installing a component to handle the feature. I don't know how much of a concern this is for this API.

2i: Use of an ambiguous codec string, such as avc1, is problematic because they do not adequately describe the codec. For example, there is no way to differentiate between baseline profile and high profile or Hi10P. There is also no guarantee that such ambiguous strings will be supported for newer codecs.

2ii: If applications do want to ask more detailed questions, they need to make many queries until they find one that is supported by the encoder. (This assumes all encoders are not configurable for various profiles, levels, etc.). AVC, for example, has a number of profiles and many levels within them. Newer codecs are adding even more parameters.

This is less of a concern for canPlayType() and similar APIs related to playback because in that case the application should know what streams it has and only needs to ask whether those streams can be played.

An API that returns a list of supported types (#59) may make more sense, but it probably depends on how configurable the encoders are since such an API could potentially return many values that an application would need to sort through.

[yellowdoge]

I believe the original intent of isTypeSupported() was closely modeled on MediaSource.isTypeSupported() of the Media Source Extensions, and the latter is a Candidate Recommendation. Both have similar strengths and weaknesses. @alvestrand any ideas how to move forward?

[ddorwin]

MSE was essentially frozen a long time ago before recent best practices and learnings could be applied. For example, promises and predictability related to MIME types. The latter has led to inconsistencies in browser implementations (that will hopefully be addressed in a future version of the spec). EME went through significant changes at a later date and attempted integrate such practices and learnings.

[ddorwin]

I think the more important question is how we expect applications to use the API. In what cases would an application call either of these APIs and why? In most cases, it seems that the ability for the same user agent to play a codec might be sufficient. (Should their be guidance/requirements in the spec related to this?) Perhaps an application wants to request a more optimal codec, a codec that is better supported by the backend, or 10-bit - all when available.

Once the intended use is understood, you can look at ways to accomplish it, such as specifying maximums or ranges in requests to create a recorder. Would getUserMedia's constraints model be applicable?

[yellowdoge]

In a parallel story, we've added encodingInfo() to the WICG Media Capabilities spec (see the issue) (already implemented in Chromium). I believe that we should move querying capabilities to that Spec and ultimately remove them from here, which would address this issue and #92. (+@mounirlamouri FYI)

[jan-ivar]

Overtaken by https://www.w3.org/TR/media-capabilities/