

Cisco's Open Source H.264 Codec - pcl
https://github.com/cisco/openh264/

======
alister
The license is abundantly generous -- it essentially says, "do whatever you
want, but don't hold Cisco responsible".

But this isn't the whole story. There are also patents involved, and these are
not mentioned in the LICENSE file.

Cisco does explain the issue on a different website: "a team can choose to use
the source code, in which case the team is responsible for paying all
applicable license fees, or the team can use the binary module distributed by
Cisco, in which case Cisco will cover the MPEG LA licensing fees [1]" (where
MPEG LA, or MPEG Licensing Authority, is the organization that holds the
patents and of which Cisco is a member)

I think that most of the audience here seems to know all this. But it wasn't
clear to me, and I think it probably wouldn't be obvious to many other
readers.

[1] [http://www.openh264.org/faq.html](http://www.openh264.org/faq.html)

~~~
_rmp_
can anyone confirm that in order to avoid MPEG LA license fees for encoding
(20$ per unit sold I think) I can not distribute Cisco's compiled encoder
library with my software (even if I use the binary from Cisco's repository
-when they make it available- instead of compiling it myself) and the only
option would be to download it from my software at runtime as a plugin? are
there any other options (the systems on which my software is going to be
installed do not have internet access)?

~~~
mcpherrinm
That's right. This is a workaround for the MPEG LA license, and having the
user download the binary right from Cisco is the only way to have Cisco pay
for the license fees. Anything else and you've got to become a licensee.

~~~
ZeroGravitas
I don't think that's entirely true.

There's plenty of other H.264 products that you can get without directly
downloading them. Flash is a close analogy, they pay the flat fee and nearly
every desktop in the world uses it. And while some people download Flash
direct from Adobe's servers, other's get it indirectly, e.g. pre-installed on
computers they buy, or by downloading an installer. And people build apps
(including desktop apps) around that functionality.

Cisco is mostly doing this to support WebRTC interoperability with their
deployed hardware (which generally means internet access) so they may just be
going for the simplest thing for them to do.

------
Daiz
>Constrained Baseline Profile up to Level 5.2 (4096x2304)

Well, I wasn't expecting miracles from this, but constrained baseline profile
only? That's very disappointing. Not only will this be unable to decode most
of the H.264 content out there (web and otherwise), you could very likely get
better results with VP8.

If only they'd have endorsed something like libavcodec instead...

~~~
leetrout
Seriously... So much for adaptive bit rate.

Makes sense that Cisco would be using CBP after seeing this on Wikipedia:

"this profile is most typically used in videoconferencing and mobile
applications"

[http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles](http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles)

~~~
Daiz
>Makes sense that Cisco would be using CBP

Yes, I can understand the encoder only supporting CBP - videoconferencing is
the one thing that you really need encoding capabilities for in a browser.
Anything else you can basically always encode offline and use x264 or
whatever.

The real shortcoming is the fact that the decoder is also limited to CBP - as
I said, this makes it completely useless for decoding most H.264 video out
there (which is either Main or High Profile, generally the latter if we're
talking HD content), web or otherwise.

~~~
cfluffy
This codec is designed more for interactive video conferencing applications
and is not really great for non interactive encoding of a movie for playback.
The choice of CBP came from that is what the IETF is considering to specify
for the WebRTC standards.

------
crbnw00ts
There sure are a lot of hard-coded numbers in that codebase. In many cases
it's easy to figure out where the numbers came from, but in others, it's
nearly inscrutable without a named constant or a comment or _something_.
Here's one example:

[https://github.com/cisco/openh264/blob/master/codec/encoder/...](https://github.com/cisco/openh264/blob/master/codec/encoder/core/src/svc_base_layer_md.cpp#L1254)

Where does "15" come from? I suppose if I'd written a codec like this before,
or if I stared at the code long enough, I could figure it out, but wouldn't it
be better to use an enum or a #define?

~~~
_wmd
Encountered this topic recently in the office.. I'm from the side of the fence
that doesn't overly care about code tidyness, so long as it performs its
overall function. 10 years ago this kind of thing might have bothered me a lot
more, but at some point crossed a threshold where I realized _all code
generated to the present day_ is pretty ugly and long term unmaintainable (but
that's a story for a rather large and rather boring essay).

The tl;dr is simply that if you obsess over minor details on this level, a lot
of brainpower is wasted that could be used for bigger problems you should be
much more worried about.

Playing devil's advocate, in this case the if() is obviously a guard for the
subsequent switch. Moving just the constant '15' into a #define would make it
read more like some magical sentinel value, unless you also #defined all the
literal values used in the switch, at which point you've introduced a wholly
bullshit layer of abstraction to what was otherwise incredibly concrete and
explicit code.

Let's assume you have a great reason for doing that. OK. So what do you call
these constants? Well, the code appears to be branching to special cases based
on the width of some integer. So we instead have what, WIDTH_1_BIT,
WIDTH_2_BITS, ..., WIDTH_15_BITS? Now we've pulled those constants out, you
stare at the block of #defines, and think, damn, this is so _ugly_ since most
of the value space isn't fully defined! So some kindly maintenance programmer
comes along and pads out the rest, producing a perfectly beautiful block of
utter line noise.

That is arguably considerably less readable than what we started with

~~~
hughlomas
A simple //comment would have sidestepped all of that and still clarified the
number's purpose.

~~~
lyndonh
It's all very well when it's a simple variable but quite often I have come up
against variables that would take a whole paragraph of text to explain their
purpose _and_ don't have a concise or obvious name.

~~~
JasonFruit
I find _quite often_ a little hard to believe. Occasionally, maybe; and why
not provide a paragraph of text? Sometimes it's the right thing to do.

------
lawl
It would be really cool if they provided predictable builds, then we could
just compare the binary against a self-compiled binary and be sure tehre are
no backdoors we can't see in the code.

Sadly even truecrypt fails to provide that. So i guess we'll have to life with
binary blobs no one knows what they're really doing.

~~~
cfluffy
Hi, I'm one of the people working on the stuff Cisco open sourced and yes, it
will be predictable and verifiable builds. We are working with some of the
Mozilla folks to make sure we can do that.

~~~
cpeterso
How often do you expect new Cisco builds to be published? Will the releases be
versioned so Firefox version X knows it will always install OpenH264 version Y
from Cisco's binary blob server?

~~~
cfluffy
Open to suggestions but the current plan would be to make it match up roughly
with the Firefox 6 week release cycle. Definitely versioned and fingerprinted
such that Firefox can verify that Cisco did not compile in bad stuff.

------
est
[https://github.com/cisco/openh264/blob/master/CONTRIBUTORS](https://github.com/cisco/openh264/blob/master/CONTRIBUTORS)

Contributors are 100% Chinese. Is this project make in Cisco China R&D?

~~~
general_failure
Cullen Jennings is not chinese

~~~
est
Well, when I posted the comment it was like this

[https://github.com/cisco/openh264/blob/3747f562492ea301b84e3...](https://github.com/cisco/openh264/blob/3747f562492ea301b84e3eae4fa8cae765d95ccb/CONTRIBUTORS)

view history here

[https://github.com/cisco/openh264/commits/master/CONTRIBUTOR...](https://github.com/cisco/openh264/commits/master/CONTRIBUTORS)

------
atonse
I'm genuinely curious --- how come nobody thought of doing this (being some
kind of platinum member and just putting it out there for all to use) all
these years during the fighting about h.264 vs the open web and yada yada?

What Cisco did seems to have put an end to all those debates, and h.264 is
available for all, with patents intact, etc.

~~~
samspenc
It costs Cisco $6 million a year to do this. I wonder if any of the
beneficiaries (Firefox, etc) are pitching in.

That sounds like loose change, but probably stuck up in bureaucratic decision-
making at anyone who thought of this before. ("Why are we spending $6 million
a year to make it free for everyone else again?")

EDIT/UPDATE: In the second paragraph, I was referring to _other_ companies and
why they didn't do this earlier. It clearly brings Cisco quite a bit of
goodwill to do this, and to see more video flowing on the web.

~~~
pkaye
I doubt it costs Cisco anything extra because they probably need the
distribution rights for other products they develop (for example WebEx.)
Besides it a good PR benefit for them with minimal incremental cost.

~~~
cfluffy
It costs Cisco lots (I work at cisco) as we were not close to paying the 6.5
million cap before this. Mozilla has been contributing to the code and making
sure the project runs well but not towards any MPEG-LA payments. There are
probably a bunch of reasons Cisco did this but making interoperable video just
work on the internet would be at the top of the list. That's good for Cisco
and others.

------
who8mylunch
What about x264 hosted at VideoLAN:
[http://www.videolan.org/developers/x264.html](http://www.videolan.org/developers/x264.html)?
It's open source and people have implemented tons of cool software tools with
it.

~~~
dpe82
The key here is Cisco is paying the patent royalties for anyone who uses their
codec binaries - which will cost them $6.5m/year. They could do the same for
x264, but it's probably legally safer to distribute an implementation they
wrote themselves.

~~~
cfluffy
If the x264 people think they can give x264 to Cisco under a license that we
can compile it and distribute the binaries with no changes to our MPEG LA
licensing agreements, tell them to get talk of me (fluffy@cisco.com) if they
want to do this. I came to the conclusion Cisco could not do this without x264
giving us an appropriate license.

