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
