[whatwg] The issue of interoperability of the <video> element
maikmerten at gmx.net
Mon Jun 25 08:48:26 PDT 2007
>> Well, as usual it depends on how one defines "open". If "open" is
>> assumed to mean "usable even for people/organizations without money"
> The usual word for something that doesn't cost anything is "free".
That'd be the definition of "free beer".
> Open: anyone can contribute to the specification, the specification text
> is available to anyone, and the ability to implement and deploy is
> offered equally to all.
That's the MPEG kind of "open".
Depending on attitude "open" could mean "anyone can contribute to the
specification, the specification text is available to anyone, and the
ability to implement and deploy is offered to all without conditions", too.
Anyway, in this discussion that's a pointless... err... point.
>> If Apple doesn't want to take the IP risk of shipping anything but
>> QuickTime then let's find someone who's willing to do it ;-)
> QuickTime is an extensible multimedia layer and a core part of our OS.
> I am not sure what your point is here. Both Apple and non-Apple, and
> standard and proprietary codecs can be operated in QuickTime.
Well, my point is that albeit QuickTime can be extended to support
basically every format on earth this won't help the non-techie user if
the components are buried somewhere on the net.
So if Apple would like to ensure that Safari users can access pages with
non-MPEG <video> content (at least some browser vendors don't feel like
they're able to license it) without requiring that the users hunt down
some decoder components by their own some sort of assistance is needed.
This assistance could be a "video component download service" that comes
with Safari or QuickTime or some web portal (similar to
http://www.apple.com/quicktime/resources/components.html - but with
guidance what component is currently of interest).
>> If Safari is encountering "application/ogg" and it can't decode that
>> stuff then redirect (after asking of course) the user to a fitting
>> QuickTime component download page on e.g. xiph.org or even automate the
>> process of installing a fitting 3rd-party component after the user
>> acknowledged the process.
>> That won't be as smooth as "native" and "out of the box" support - but
>> if the whole process only involves like 4 user mouse clicks then
>> operability is as "okay" as it can be under the given circumstances.
> we have looked into this before, and probably will again (see the
> currently suspended 'quicktime download program').
Unsuspending that program or having talks with (in this case) xiph.org
(they already have a working QT component) outside of that program
sounds like a good way to strengthen the interoperability of Safari with
Opera and Mozilla. I heard that xiph.org tried to participate in that
QuickTime download program in the past but that this more or less
stalled on Apple's side (I only heard one side of the story, though).
More information about the whatwg