On Mon, Mar 12, 2012 at 8:44 PM, Andreas Gal <
andre...@gmail.com> wrote:
> We can't license decodes and ship those. That would bar others from shipping Firefox without entering into the same deals. All we are talking about is using existing accelerated decoders that already are licensed and available on the system.
I think the crucial line that's about to be crossed is exposing
functionality that cannot be implemented royalty-free to the Web. (We
already expose features that are implemented using royalty-bearing
technologies--anything that calls a Windows or Mac OS X API--to the
Web, but that's OK as long as it's also possible to implement those
features on top of a royalty-free OS (Linux).)
*If* we cross that line by exposing H.264 to the Web in a Mozilla
product (it's already exposed by everyone else--including by Opera in
their mobile and TV products--we are very alone with our current
position) here's how I think we should do it:
I think it's very important to have one Web platform and to have Gecko
expose the same feature set everywhere. Moreover, if we expose H.264
to the Web (regardless of whether we ship an H.264 implementation), we
will have reneged on our principle not to ship non-RF codecs. After
that, Web authors will not bother to support us with WebM on *any*
platform and will wait for us to expose H.264 to the Web everywhere.
(Many Web authors are in that mode already.)
Therefore, if/when we expose H.264 to the Web in some Mozilla product,
we should have it ready across the product line--including Firefox on
Windows XP and Firefox on desktop Linux.
I think Mozilla Corporation should have two products: Firefox and
"Mozilla MPEG Components" (the latter name is just a placeholder, of
course). The source code for both would be available under Open Source
licenses. However, while anyone can take the Firefox source, compile
it and distribute it royalty-free under a different name, it would be
acknowledged that distributing a self-compiled copy of Mozilla MPEG
Components probably requires licenses from MPEG-LA and Via Licensing
in some countries.
Mozilla MPEG Components would include the Android 4.0 software
implementations of H.264 and LC-AAC (or maybe libav implementations).
(I think the discussion about whether to support MP3 is a separate
discussion. I don't know if the MP4 container is RF, so I don't know
which side of the Firefox/Mozilla MPEG Components divide it should
go.) Mozilla MPEG Components would expose its functionality through an
API exactly or roughly like your MPAPI proposal. Mozilla MPEG
Components would compile into a shared library.
Firefox would look for a library that quacks like Mozilla MPEG
Components. If found, Firefox would report video/mp4 with the right
codecs parameter as supported via canPlayType and play
H.264/LC-AAC/MP4. If not found, Firefox would behave like today.
I think Mozilla Corporation should take the patent licenses at the cap
price where number of units shipped doesn't matter and ship
productized binaries of Mozilla MPEG Components for all platforms that
Mozilla ships Firefox for. Also, I think it would be good to ship
Mozilla MPEG Components for platforms like FreeBSD and Solaris where
there are non-Mozilla supported builds of the Firefox codebase
available.
Mozilla-shipped Firefox releases would come with a bundled Mozilla
MPEG Components release, so users of Mozilla-shipped Firefox wouldn't
have to go through any special steps to get H.264/AAC support. Parties
who self-compile the Firefox codebase (either under the Firefox name
or some ElementAnimal name) could use a copy of Mozilla MPEG
Components binaries shipped by Mozilla Corporation for free. If they
wanted to, they could compile Mozilla MPEG Components themselves and
get patent licenses on their own. Even non-Gecko products would be
welcome to use Mozilla MPEG Components as shipped by Mozilla
Corporation for free, so if Opera wanted to use it on desktop, I think
Mozilla should let them. If someone wanted to write a Gstreamer
plug-in that wrapped Mozilla MPEG Components for use in other Linux
apps, that would be cool too.
Basically, I think Mozilla needs to pay for the patent licenses in
order to deal with Windows XP and not leave functionality of Firefox
on XP up to a third party. Once the patent licenses are sunk cost, I
think it makes sense to hack the MPEG-LA scheme to the maximum extent
possible and give a codec-lib-only product away for free to everyone.
Then, once that baseline software functionality is available on all
platforms that Gecko runs on, I think it would make sense to use
system decoders instead of Mozilla MPEG Components where available.
But I think using system decoders where available as the first step
would be bad as it would fragment the feature set Web authors can
expect of Firefox.
- -
Some tangential points:
* In order to avoid fragmenting the platform exposed to Web sites, I
think we should still control the set of video formats exposed to the
Web and shouldn't expose random system codecs even when we technically
could.
* The licensing regime for MP3 is even more unpleasant than the
regime for H.264 and AAC, so I think MP3 requires a separate
discussion and decision. It's also worth noting that it's not too long
until the MP3 spec turns 20 years old, so it might make sense to wait
until then.
* On the face of things, it seems that using the Android 4.0 software
implementations of H.264 and AAC would be a better match for code
that's designed to support Android hardware acceleration, too. Also,
for a component of this nature, Apache License 2.0 might be nicer than
LGPL 2.1. However, there might be technical reasons to prefer libav's
decoders. I'm not competent to judge that.
* Conceding to a patent toll booth once sets a terrible precedent.
Already at the W3C some people are using the H.264 precedent as an
excuse to introduce DRM schemes that not only are patent-encumbered
but are also trade secret-encumbered (the operation of H.264 is not a
secret) and anti-circumvention-encumbered (decoding H.264 is not an
anti-circumvention-law-invoking activity).
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/