Live data from Hacker News

Cisco's Open Source H.264 Codec

github.com

71–80 of 84 posts

Re: Cisco's Open Source H.264 Codec

#71
post #23

Earlier quoted context omitted.

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 r…

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

It's possible the original code had a //comment and it was stripped when they created the F/OSS repository.

Re: Cisco's Open Source H.264 Codec

#73

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.

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.

Re: Cisco's Open Source H.264 Codec

#74

Earlier quoted context omitted.

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…

Thanks for the information. 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.

Re: Cisco's Open Source H.264 Codec

#75
post #33

Earlier quoted context omitted.

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

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.

Then write a paragraph of text. An hour writing today will save weeks of reverse engineering later.

Re: Cisco's Open Source H.264 Codec

#76
post #64

Earlier quoted context omitted.

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…

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.

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.

Re: Cisco's Open Source H.264 Codec

#77
post #74

Earlier quoted context omitted.

Thanks for the information. 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…

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).

Re: Cisco's Open Source H.264 Codec

#78
post #64
post #62

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…

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.

Re: Cisco's Open Source H.264 Codec

#79

Earlier quoted context omitted.

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. :)

Re: Cisco's Open Source H.264 Codec

#80
post #10

Earlier quoted context omitted.

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.
Post reply on HN