Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cisco's Open Source H.264 Codec

github.com

Post reply on HN
Print view View original

31–40 of 84 posts

Re: Cisco's Open Source H.264 Codec

#31

Post by josephlord »

mlinksva wrote: post #28
josephlord wrote: post #24

Earlier quoted context omitted.

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

Re: Cisco's Open Source H.264 Codec

#32

Post by andrewf »

crbnw00ts wrote: post #12

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.

Re: Cisco's Open Source H.264 Codec

#33

Post by lyndonh »

hughlomas wrote: post #25
_wmd wrote: 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 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.

Re: Cisco's Open Source H.264 Codec

#34

Post by JasonFruit »

lyndonh wrote: post #33
hughlomas wrote: post #25

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.

I find quite often a little hard to believe. Occasionally, maybe; and why not provide a paragraph of text? Sometimes it's the right thing to do.

Re: Cisco's Open Source H.264 Codec

#36

Post by sliverstorm »

technomancy wrote: post #11
atonse wrote: 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.

"Free as in as long as you don't try to compile your own." If you think that addresses the issues at play, you haven't been paying attention to both sides of the debate.

Open source does not mean free to build & use. It means open source.

Re: Cisco's Open Source H.264 Codec

#37

Post by sliverstorm »

atonse wrote: 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.

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.

Re: Cisco's Open Source H.264 Codec

#39

Post by dpe82 »

Sanddancer wrote: post #29
anon4 wrote: post #20

Earlier quoted context omitted.

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.

For WebRTC they also need an encoder. ffmpeg uses libx264 for encoding H.264, which is GPL.

Re: Cisco's Open Source H.264 Codec

#40

Post by dpe82 »

who8mylunch wrote: post #38

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.

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