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.
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)?
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.
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.
Not $20 but $0.20. (after the first free 100,000 and until it drops to $0.10 after 5 million) although you may have to sign a license with MPEG-LA to take advantage of the free 100,000 and potentially submit to audits so there are risks/costs.
I don't know how direct the distribution from Cisco to the end user has to be to be legal although I can imagine a range of possibilities for this I don't know if they would be practical in your situation. I imagine that you could ship a tool that creates an install package to be used on the non-connected devices and downloads the binary from Cisco and adds it to your install bundle but that is still an annoying extra step.
Practically I don't see anyone coming after you (and certainly not getting real damages) if you did include Cisco's binary with your product - it would be hard to see the real harm or damage caused.
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:
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?
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
I'm not sure how much this applies to open source. Closed source, quite possibly, since it probably won't survive long enough / need to change enough / need enough people to understand it.
Open source, meanwhile, requires being understandable to new people. It needs to explain itself, or it needs to be idiomatic (within its specialty). If neither, you're condemning people to rewrite it or waste time trying to figure out the original intent.
The second half of what I said explained how the code becomes less readable. If someone wants to hack on that code, they better understand the algorithm it implements, which means at a minimum they've probably absorbed the same 2000 page spec the original developers absorbed (and know exactly what 15 means). No amount of #define can fix that, although in the right circumstance some comments might help.
Your first paragraph sounds quite defeatist. In my experience, the way you deal with "minor details" is to write them down in a style guide. It'll take away a lot of the quibbling about small things. Some will find it limiting, others will find it liberating.
I've worked at several jobs that had decade old code in production. Some cared about the little things, some didn't. I know which code was the best to work with. In my experience, the broken windows theory is true when it comes to code. The little things matter in the long run.
This is a very insightful comment. There has also been some debate about the appropriateness of non english comments and comments that only made sense in context of internal code names for Cisco projects. The high level test we used was lets get the basic code out on github as early as possible.
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.
IMO it doesn't make sense to read code like this without a copy of the H.264 spec in hand. And once you've got that spec, why paraphrase a fraction of it, poorly, in the source code?
I do think that comments at the function level indicating which part of the spec you should be reading would be nice. They might not be an issue for people who are indoctrinated into the code though.
Huh. I don't think it's just you - that looks like some properly nasty code. Formatting is all over the place, lines are commented out, comments are useless and obviously wrong in places...
I don't really speak C++ though, so maybe this is normal.
The good point is that other hacked together quasi-compatible implementations now have an "official" reference implementation to browse. It could be a lot worse... I've waded through uncommented OCaml to discover how a certain shall-go-unnamed commercial, non-restful XML API worked. Or, Cisco could've never open-sourced it.
I'm not in to video circles anymore, but I was under the impression the existing open source implementations were way better. The reason this code is significant is Cisco is providing licensed binaries.
As with many things it seems like knowing how an H264 codec works before reading the code is essential. I don't someone has an approachable reference for the standard?
while i'm sure there's many other examples, in that particular case it's just the maximum value of an unsigned 8 bit integer, as defined above on line 1252.
it would be a bit better if it explicitly had a nice #define but recognizing the values of common powers of two (minus one) is a useful code reading skill.
>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...
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.
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.
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.
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.
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?
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.
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.
No, it hasn't put an end to debate at all. This is an ugly workaround and still requires Cisco to build binaries on your behalf. It's quite a stretch of "open" and certainly not "free" (not that it claims to be).
There is still ongoing work to create a better, free standard.
Now is a great time for the next generation if VP9 really is patent free or fully licensed OR Daala is ready to take on H.265 AND that Free solution matches or beats H.265 AND that Free solution can get itself in hardware (particularly mobile) solutions in the same timeframe as H.265.
The other possibility for the Free next generation solution is if H.265 licensing is unreasonable (as H.263 was and H.264 wasn't).
For the current codec generation the ship has sailed, the deployed base of H.264 devices means the battle is over.
* Due to the nature of patents, “patent-free” tech does not exist.
* At scale H.264 is crazy cheap. It costs $6.5 million for YouTube to serve 72 billion hours of video. Still, it is infinitely more expensive than free.
I'm actually sceptical that VP9 will be good enough and patent safe enough to dislodge H.265. From what I've read about Daala I suspect it will too late to the battle. I suspect hardware support for H.265 is already well under way that a convincing improvement would be necessary to stop H.265 dominating the next decade. The advocates for Free codecs need to forget about H.264 and focus on a compelling argument to beat H.265 and get their chosen answer into hardware developments NOW. In 12 months it will be too late if it isn't already.
That doesn't mean I don't appreciate the development of these and other codecs, they are a factor in keeping the license prices reasonable.
But I suspect you're right about VP9/H.265 decisions being made now, and royalty free alternatives keeping prices down even when the alternatives don't win a lot of market share (could say the same about the never-winning "linux desktop" -- it gets negligible seats, but may have shifted $$$ from Microsoft profit to consumers over the years).
That might be the plan for Daala but it really needs to be MUCH better to make another generational change worthwhile.
I don't think VP9 can win the current fight to be honest. I doubt it is patent free, or good enough. I also wonder if Google can cooperate in the way required to build support for it outside of its Android family.
Even if Google fails to play nicely with Microsoft and Apple (who are both well known for their enthusiastic embrace of open and royalty free formats) it's still a fact that Android accounts for more than half of "smart connected device" sales (i.e. phones + tablets + desktops + laptops) and is growing that share rapidly.
Having VP8/9 support shipping on those devices is a major (though probably not fatal) blow to H.264 and 5 and will probably weigh heavily on the minds of the people currently figuring out how much they can charge for H.265 patents.
Though personally I think H.264 (particularly x264) being "good enough" and massively deployed might be a bigger issue for H.265 uptake.
1) I think that was VP8. I don't know if those patents are licensed for use with other codecs or the extent to which VP9 uses the same technology.
2) MPEG LA doesn't have patents they invite patent owners to contribute them to patent pools for a cut of revenue. Where companies have not been involved with the development of standards they are not obliged to license them on FRAND basis so there is more reason not to join a pool. Nokia at least is in the pool for various MPEG standards but not VP8, there may be others waiting to troll if large scale use occurs.
3) Nokia hadn't joined the VP8 pool and was actually using a VP8 relevant patent against an Android manufacturer. I don't know the current status of this case but if you have a link to recent news I would be grateful.
2) Yes, that's why agreements with the MPEGLA are actually with the member companies (as mentioned in [1])
3) That was Nokia asserting against HTC three times. The first one was dismissed, the second one was rejected[2]. I'm having trouble finding any information about the third (which is at the ITC, not in a court), so it may still be ongoing.
1) According to that link the VP8 patents are licensed for use in VP9 (which I had forgotten or didn't know) but there is still the possibility of new patent from existing licensees in addition to additional patent holders coming forwards.
3) The reference you give is to one of the patents but there are more than one involved. As far as I know it is still an ongoing open issue.
as for 1), it's also possible that there are h.264 patents that aren't part of the pool.
Thomson created what is essentially an MP3 license pool, and yet, Sisvel cleaned out Cebit (one of the larger electronics fairs) booths every year (with the help of German customs) because some asian vendors showed unlicensed MP3 players.
It's still possible that some non-MPEGLA party stumbles over a patent that covers some tiny aspect of h.264.
Its possible but it is now improbable that there are strong critical patents in H.264 which aren't either in the pool or at least owned by a company that participated in the standards setting (and are therefore bound by FRAND commitments). The reason I believe it improbable is that anyone in that position has hit the jackpot and are entitled to fees related to virtually every phone, television and blu-ray player currently being produced - there is no reason to wait further they can cash in now.
VP8 has not been widely deployed (at least in hardware) to anything like the same extent so the possibility of lurkers is greater.
Getting products pulled from Cebit (and German Customs helping) is for me a completely wrong on so many levels I can barely describe (at least if the products weren't for sale to the public).
Interesting enough Youtube has removed the HD WebM formats and only offers 360p for WebM and higher quality is mp4 only. Strange decision baring in mind that Google is behind pushing WebM.
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.
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.
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.
That reads more like the GPL than a definition of what open source means. What, then, do you call code that provides the source but does not allow you free distribution of both the source & binaries? "The source is open but it's not open source"?
Fluendo does this with MP3, but that license is only $50K instead of millions.
People proposed this idea repeatedly to Mozilla back in the day but they rejected it. Maybe they feel their hands are somehow cleaner if Cisco is paying instead of them.
cisco pays 6mi, and them mpegla returns 3mi to them for their patents in the pool. and if the format becomes ubiquitous, they get any few billions from this same pool from their competitors when they also license it.
I'm still confused why Cisco is even allowed to do this. Do they pay a flat license fee to MPEG-LA for unlimited usage? I would think they would pay per-seat like most video codecs.
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.
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.
Works great. You can put 3 hours of 1080p24 content on a single layer DVD (4.4 GB) and it still looks great. And there's room left for a soundtrack too.
Well it looks ok, but lots of detail is lost, especially if the source is grainy. I usually don't bother and go for 720p, but when you need great quality, you need 8-12GB for 1080p.
That's what we're all told to expect. It's not really the case. Is there some loss? Yes, of course. Is it bad, or even noticeable? Everyone who is not a video geek would not notice a thing. Heck, even I do not notice anything amiss, except for scenes with a lot of motion. This is on large high-quality screens at the optimal viewing distance.
As far as I can tell, it's not the graininess that eats up the bit budget, it's motion, and complex fine patterns. Moderately grainy sources such as average film stock don't seem to have a large visual impact. But what does have an impact is either lots of motion in the field, or complex "islamic-art-like" patterns, or especially both together.
I've put even 3 h 45 min of film stock on a single-layer DVD, at 1080p24. Again, the vast majority of people could not tell the difference. Low motion scenes were perfect. There was some artifacting on high motion segments, but it's not the ugly, blocky, unnatural stuff you see on MPEG2. It was blending into the nearby shapes, more flowing and organic-like.
2 hours or less and I can't tell the difference from the source material at all (I haven't done A/B comparisons). Around 3 hours I can tell - although it's pretty minimal. The threshold must be somewhere in between. I would only think of splitting it, or using double-layer DVD, somewhere near 4 hours.
I use the latest x264, with MeGUI, and the AVCHD profile as defined in MeGUI, with the Film tuning, and 2-pass encoding in order to hit a pre-defined file size.
I remember the days when I was transcoding 480i DV tapes onto SVCD, with mpeg2enc. We've come a long way. :)
Among other reasons, x264 is GPL-encumbered, which would make it impossible to bundle with the sorts of projects that openh264 is going to be bundled with.
It's actually dual-licenced GPL and an alternative where you don't get the so-called "viral" properties of the GPL, but changes to the code still get returned to the project, kind-of LGPL-ish.
That seems to suit what Cisco are doing here, but a Cisco representative claimed that when they suggested just using x264 that it was shot down by Mozilla (possibly because Mozilla shared the common misconception than x264 is GPL-only?)
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