joao.eiras at gmail.com
Wed Jun 18 03:57:51 PDT 2008
The spec clearly says the following
"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
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
> 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?
> 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
>> 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
More information about the whatwg