Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I can assure you that we did our testing against x264, and that we produced encodings that were better than x264. You're also assuming that compression optimization can only occur in the encoder - which I assure you is false (damn you NDA!! You'll have to take my word on these statements.)

As to the business of selling said encoders, I couldn't agree with you more, if you've got something that improves the most widely used encoder then surely customers should be clamoring to get a hold of this algorithm. That is if you're selling it properly.

However, I was merely a contractor, and not making the business decisions. I worked with multiple contractors that thought similar things to yourself (myself included.) And when you're taking investor money, telling them that you're going to open source a technology that took 2+ years to develop, and hope that you'll make money from it is a great way to lose your investor money.



I can assure you that we did our testing against x264, and that we produced encodings that were better than x264

By what measurement, PSNR? x264 doesn't optimize for PSNR by default.

And when was this? x264 has improved dramatically in the past 4 years. In 2007, Mainconcept could beat x264 in many cases and Ateme's 2004 encoder was still sometimes better! There are cases where x264 has improved by a factor of 2 in this time period, or more.

You're also assuming that compression optimization can only occur in the encoder

Do you mean prefiltering? Such a thing is a dishonest comparison, as you can prefilter before using any particular encoder, and there are whole frameworks built for exactly that purpose which are widely used with x264 -- and other encoders too.

And when you're taking investor money, telling them that you're going to open source a technology that took 2+ years to develop, and hope that you'll make money from it is a great way to lose your investor money.

If your technology takes 2+ years to develop, your programmers are incompetent or your management is broken. Probably no single algorithm in x264's history has taken more than a few days to develop. Coming up with good ideas is a matter of thinking, combined with trial and error: once you have a idea that actually works, implementing it is dead trivial. The time-consuming part is the other 99 ideas you tried that didn't work so well -- and you can't plan for that.


I used the term "algorithm" as a crutch, but it seems likely there are tools out there than can do fantastic keyframe & data rate shaping.

The most apparent is whatever Apple's been using for years for their movie trailers. Not a single artifact, low data rate, etc. It's better than your average 2-pass. But who knows, the "magic" could simply be to start with uncompressed source...


> However, I was merely a contractor, and not making the business decisions. I worked with multiple contractors that thought similar things to yourself

Do you know you're not talking to some contractor, you're talking to the guy behind x264?

If you don't know him, read his analysis of VP8 (note copyright footer):

http://x264dev.multimedia.cx/archives/377

Having been in the streaming industry since the mid 90's, with heavy work in live and on demand encoding, I've seen dozens of these companies make similar claims, usually in pursuit of investment dollars. For years running, regardless of open source versus closed source, none stack up well against x264 when measured for the way people see video and for the resources taken to produce the encoded content.

You really don't have to read past the first graph:

http://compression.ru/video/codec_comparison/h264_2011/

This is an informative study, and has been for the last seven years. If you have a better compression that would let me, as a CDN, offer clients movie delivery to users with enough less bandwidth and storage it's worth retooling for, we're all ears. Again, I've talked to dozens upon dozens. None really had it. So far, given their original source, I could personally produce an even smaller x264 file that end users prefer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: