
Cisco to release BSD-licensed H.264 stack - padenot
https://brendaneich.com/2013/10/ciscos-h-264-good-news/
======
pthatcherg
That's the "Good News". Now for the rest of the story:

The open source part of this is nearly useless, if not completely so, as
evidenced by the fact that Firefox won't be using the source code. The "you
don't have to pay the MPEG-LA" part only applies to the binary module. If you
want to pick up this code and ship it in your own software, you'll still need
to pay the MPEG-LA.

The reason they are doing this is to put more weight behind H264 in the
political battle in the IETF over the MTI video codec for WebRTC. But if they
succeed in making H264 the MTI, and you want to write a mobile app that
interops with WebRTC for doing some form of realtime video, you'll won't be
able to use their source code without paying the MPEG-LA. You'd have to use
their binary module, downloaded from their servers, which, as they mention in
the Q&A, is impossible on iOS.

The announcement seems to try hard to smudge this distinction and push it into
the fine print, but there's still a patent "elephant in the room".

TL;DR: This doesn't solve the patent issues surrounding h264, and doesn't make
it anymore suitable as an MTI for WebRTC.

~~~
gillianseed
Yes this sucks, it's obviously MPEGLA's (of which Cisco is a member as a h264
patent holder) move to prevent WebRTC from standardizing around VP8/VP9 (which
is already supported in Firefox and Chrome), so instead we are to rely on a
binary blob from Cisco for royalty free WebRTC (Flash all over again).

The big stink is how Firefox is supporting this, it's like a huge betrayal of
the principles of an open web which is what I directly associate Mozilla with.

As a long time Firefox user and promoter I feel betrayed.

~~~
BrendanEich
We "betrayed" by not doing what, exactly?

H.264 won the HTML5 video battle, as noted at
[http://brendaneich.com/2012/03/video-mobile-and-the-open-
web...](http://brendaneich.com/2012/03/video-mobile-and-the-open-web/). If
anyone betrayed someone then, it was Google for not doing as they explicitly
blogged they would by removing H.264 support from HTML5 video in Chrome. (But
I understand why they didn't; they're realists.)

For WebRTC where there is no extant/legacy content reason for us (not speaking
for Cisco) to require H.264, we prefer VP8 over baseline H.264, but do not at
this point want to rule out either. And on mobile devices, especially at the
low end, the h/w codec advantage for H.264 is material.

Even next-year-announced chipsets with VP9 support tend to have only h/w VP9
decoding and at best s/w encoding (perhaps on an extra ARM core!).

Your fancy camera with video short-take capabality has boiled H.264 encoding
as well as decoding into even low-end SoCs. How much this means for battery
life, we are still digging into, but it's not trivial for long WebRTC calls.

Instead of dramatic talk about betrayal, where you seem to expect Mozilla to
fall on the nearest sword stood up and aimed at our gut (probably by a
competitor), and die a glorious but pointless death, think about the long run.
H.264's price ceiling is now $0.

This matters for future codecs. Between our work on Daala, and downloadable
codecs such as OTOY's ORBX.js, there is a better and unrestricted future to
invent. Join us, if you can be realistic about H.264 h/w advantages.

/be

~~~
gillianseed
You already knew about how much more/better support h264 had long before you
embarked on what now comes across as nothing but a charade as you turn coat
ONE WEEK before the WebRTC future is being voted on, you KNEW this so what has
changed?

Oh, what has changed is that now you, Mozilla, can use h264 royalty free, that
is what has changed.

So suddenly open source royalty free standards aren't that important anymore.
I threw up a little in my mouth when I read -'we lost the fight' from Monty,
you didn't fight!

Instead you switched sides one week before the vote because MPEGLA threw you a
bone.

And if all it boils down to in the end is 'hardware advantages' then you can
just drop the pretense of Dalaa right now, it will NEVER be anything but much
less supported than the latest offering from the MPEGLA cartel, so from that
very perspective it's nothing but vaporware.

MPEGLA was terrified of WebRTC and HTML5 standardising under a truly royalty
free open source codec which could be used anywhere by anyone, so they gave
you the 'flash'-style binary plugin for 'free' and you swallowed it, hook,
line and sinker.

This was the chance to break the royalty-laden video technology monopoly of
MPEGLA by getting a truly free codec standarised, and despite you having made
a show of 'carrying the torch' for royalty free open source web standards you
sold out one week before showdown when Cisco called with an offer.

They got you cheap.

~~~
BrendanEich
You are not making any sense.

First, MTI votes in IETF are tricky to predict, but here is a safe bet: VPx
was never going to win sole MTI. Not ever.

Second, if we had not been fighting -- and holding to only WebM for HTML5
video until last year -- while our competition was shipping H.264 for HTML
video, you might be able to say that we didn't fight. If we had not tried to
make s/w VP8 perform on lower-end mobile phones ahead of others including
Google, you might make that charge.

But we did those things and failed. We learned from those negative results.
What have you done? What have you learned? Where is your skin in the game?

Third, MPEG LA has not thrown us a bone. Cisco != MPEG LA. Taking H.264 to
zero price is a net public good and a prerequisite for getting RF licensing of
part or all of H.264 for all desktop systems (since rents there, as opposed to
on mobile devices, are running low).

When we do that in the next year (or sooner) based on taking the price to
zero, and gain free as in speech licensing, will you thank us? Not likely.

Fourth, MPEG LA was not terrified of HTML5 standardizing on a truly RF codec,
because HTML5 was never going to do any such thing. Now you're just
confabulating. Again, read

[http://brendaneich.com/2012/03/video-mobile-and-the-open-
web...](http://brendaneich.com/2012/03/video-mobile-and-the-open-web/)

and wake up and smell last year's coffee.

As for "they got you cheap", if I were about money, I would have gone to
Google ages ago. If Mozilla were about money we would have sold out in any
number of ways.

This is not about money, it is about interoperation and zero-price ceiling for
H.264 now, and RF licensing for desktop next -- and after that, better codecs
that are defensibly unencumbered and/or downloadable in JS and WebGL2 or
better (probably both).

None of this is easy to pull off. Rejecting interoperation is a sure way to
die fast for no good end. Shouting about betrayal on HN is cheap and easy by
comparison. Try doing something productive for a change.

/be

~~~
gillianseed
>Third, MPEG LA has not thrown us a bone. Cisco != MPEG LA.

Oh please, Cisco is part of MPEG LA and you'd have to be incredibly naive to
believe that this was Cisco striking it out on their own to offer a
'solution'. This is MPEG LA's offering, brought to you by one of it's members.

And likewise it doesn't take a genious to realize that you switching sides one
week before the vote came as a result of discussion with Cisco, to offer
broader support for h264 as the WebRTC standard.

So yes, I say you sold out.

>Fourth, MPEG LA was not terrified of HTML5 standardizing on a truly RF codec,
because HTML5 was never going to do any such thing.

Oh I'm sure this royalty free h264 binary blob offering from MPEG LA was due
to the kindness of their hearts.

Of course they were terrified, because even if this was just for WebRTC and
not HTML5, it would have set a precedent for a fully open source and royalty
free codec, with all the benefits that come along with it, which in turn would
increase demands for fully open web video solutions in all areas.

Also you totally avoided the question I posed regarding your 'hardware
support' argument, and where that leaves Dalaa as anything more than a toy
project.

I held you guys to much too high standards it seems (much higher than any
others in the web industry), I was obviously wrong.

~~~
BrendanEich
> Oh I'm sure this royalty free h264 binary blob offering from MPEG LA was due
> to the kindness of their hearts.

That's not from MPEG LA to us. That is from Cisco to everyone who wants to use
a blog, and it's permitted by the licensing, just the same as Flash today can
be downloaded from Adobe as a binary blob and neither I (as a user) nor
Mozilla needs to pay MPEG LA.

I still see lots of anger, as well as confusion. Anger leads to the dark side.

A hopeful sign, kind of: you started with "betrayal" (Harold Pinter play!) and
now you are faulting Mozilla for being confused, or for not reforming All The
Things instantly. A bit of a climb-down -- just sayin'.

Please note that we don't like any of the bad patent-pooling, rent-seeking
behavior either. Failing to overcome it all at once, finding an incremental
path to what we believe will be a better future, not throwing ourselves on all
the swords, is part of how Mozilla operates. If you want purity, there are
prefs you can set and add-ons you can install in Firefox. If that's not pure
enough because you have to set prefs or use add-ons, there are tiny share
browsers you can use instead.

I'm not saying "there's the door", rather I'm explicitly reaffirming that
Mozilla does not consider every bad reality imposed on competitive browsers to
be a make-or-break principle test (Monty made it sound like that; Mitchell and
I do not agree), which we can pass only by rejecting reality and therefore
very likely shrinking to tiny market share.

/be

~~~
BrendanEich
s/use a blog/use a blob/, LOL.

------
ghoul2
I __really__ __really__ don't get the mozilla stance here. It just doesn't
make _any_ sense to me.

Mozilla has been resisting Googles libre codecs even though they come with
full source code and a patent pledge. Google has already even paid to
eliminate potential threat from the evil MPEG LA. It is as free(libre) as you
can get in this space.

On the other hand, the Cisco plugin is no solution at all. A binary module
that has to be downloaded by each user? How can Mozilla justify
recommending/requiring a binary module whose source it can not
view/audit/share? This approach wouldn't be permitted under Debian Free
Software Guidelines, thus ensuring that WebRTC-Firefox won't work on debian
and its derivatives.

Cisco benefits from H.264 winning the standards battle. They also have patents
in the MPEG LA pool. Apple, MS and Cisco - none of them are under any
obligations to provide a libre implementation of WebRTC. Only Google and
Mozilla have that responsibility. And they can make it happen today by just
agreeing to go with VP8 and VP9 when it lands (both are covered by the patent
pledge as well as under the MPEG LA agreement).

H.264 is a defacto standard already, I understand. But google, with its
control of youtube and Android, can make a serious dent in that. If Moz and
Google ensure that VP8 becomes the de-jure WebRTC standard, a Free software
implementation of that can be released by mozilla _today_. No need to wait for
Dwolla to come to fruition.

I'd really like to understand what I am missing here.

~~~
pornel
Mozilla has implemented WebM playback, but WebM hasn't gained enough traction
to matter.

> But google, with its control of youtube and Android, can make a serious dent
> in that.

Uninstall Flash and try using a browser without H.264 codec. I have, and it
sucks.

YouTube is the only major site that supports WebM, and even there WebM it's a
second-class citizen (videos with ads are not allowed to use HTML5 player, and
not all videos are transcoded to WebM).

Google dropped the ball here. Android still has better support for H.264 than
WebM. YouTube is half-broken with WebM. Chrome broke promise of dropping H.264
— they know that a browser cannot survive without it.

~~~
IvanK_net
And by the way, it is not possible to use Youtube without Flash Player. Some
videos simply are not played with HTML player and Youtube tells you to
download Adobe Flash Player :( Hope there will be some new competitor, who
will offer video services without third party plugins. Maybe Vimeo?

~~~
jakeogh
I haven't had flash installed for years. For videos, I made a key-binding that
extracts any URL's in XA_PRIMARY, launches [https://github.com/rg3/youtube-
dl](https://github.com/rg3/youtube-dl) and then plays the video with mplayer.
Looks better (because the vid is full res) and never skips.

~~~
nisa
There is almost always a way. But explain that to my mom/room mates/friends
who don't even know what a key-binding is.

~~~
nitrogen
Don't explain it, just do it for them. Then they'll be the cool ones whose
YouTube works better than everyone else's.

~~~
jakeogh
Code: [https://github.com/jakeogh/youtube-dl-
wrapper](https://github.com/jakeogh/youtube-dl-wrapper)

------
smnrchrds
If you live in a country which doesn't allow patents for software, this is
great news. I wonder why no one cares about it in this thread. Foreign laws is
how we got DeCSS, VLC and Handbrake to name a few.

Mozilla could simply ship different packages for different countries, based on
their patent laws. For example, US version could use binaries distributed by
Cisco, while EU binaries could be built from source code maintained by
Mozilla. IANAL but I think it would be completely legal as long as the company
which distributes the EU version is a subsidiary or a separate legal entity
located in EU.

You are free to use whichever package you wish. Of course it would be illegal
if you live in a country that has software patent laws. But legality never
stopped us from using VLC or Handbrake. Why should it now?

~~~
pritambaral
Mozilla already supports (in code, not principle) H.264 by leveraging non-
Mozilla code. It's not usually a problem on Windows on Mac since the user has
already paid for a license when they bought the OS, but on Linux (gstreamer)
it can cause patent violations within US.

I hope (an believe) Mozilla will keep that functionality to use one of
multiple backends (Windows's fedia framework, gstreamer etc.) when it adds
this Cisco binary.

~~~
BrendanEich
We will need WMF at least until OpenH264 does High Profile, and I believe we
are not going to be able to use only the OpenH264 binary blobs. Therefore
we'll support other back ends (but not necessarily all possible back ends).

/be

------
nly
This just seems like the worst of both worlds for Mozilla:

1\. You can't guarantee the code will remain open.

2\. You still can't build and distribute modified works even with the code you
already have, because of patent constraints and licensing.

3\. You're using binaries from Cisco which you can't verify (unless they're
going for deterministic builds).

We already have mature, high quality, open source implementations of H.264.
Why can't Cisco just build and license one of those?

I for one will not be installing the binaries.

~~~
ZeroGravitas
Cisco already promised to permissively open source this implementation (though
not the binary fees-paid bit), because people were complaining they'd need to
pay for an H.264 implementation (as well as patent fees) in non-GPL projects
(GPL would allow you to use x264), which was another good reason to not vote
for this codec to be MTI in WebRTC.

Which Cisco was pushing for as it makes it easier to inter-operate with all
their existing video-conferencing gear.

Also, it costs them nothing since the H.264 licences are designed to not annoy
the big players too much, because they could shift the market if they wanted
too, and so cap out at about $6 million a year which I assume Cisco already
pays.

~~~
nly
You can use ffmpeg/libav's decoder in non-GPL or even proprietary projects,
since it's LGPL.

~~~
ZeroGravitas
This is in the context of WebRTC, i.e. standardized video web chat, which
needs an encoder as well.

~~~
nly
I'm not a video codec enthusiast, but it seems natural to me that low
latency/real-time constraints on the encoding process is going to mean you're
not benefiting from H264s full potential anyway. High profile H264 encodes are
incredibly slow, and there must be other codecs that fill the streaming niche.

This may benefit hardware and corporate conferencing gear manufacturers (aka
Cisco?), but I don't see how the encoder specifically benefits Firefox users.

~~~
ZeroGravitas
Well it'll help interoperate with those legacy systems. It seems that VP8's
libvpx implementation is likely to be better quality than this solution for a
while, since it only supports Constrained Baseline (and even x264 roughly ties
with VP8 when limited to that level) and won't even be available for months.

Also, if they get an AAC decoder from somewhere it'll provide H.264 decode of
HTML5 video to Firefox users on XP.

I'd still like to see VP8 as the MTI in WebRTC, and I'm somewhat surprised by
the timing of this announcement (i.e. nothing seems set to happen for months,
so why are they talking about it other than to influence that decision?) but
there's definitely pragmatic benefits for Firefox and its users.

~~~
nly
Interoperating with legacy systems? What legacy systems? The majority of
Firefox users currently don't use WebRTC with H264 streaming at all. This is a
very new thing. Maintaining legacy only seems to benefit Cisco.

> if they get an AAC decoder from somewhere it'll provide H.264 decode to
> Firefox users on XP.

aacdec.c and friends in ffmpeg git seem to be LGPL also...

~~~
ZeroGravitas
Although it's called WebRTC, and the billion or so installs of the two
existing Web browsers that actually implement it both use only VP8, there's a
lot of moneyed interests (like Cisco) that want to be able to inter-operate
with legacy systems outside the browser. Video transcoding would really put a
crimp in their plans.

And when I said "get an AAC decoder" I mean in the same sense that they get
the H.264 encoder/decoder from Cisco, or the AAC and H.264 encoder/decoder
from later versions of Windows or Android, with the key feature being not
paying any patent fees for it.

------
gioele
Who maintains the open source code?

What if a source change is accepted and Cisco does not want to release
binaries based on that code?

What if the code contains a security issue that is exploitable, but only in
remote cases and the maintainers do not want to accept changes to the code for
whatever reason?

How many attacks will there be trying to redirect the Cisco DNS in order to
let Firefox download a malware-ridden binary?

Will the binaries be available as deterministic builds?

Will the binaries be signed and checked by Firefox? Who has access to those
signatures?

How is this a victory over using GStreamer and using the encoders/decoders
available on the OS?

~~~
mbrubeck
This isn't necessary for systems that already have H.264 decoders provided by
the OS, but it's useful for platforms like Windows XP (which still accounts
for 20-30% of web usage) that don't have built-in H.264 decoders.

Firefox already uses cryptographic signatures to verify other code that it
downloads (including updates to Firefox itself); it could do the same for the
Cisco H.624 decoder.

Windows XP users already need to download a third-party binary plugin (e.g.
Flash) to play H.264 videos in Firefox. Cisco's code has the advantage that it
is open source and could be signed and distributed by Mozilla.

~~~
mbrubeck
Correcting myself: it looks like Mozilla can't distribute the binary itself
(while still benefiting from Cisco's end user licensing), though it could
still publish its own signature for verification.

------
cromwellian
Cisco owns WebEx. Along with Microsoft (Skype), and Nokia, they are fighting
WebM in WebRTC as a mandatory to implement codec, so I am deeply skeptical of
this move.

This seems basically about preserving investments in WebEx and Skype IMHO.

I also feel a tinge of Mozilla trying to kill WebM/VP8 to favor their own
vaporware codec. Are we being told, forget VP8, use H264 for now until Daala?

~~~
pornel
It's unfair to call Daala vaporware. The source and documentation are
released, and you can see it's making progress:
[http://people.xiph.org/~xiphmont/demo/daala/demo1.shtml](http://people.xiph.org/~xiphmont/demo/daala/demo1.shtml)

> Are we being told, forget VP8, use H264 for now until Daala?

We're told Mozilla can't win battle against H.264, but will be fighting the
next battle with Daala.

~~~
cromwellian
Ok, I take it back, vaporware is a little harsh. But in order for Daala to
win, it will not only have to beat H.264, but also H.265 and significantly.
Otherwise, the argument of the powers that be is that H.264/265 are the
established standard, widely deployed, low-power hardware implementations, and
here is this spec, which doesn't meaningful improve on quality, bandwidth, or
battery life, but is license free.

In other words, Daala will have to hit a homerun out of the park to convince
all of the major players to endorse it over their existing deployed
infrastructure.

If they do, I will be the first one cheering in the streets. But I'm
skeptical, hence again, like with WebP, we see Mozilla opposing something that
offers immediate offers benefits now in favor of something that in a few years
might be.

This Cisco blob, what if it significantly underperforms x264 in encoding
quality and CPU. Would we then be stuck with crappy WebRTC video quality
because you can't drop in better implementations?

~~~
BrendanEich
WebP does not offer immediate benefits by our measurement:

[http://people.mozilla.org/~josh/lossy_compressed_image_study...](http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/)

[https://groups.google.com/forum/#!topic/mozilla.dev.platform...](https://groups.google.com/forum/#!topic/mozilla.dev.platform/9NKc7OeEFLM)

If you work at Google, please point out errors in our methods or data, give us
better metrics, or otherwise correct us.

> This Cisco blog, what if...

"What if?" What if Google fails to get VP9 codecs into h/w? (See my response
above; half-way [decoder only] does not count.)

Lots of what-ifs here, but I believe OpenH264 is Cisco's best s/w codec. Let's
see, shall we, and not speculate idly.

/be

~~~
cromwellian
That's for JPEG, I had a long discussion on HN with someone, apparently from
Mozilla, over what I meant by this. My social network streams are more and
more filled up with multi-megabyte animated GIFs, and WebP is a reasonable
replacement for both animated GIFs and transparent PNGs. Today, we have three
formats to serve three needs: lossy, you choose jpeg, transparency, you choose
PNG, animated, you choose gif. Animated and transparent? Out of luck. Lossy
animated? Out of luck. Lossy and transparent? Out of luck.

I don't care so much about replacing JPEG as replacing GIF and PNG. APNG might
fit the bill for animated, but given how much information GIF throws away, and
given the 2M-5M GIFs I see out there already, it's likely to exacerbate the
bandwidth problem, not make it better.

I don't really care if WebP is the replacement, maybe the replacement of
mjpeg, or some other format so that people post short 5-6 second clips using
<video> instead of <img>. But animated GIFs are chewing up a lot of mobile
bandwidth and there is no solution out there right now that mitigates the
problem.

~~~
pornel
> My social network streams are more and more filled up with multi-megabyte
> animated GIFs, and WebP is a reasonable replacement for both animated GIFs
> and transparent PNGs.

It's only slightly better than _lossy_ PNG:

[http://pngmini.com/vs-webp/](http://pngmini.com/vs-webp/)

It doesn't appear to be good at beating GIF, and loses to APNG in compression
(and I suspect also decoding speed):

[http://littlesvr.ca/apng/gif_apng_webp1.html](http://littlesvr.ca/apng/gif_apng_webp1.html)

and I find it highly questionable whether a new format that is exactly as
expensive as WebM intra frames should be used instead of WebM.

------
SeanLuke
Am I misunderstanding something? Cisco is releasing source code to something
heavily patent-encumbered, but is doing so under _BSD_ , an open source
license with no patent release. What value is the source code then? I can only
imagine it's to allow others to verify the correctness of their
implementation. You certainly can't use that source code in your own binaries.

~~~
0x09
It will be just another H.264 decoder and encoder, like in libavcodec and x264
respectively. It's actually pretty exciting since no competing (with x264)
open source H.264 encoder ever managed to reach maturity. And it's licensed
more liberally than x264's GPL+commercial.

> You certainly can't use that source code in your own binaries.

Obviously you can, but then it's up to you to work it out with the MPEG-LA. Or
not, depending on where you live.

------
ZeroGravitas
Interesting parallel to EME. They've taken the paid for codec licences and the
DRM out of Flash and built them into two smaller plugins (one binary based on
secret DRM code, one binary based on open source code).

I wonder how this stacks up quality wise to x264. I thought it was a bit
suspect that a few months back Cisco announced they would release this under a
permissive open source licence only _after_ H.264 was accepted as Mandatory To
Implement in WebRTC, while also continuing to argue for H.264 vs VP8 using the
highly regarded (though GPL/dual-licenced) x264 encoder.

Also, how can this possibly be legit according to the patent license? Or do
the patent owners turn a blind eye, like Microsoft in China, and Adobe with
student piracy with their eyes on not losing control?

~~~
bazzargh
It's legit because Cisco are paying the license fees (mentioned in the
article)

~~~
ZeroGravitas
Yeah, but that's like someone paying for an all-you-can-eat buffet and then
smuggling in a few bus loads of hungry people. Just because you paid for it
doesn't mean it's what the people you bought it from were intending.

~~~
pgeorgi
They're licensing per user - just that MPEG-LA has a upper bound of what to
pay annually (currently $6.5 million). That's something that Cisco can
probably better manage than not being able to move forward with their plans.

Question is if MPEG-LA closes that loop hole the next time they revisit
licensing payments (but then, how? Microsoft and Apple profit from the same
provisions, for example).

------
brendang
The Cisco paid MPEG LA license fees only cover the Cisco delivered binaries.
Doesn't sound like this completely free plug-in method would work for say, iOS
apps which can't download external binaries. You'd still have to cover the
MPEG LA licensing. According to
[http://www.openh264.org/faq.html](http://www.openh264.org/faq.html) "In order
for Cisco to be responsible for the MPEG LA licensing royalties for the
module, Cisco must provide the packaging and distribution of this code in a
binary module format (think of it like a plug-in, but not using the same APIs
as existing plugins), in addition to several other constraints. "

~~~
ZeroGravitas
Does iOS not already provide the equivalent encode and decode capabilities to
app developers?

~~~
brendang
I may be wrong, but I don't believe you can access the H.264 stream to send to
a remote location, say for a video conference application. I believe the API
only allows for saving to a file.

------
gcb0
NO! WRONG! tl;dr NO CODE IS BEING RELEASED AS BSD!

nothing is being released as BSD-license! NOTHING! take down this title! it
will only harm the public perception of webM and make webM supporters sound as
crazy as i am sounding here (i am the exception guys, everyone else is pretty
sane)

CISCO is releasing header files and such so that you can compile their still-
patent-encumbered binary blobs into a few major platforms. NOTHING even
slightly relevant is being given out as BSD-license. Nada. Zero.

This is nothing but harmful propaganda against open standards.

~~~
saidajigumi
> NO! WRONG! tl;dr NO CODE IS BEING RELEASED AS BSD!

Then please cite a source that backs that up. Bothering to follow the links
from the Mozilla post indicates you are dead wrong:

    
    
        We plan to open-source our H.264 codec, and to provide
        it as a binary module that can be downloaded for free 
        from the Internet. -- [1]
    
        [...] The source code will be open source and distributed 
        with a BSD lIcense. The binary module is separate and 
        when the users software downloads it from Cisco, that 
        is when we are responsible for paying the MPEG LA 
        royalties. – Nadee Gunasena, Cisco PR [2]
    

[1] Cisco blog: [http://blogs.cisco.com/collaboration/open-
source-h-264-remov...](http://blogs.cisco.com/collaboration/open-
source-h-264-removes-barriers-webrtc)

[2] Comment on same: [http://blogs.cisco.com/collaboration/open-
source-h-264-remov...](http://blogs.cisco.com/collaboration/open-
source-h-264-removes-barriers-webrtc/#comment-966417)

~~~
gcb0
you even cite the source but can read the paradox on "open source [...] and
provide a binary blob"? Read the response from Firefox to understand. If you
are not a coder, than i apologize and provide a car analogy :) they are giving
out cars with the engine bay shut, but they are providing 3D files under BSD
license so you can print a glove and a shoe to use when driving the car. And
the shoes and gloves are so bad, the the mozilla driver said he will just sew
his own and use the car for free, which he still has no idea which engine it
is using or what fuel it takes.

as i said, no "significant code" will be provided. The code they are open
sourcing is HEADER FREAKING FILES for the entry points on the binary blob.

It is the exact same thing as nvidia provides. and nvidia even provides the
header files as GPL! so let's all go buy nvidia drivers as they have GPL OPEN
SOURCE DRIVERS PROVIDED BY NVIDIA! huray!

~~~
asadotzler
I think you're confused here. Let me try to explain with an example. Mozilla
provides sources and binary blobs both. The latter in no way negates the
former.

Cisco will be providing sources and binary blobs both, and the latter in no
way negates the former.

Yes, there's "a catch". The catch is, though you get a BSD code license on the
source that allows you to redistribute the the source, you do not get a patent
license for shipping products based on that source. The only patent protection
you can get from Cisco is from their specific binary.

Cisco's isn't the first open source H264 codec and it won't be the last, but
it's the only one that comes with patent help and that's what makes it
different from the others.

------
ZeroGravitas
Announcement to WebRTC list: [http://www.ietf.org/mail-
archive/web/rtcweb/current/msg09269...](http://www.ietf.org/mail-
archive/web/rtcweb/current/msg09269.html)

The project website: [http://www.openh264.org/](http://www.openh264.org/)

------
BrainInAJar
I see no source code. And until I do see the source code, this isn't news,
this is just hot air lies from a big corporation.

------
0x09
An interesting aspect of this announcement is that it has the potential to cut
into x264's bottom line. For several years now the authors have dual licensed
the encoder under the GPL and a commercial license[1], meanwhile enjoying an
uncontested position among H.264 implementations. I don't expect Cisco's
offering to be able to compete on speed or quality of implementation, but the
BSD license also means that it may be "good enough" for some potential x264
licensees. I'm curious to see how this plays out.

[1] [http://x264licensing.com](http://x264licensing.com)

------
darkstalker
Meanwhile you can enable native H264 support on linux with the about:config
setting "media.gstreamer.enabled". This requires gstreamer with the respective
plugin to be installed.

------
throw7
Very sad that software patents are strangling any type of forward progress in
this area (webm/webrtc). I almost want to say a mti is impossible to dictate
in this arena, and just leave it to the protocol to handshake... if it fails
so be it, no video.

------
shmerl
Are they saying that WebRTC is going to standardize H.264, or they are saying
just that Mozilla will have an easy way to implement it in cases where nothing
else is possible?

It would be better if WebRTC standard remained ambiguous about video (like it
is now), but in practice H.264 could be implemented by everyone, rather than
making any such encumbered codec mandatory. The big failure here is of course
not making VP9 mandatory, but it looks like before Daala comes, we won't have
a mandatory free codec for the Web.

If H.264 will become a mandatory part of the standard - then it will be pretty
bad.

------
rejoinder
I just read this:

[http://www.zdnet.com/blog/bott/if-vlc-can-ship-a-free-dvd-
pl...](http://www.zdnet.com/blog/bott/if-vlc-can-ship-a-free-dvd-player-why-
cant-microsoft/4962)

What's the deal with VLC and H.264? Is it along the same lines?

Also I don't really get why you'd stick with the non-free codec if there was a
free better alternative. What's so good about H.264, and is it better than the
free competition?

------
caycep
This is probably a RTFM question on my part - but how does VLC play back H264?
I presume it's part of the x264 library, but is this essentially a reverse-
engineered H.264 codec?

The weirder thing is that I have some handbrake encoded videos from ~ 2008 or
so that don't play "Error: codec 'h264' not available. Yet other videos with
the exact same codec/media information play fine...which is spooky.

~~~
hsivonen
There is no need to reverse engineer H.264. The spec is not secret. VLC
operates out of France--not the U.S.

~~~
ars
France or U.S. doesn't matter for this - the patent laws are more or less the
same.

------
AshleysBrain
If they get an AAC decoder as well... does this mean we'll finally have one
video and one audio format for the web that plays everywhere?

------
zx2c4
I'd like to see the binaries released as deterministic builds. This would
avoid quite a few concerns for Mozilla supporters.

------
theandrewbailey
Incoming Stallman "this is not free software" rant in 5, 4, 3, 2...

------
danbmil99
Sad face.

------
nutela
Great news but will we be paid by karma now or how should it work this whole
opensource thing?

~~~
AlexanderDhoore
Please go look at the members list of the Linux Foundation [1]. And convince
yourself that pretty much every single company on this planet uses open source
software. It's not some new fad or hippy communist thing. It's serious multi
billion dollar business.

[1]
[http://www.linuxfoundation.org/about/members](http://www.linuxfoundation.org/about/members)

~~~
nutela
I was asking if people should expect to be paid when contributing to OSS or
how is the busines model set up?

