[whatwg] Scripted querying of <video> capabilities

On Oct 13, 2008, at 1:06 PM, Ian Hickson wrote:

> On Thu, 7 Aug 2008, Tim Starling wrote:
>>
>> Would it be possible to add methods or properties to  
>> HTMLMediaElement to
>> support scripted determination of client codec capabilities?
>
> The answer, based on replies quoted below from browser vendors,  
> appears to
> be "no", sadly. I agree that it would be a really useful thing to  
> have.
>
>
> On Thu, 7 Aug 2008, Robert O'Callahan wrote:
>>
>> That would be nice to have. Unfortunately DirectShow and Quicktime do
>> not seem to expose the ability to enumerate supported codecs, so it
>> might be hard to implement for some browsers.
>>
>> As things stand, you can use <source> elements to offer different
>> formats, and you can try to play a stream and use script to detect  
>> if it
>> fails to play.
>
> On Thu, 7 Aug 2008, Dave Singer wrote:
>>
>> In general, the source fallbacks are also a way to 'probe' this,  
>> albeit
>> in a very different way.
>>
>> I'm not sure you can always get a definitive answer to the question  
>> "if
>> I gave you a file with this (extended) MIME type, could you play it?"
>> and I am fairly sure that asking the implementation to enumerate  
>> all the
>> types it could support would be hard.
>
> It is sad that we can't provide an API such as the requested one.
>
> This brings up another point, which is, is the "type" attribute on
> <source> actually useful? Should we remove that and just have browsers
> probe the video subsystem for each resource? We can always add the
> attribute back later if it becomes useful again, but I'd rather not  
> have
> something that isn't used by browsers, since then it'll be used  
> wrong by
> authors, making it useless forever.

While the underlying media frameworks can't necessarily answer, "if I  
give you a file with this MIME type, can you play it?", they can at  
least give a yes/no/maybe answer, which can still be quite helpful,  
since the UA will know it does not need to check some media streams at  
all.

> Also, should we make .load() asynchronous as far as selecting a  
> media file
> goes? Right now, a media file has to be instantaneously and  
> synchronously
> selected, so the UA can't try each one in turn.

I believe the original design intent was to make selection completely  
static and not not based on a fallback-like approach of trying each in  
turn. Let's assume IE implements <video> at some point but does not  
support Ogg or MPEG-4 out of the box. Then an author wishing to  
provide 3 media streams could still likely get the job done, since  
browsers could likely determine whether or not particular basic  
content types are supported. It might be hard to get more complex  
cases right though.

Regards,
Maciej

Received on Monday, 13 October 2008 16:13:37 UTC