61–70 of 84 posts
What about x264 hosted at VideoLAN: http://www.videolan.org/developers/x264.html ? It's open source and people have implemented tons of cool software tools with it.
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 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/... 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…
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.
would certainly help if you had a spec open.
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…
Earlier quoted context omitted.
VP9 is licensed for all MPEG-LA patents, so it has that going for it.
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 jo…
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...
Earlier quoted context omitted.
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 jo…
1) No, it included VP9[1] 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%20New…
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.
>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...
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
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.
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…
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 whic…
What about x264 hosted at VideoLAN: http://www.videolan.org/developers/x264.html ? It's open source and people have implemented tons of cool software tools with it.
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.
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?)
Earlier quoted context omitted.
From what I understand, Daala is aimed at the generation after VP9/H.265, eg https://lwn.net/Articles/571978/ 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 pro…
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.
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.