Don't Buy the Snake Oil of Beamr Video

Most h264 encoders suck. If you take an h264 recording from your camcorder / phone / ip camera / blu ray rip, and push it through x264 (and no special configuration), you usually get 30% bit rate reduction with no loss of quality. With tweaking, you very often get 50%-75% bit rate reduction with no loss of quality, but you have to actually tweak. (e.g., I'm getting ~65% bit rate reduction on h264 streams coming out of Axis IP cameras by running through x264 with -tune slow ant no other change).

Beamr's claim to fame appears to be that they automate this tweaking. Diaz' claim seems to be that "--crf 18.5" is a tweak that can consistently deliver better bitrate reduction than Beamr.

My opinion: If you can use the x264 commandline, Beamer is probably overpriced for you. But if you're a professional photographer with no serious computer skills, Beamr might be useful for you. (Assuming they actually deliver something better than --crf 18.5 ; a claim of which I have no knowledge, but I will assume for the sake of argument)

"better" = "smaller files"

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

Witness here how certain posters seem determined to trash the product. No matter what the defenders say, they simply must come back with something, and they will keep going until the defenders simply give up. Notice each attempt subtly shifting the goal posts each time the defending argument is put.

Do I want to post examples? Absolutely no. All that will do is end up the same way. No matter what I say, there will be endless comebacks until people get annoyed with the whole thing ending up in a similar cycle. I'll leave it as one of those things a read can decide for themselves.

So be careful, the use of the term snake oil can tell you as much about the person using the term as it can the target.

The funny thing is, this is the sort of thing that H.264 encoders intrinsically do. x264 has some fairly advanced algorithms in it to optimize for human visual perception (thanks DarkShikari, akupenguin, et al).

I assume these guys are basically determining settings to feed to x264. (They can't be modifying x264 itself since they'd then need to submit their source code changes upstream, if I've read the other replies right.)

If all they're doing is turning x264's settings knobs, they'll have to have studied the effects of those knobs in depth. I can hardly see how any analysis they're doing can be usefully turned into settings for x264. I find it a bit difficult to phrase my reasoning, but I'll try:

-----

- Trying to outdo x264's analysis at optimizing for perceptual quality while still depending on it is like trying to optimize a car engine from the driver's seat. It's not likely to happen.

- x264's settings are, generally speaking, macroscopic - they apply to the whole video segment. (You can apply different settings to different segments, but in the end your control is still limited by whatever knobs x264 offers.)

- If there were a way to optimize things better than x264 has, it almost certainly requires working directly within the encoder's analysis code itself rather than carrying out a pre-encoding analysis process and then fiddling with rough-control knobs. I simply doubt the complex interplay of settings within x264 lends itself to mere knob-turning. Many of the settings are mainly for making tradeoffs among the impossible trinity of encoding speed vs output quality vs output bitrate, rather than to allow the encoder to improve the output perceptually (because that's x264's job).

- Even if they managed to build a pre-analysis model that figures out decent settings to feed into x264, it would break to some extent whenever x264's code/algos are changed. That doesn't seem like a stable base to build a business on.

- All the above reasoning is overkill, because the settings the Beamr encoder turned out look outright silly to me: setting b-frames to 0 is just shooting x264 in the foot (b-frames are central to bitrate savings through discarding unnecessary visual data). Plus it turns off mb-tree and psy in 3 out of 4 samples, which basically discards two of x264's more powerful adaptive bitrate-vs-quality features. (mb-tree detects motion and saves bits on and around moving objects; psy is various optimizations for psychological quality perception, e.g. grain level.) It's just plain regressive.

-----

More fundamentally, the claim that "a minimum bitrate for visually lossless encoding of a video can be found" is quite doubtful, because of the fuzziness of the claim and its assumptions. The trouble is, a pure marketing line like this is easy to sell to a non-technical crowd. And x264 is good enough that anyone re-encoding a crappy source with it will find good bitrate savings, even with dumb settings.

Anyone looking to encode video in the cloud should instead use a well-priced, well-tuned service that doesn't overstate its case. Daiz suggested Zencoder, so it's probably a good bet. People who just want to shrink videos should grab Handbrake or any other x264-using encoder package, and use one of the presets (or just stick to the defaults). The result will probably be better than this service, as things stand.

(Thanks for patrolling the video frontier, Daiz.)