Cisco's Open Source H.264 Codec
github.com
github.com
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.
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.
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.
https://github.com/cisco/openh264/blob/master/codec/encoder/...
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?
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.
I don't really speak C++ though, so maybe this is normal.
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
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.
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.
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.
would certainly help if you had a spec open.
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...
Makes sense that Cisco would be using CBP after seeing this on Wikipedia:
"this profile is most typically used in videoconferencing and mobile applications"
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.
While initially, members of the project seemed to be from the same Cisco family, it looks welcoming: https://github.com/cisco/openh264/blame/master/CONTRIBUTORS
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.
Contributors are 100% Chinese. Is this project make in Cisco China R&D?
https://github.com/cisco/openh264/blob/3747f562492ea301b84e3...
view history here
https://github.com/cisco/openh264/commits/master/CONTRIBUTOR...
What Cisco did seems to have put an end to all those debates, and h.264 is available for all, with patents intact, etc.
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.
There is still ongoing work to create a better, free standard.
VP9 exists, is better and free (in Chrome, will be in Firefox release in a few months)
There is still ongoing work to create a better, encumbered codec, h.265
There is going work to create a much better, free codec, Dalaa
Now is a good time to finally break free of encumbered video codecs. If not now, when. :)
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.
[Edit: replaced 'open' with 'Free']
* 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.
Agree H.264 is cheap but I think you underestimate how cheap. Internet delivered video that is not subscription or pay per view is free!
http://www.mpegla.com/main/programs/avc/Documents/avcweb.pdf
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).
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.
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] http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachme...
[2] http://www.osnews.com/story/27245/VP8_does_not_infringe_on_N...
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.
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.
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).
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.
just replace mpegla with google.
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.
they are still the bad guy in this.
If you think that addresses the issues at play, you haven't been paying attention to both sides of the debate.
"Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:"
Without being able to build and use it, the "derived works" section can't be met.
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. :)
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?)