Hacker News Reader

Comment by drorgill | Hacker News Reader

Again, you are missing the point. Where did the CRF number of 18.5 come from? Did you test several parameters, and found what parameter gives lower bitrates than Beamr Video on this specific clip set?

Would you apply the same CRF parameter of 18.5 to any video file to reduce its bitrate? And does this parameter ensure reducing the bitrate of any video file without hurting its quality? If so, you could apply it recursively on a video clip and reduce bitrate indefinitely...

The bottom line is that there is no setting of x264 that guarantees reducing the bitrate of ANY input video file while maintaining its visual quality. And this is exactly what Beamr Video guarantees.

View on HN

>Did you test several parameters

Nope. I just picked a value and tested what I'll get with it. Also, it doesn't matter where the number comes from. As long as I'm not changing it for different videos, the bitrate selection is completely up to x264's CRF mode. And what do you know, here it produced smaller results than your technology while providing the same level of quality!

>Would you apply the same CRF parameter of 18.5 to any video file to reduce its bitrate?

That's what I did for all the test videos here, and it produced better results compared to your technology on all of them (basically identical quality, smaller filesizes).

>And does this parameter ensure reducing the bitrate of any video file without hurting its quality? If so, you could apply it recursively on a video clip and reduce bitrate indefinitely...

Constant lossy re-encoding is going to degrade video quality no matter what - nothing is going to change that. Not your technology, not x264's CRF. Why are you even bringing up something as silly as this?

>The bottom line is that there is no setting of x264 that guarantees reducing the bitrate of ANY input video file while maintaining its visual quality. And this is exactly what Beamr Video guarantees.

I have just demonstrated that encoding with x264 --crf 18.5 is a more effective solution than your technology on all your presented test cases. You have given us absolutely nothing to actually "guarantee" your claims, which is exactly why your product is Snake Oil.

> it produced better results compared

"better" = "smaller files"

But how did the visual quality compare between the original and two compressed versions (yours and Beamr's)?

> Would you apply the same CRF parameter of 18.5 to any video file to reduce its bitrate? And does this parameter ensure reducing the bitrate of any video file without hurting its quality? If so, you could apply it recursively on a video clip and reduce bitrate indefinitely...

> The bottom line is that there is no setting of x264 that guarantees reducing the bitrate of ANY input video file while maintaining its visual quality.

Wait wait, what? so Beamr Video can be applied recursively on a video to reduce bitrate indefinitely?

You actually claim that Beamr Video can reduce the bitrate of any input video while maintaining its visual quality?

Listen, if you're in the business of data compression, you can't really just not know about the Pigeon Hole Principle and not make a fool of yourself sooner or later.

Also, just like talk of perpetual motion has no place in a serious discussion about energy efficiency, neither does talk of infinite data compression have any purpose in a serious discussion about data compression and bit rates. Regardless of whether you just claimed that your technology does that, or whether you just claimed that an industry-standard open source encoding solution with default settings ought to do this, in order to be compared to your technology.

> And this is exactly what Beamr Video guarantees.

I got some videos of white noise, I need them bit-identical, but smaller. Claude Shannon died 12 years ago, what's he gonna do about it? That silly Source Coding Theorem can't tell us what to do, or claim, right?!

Nice response. I'd phrase my own rebuttal like this:

If you repeatedly apply lossy compression to a video, you'll find that the video either very quickly balloons or becomes a blocky or blurry mess. The encoder ends up spending bitrate to preserve compression artifacts, and the bit bill keeps growing. This is something that x264, even in its efficiency, can't get around, and if Beamr is just tweaking x264's setting knobs, it doesn't have a snowball's chance in hell of doing better.

If Beamr is just offering a fire-and-forget solution to tweaking x264's settings, they should just say so and provide some hard counterevidence to Daiz's report. There's no shame in trying to offer a tweaked encoding service, but they'd better be able to back it up when challenged by evidence.

Making statements that are technically unlikely or impossible hurts the speaker's credibility and chances of garnering goodwill. It might have worked for Monster's mass-marketed cables, but it probably won't fly in a more technical group of consumers.

You write that "The bottom line is that there is no setting of x264 that guarantees reducing the bitrate of ANY input video file while maintaining its visual quality. And this is exactly what Beamr Video guarantees."

So, turning this sentence around, Beamr Video guarantees to reduce the bitrate of any input video file while maintaining its visual quality. (I think that's what you're saying. Please explain if not.)

So what happens if I take an input video file, run it through Beamr Video, and then take the output and run it through Beamr Video again? Is the output the same size or smaller?

If the file is the same size, the statement that "Beamr Video guarantees to _reduce_the_bitrate_ of any input video file..." can't be true.

If the file is smaller, what happens if we repeat the process again... and again... and again. We started with a file containing a finite number of bits. If each iteration reduces the number of bits, we eventually end up with an empty file. Obviously, it's not possible to maintain visual quality when there is no data, so the statement that "Beamr Video guarantees to reduce the bitrate ... _while_maintaining_its_visual_quality_" can't be true.

Either way, I can't see how your statement can be true.

The crfs are based on perceptual quality from the docs: 18 is visually lossless

http://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide#crf

Reply on news.ycombinator.com