Okay then, you asked for it, so here you go.

>The important thing regarding our technologies, and the main point you have missed in your analysis, is that they are used for automatic image optimization to the lowest bitrate or file size possible, and not for encoding an image or video to a specific bitrate or file size.

This is exactly what the CRF mode in x264 is for. Now, in another comment you're claiming the following:

>The decision Beamr Video makes are "smarter" than x264's CRF mode, since they are based on a perceptual quality measure we have developed.

Let's see how well that measures up to reality then, shall we? For this comparison, I used the same four clips as earlier, and ran each of them against the following command line:

  x264 --crf 18.5

That's it. Completely default settings, with the exception of setting the CRF to 18.5 for everything. This shall be our vanilla x264 equivalent of your "technology that can adaptively reduce the bitrate of any clip to the minimum amount possible, while ensuring that quality of the output clip is perceptually identical to the quality of the input clip". Since we're using the same value for everything, it involves as much choosing on the user end as your service would. Now then, let's see how your "smarter than CRF" technology actually fares against x264's CRF. Here are the results:

* Clip 1 - http://check2pic.ru/compare/26755/ (CRF 18.5 encode is ~11.7% smaller)

* Clip 2 - http://check2pic.ru/compare/26756/ (CRF 18.5 encode is ~4.4% smaller)

* Clip 3 - http://check2pic.ru/compare/26757/ (CRF 18.5 encode is ~17% smaller)

* Clip 4 - http://check2pic.ru/compare/26758/ (CRF 18.5 encode is ~19.5% smaller)

( The full videos are available here: http://blisswater.info/video/beamr/set3/ )

As we can see from the comparisons, x264, at defaults setting and CRF 18.5, can produce practically identical visual results (as in you wouldn't notice any quality difference in action), while producing smaller bitrates all over the board. Looks like your supposedly "smarter than CRF" technology for choosing bitrates isn't so smart after all, eh?

In short, even if you have developed some sort of quality-based bitrate-choosing technology of your own, in practice it still seems to lose consistently to x264's CRF mode (and since x264 actually allows you to control the CRF value, it's much more versatile than your "no quality settings at all, we know best" offering). As such, given the substantial claims about the capabilities of your technology, the Snake Oil verdict shall remain.