W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] Scripted querying of <video> capabilities

From: Dave Singer <singer@apple.com>
Date: Tue, 14 Oct 2008 14:21:58 +0900
Message-ID: <p06240829c519c8af0868@[192.168.1.132]>
At 20:06  +0000 13/10/08, Ian Hickson wrote:
>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.

I agree, as it is useful for 'portal pages', where you can prompt the 
user "you need to download and install X to view movies on this 
site". 

>
>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.

I think it is.  Without it, the UA would have to open each source and 
get its type via HTTP content-type, which is a lot slower, wouldn't 
it?  Is it clear that if the type is supplied in the markup, the UA 
can (and probably will) use it for content selection, at least at the 
coarse level, thus avoiding opening connections for files it knows 
(from the type) it cannot support.

>
>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'll discuss this internally and get back to the list.

>
>
>On Fri, 8 Aug 2008, Henri Sivonen wrote:
>>
>>  Does what HTML5 says now match the framework APIs?
>>
>>  The MIME codecs parameter seems to confuse both WebKit and Minefield, for
>>  instance:
>>  http://hsivonen.iki.fi/test/moz/video-selection/source-mp4-ogg.html
>>  vs.
>>  http://hsivonen.iki.fi/test/moz/video-selection/source-mp4-ogg-params.html
>
>This is a bad sign; what should we do to fix this?

If we have bugs here, we'll look at it.  Clearly precise mime types 
are desirable.


-- 
David Singer
Apple/QuickTime
Received on Monday, 13 October 2008 22:21:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:44 UTC