Live data from Hacker News

Cisco's Open Source H.264 Codec

github.com

21–30 of 84 posts

Re: Cisco's Open Source H.264 Codec

#21
post #8

Earlier quoted context omitted.

VP8 exists, and is free 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. :)

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…

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

Re: Cisco's Open Source H.264 Codec

#22
>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...

Re: Cisco's Open Source H.264 Codec

#23

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…

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

Re: Cisco's Open Source H.264 Codec

#24

Earlier quoted context omitted.

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…

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

20 year old tech can avoid patent problems but I share you scepticism about the status of VP8/9.

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.

Re: Cisco's Open Source H.264 Codec

#25
post #23

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…

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.

Re: Cisco's Open Source H.264 Codec

#26
post #23

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…

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…

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.

Re: Cisco's Open Source H.264 Codec

#27
post #26
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…

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…

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.

Re: Cisco's Open Source H.264 Codec

#28

Earlier quoted context omitted.

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

20 year old tech can avoid patent problems but I share you scepticism about the status of VP8/9. 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…

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 profit to consumers over the years).

Re: Cisco's Open Source H.264 Codec

#29
post #20
post #3

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.

Why can't they just build ffmpeg (with only h.264 enabled), instead of their own implementation of h.264?

ffmpeg is lgpl-encumbered. Openh264 is under the much more open BSD license.

Re: Cisco's Open Source H.264 Codec

#30

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…

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