[whatwg] Javascript API to query supported codecs for <video> and <audio>

[João Eiras]

The spec clearly says the following
http://www.whatwg.org/specs/web-apps/current-work/#video1
"User agents should not show this content to the user; it is intended
for older Web browsers which do not support video,"

Although we fully understand the reasoning behind this, there's an use
case missing.
The user agent may support video but might not support the file format.
So in this case, <video> should do fallback, because:
a) <video> tags are markup and therefore its error handling is not
available to scripts
b) the author may not want to use scripts, or may want to make the
page fully usable with scripting
c) it's a predictable scenario without any written solution


2008/6/18 Philip Jägenstedt <philipj at opera.com>:
> Sorry, my reply was cut short. Again:
>
> It seems to me that it's a good idea to wait with this until we know
> more about what will happen with baseline codecs etc.
> Implementation-wise it might be less than trivial to return an
> exhaustive list of all supported mime-types if the underlying framework
> doesn't use the concept of mime-types, but can say when given a few
> bytes of the file whether it supports it or not. Allowing JavaScript to
> second-guess this seems like a potential source of incompatibility.
> Isn't it sufficient to look for MEDIA_ERR_DECODE and add fallback
> content when that happens?
>
> Philip
>
> On Wed, 2008-06-18 at 17:34 +0700, Philip Jägenstedt wrote:
>> It seems to me that it's a good idea to wait with this until we know
>> more about what will happen with baseline codecs etc.
>> Implementation-wise it might be less than trivial to return an
>> exhaustive list of all supported mime-types if the underlying framework
>> doesn't use the concept of mime-types, but can say when given a few
>> bytes of the file whether it supports it or not. Allowing JavaScript to
>> second-guess this doesn't seem great
>>
>> On Wed, 2008-06-18 at 12:18 +0200, j at oil21.org wrote:
>> > On Wed, 2008-06-18 at 12:03 +0200, Anne van Kesteren wrote:
>> > > Why is that needed? The elements provide a way to link to multiple codecs
>> > > of which the user agent will then make a choice.
>> > i do not intend to provide multiple codecs since that would require
>> > multiple backend implementations for playing files form an offset,
>> > encoding files in multiple codecs on the server, more disk space etc,
>> >
>> > instead i would only use the <video> tag if the codec i use is supported
>> > and fall back to other means via <object> / java / flash or whatever to
>> > playback the video or indicate that the user has to install a
>> > qt/dshow/gstreamer plugin. in an ideal world i could use <video> like i
>> > can use <img> now and be done with it, but since this is not the case we
>> > need tools to make the best out of <video>, not knowing what the browser
>> > supports and just hoping that it could work is not an option.
>> >
>> > j
>> >
>> >
> --
> Philip Jägenstedt
> Opera Software
>
>