W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2016

[mediacapture-record] Reconsider isTypeSupported() API

From: ddorwin via GitHub <sysbot+gh@w3.org>
Date: Tue, 22 Nov 2016 00:48:36 +0000
To: public-media-capture@w3.org
Message-ID: <issues.opened-190878242-1479775714-sysbot+gh@w3.org>
ddorwin has just created a new issue for 

== Reconsider isTypeSupported() API ==
`static boolean isTypeSupported(DOMString type)`
 1. Is a static synchronous API
 1. Requires one of the following:
    1. Use of an ambiguous codec string in `type` (something that may 
not be supported for some codecs)
    1. 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 

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 

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.

Please view or discuss this issue at 
https://github.com/w3c/mediacapture-record/issues/93 using your GitHub
Received on Tuesday, 22 November 2016 00:48:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:38 UTC