Daiz hello, this is Dror from Beamr. The technologies we have developed, JPEGmini and Beamr Video, are definitely not "Snake Oil", and I don't think it would be good practice to make such claims regarding any company's technology without checking the facts first and asking for the company's response before posting.
Our technologies for image and video compression have received excellent reviews in the media, and have been tested and proven by industry experts. You can find the reviews online, and I would be happy to send you the quotes we got from the industry experts as well. Thousands of users are using our free online photo optimization service at JPEGmini.com daily, and thousands more have purchased JPEGmini for Mac to optimize images locally, and they are all very happy with these tools.
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. Based on analysis of the image or video using a perceptual quality measure we have developed, we adaptively set the encoding parameters for each image or video. So the amount of compression for each image or video clip is different, and depends on the content and original quality of that image.
Comparing the quality of a clip encoded in Beamr Video with the quality of the same clip encoded at the same bitrate using another encoder is meaningless, since part of the uniqueness of Beamr Video is "knowing" what is the right bitrate (actually the lowest bitrate possible) for encoding each video such that it stays perceptually identical to the original clip. Beamr Video is the only 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.
The same is true for our image technology: We reduce each JPEG file to the minimum file size possible without affecting its original quality. Of course, you can take a specific file and tune a regular JPEG encoder to reach the same size on that specific file. And you can also manually tune the quality for each image using a regular JPEG encoder by viewing the photo before and after compression. But there is no other technology that can take millions of photos and automatically adapt the size of each one to the minimum possible size while preserving quality.
The clips on our website are an initial demo of Beamr Video we are offering today, based on Blu-Ray sources. In a few weeks we will launch a cloud-based Beamr Video encoding service, where everyone will be able to process their own clips and reach their own conclusions. There are free trial versions of JPEGmini available for anyone to download and try. So again, I don't understand the basis of your "Snake Oil" claim. I would be happy to continue this discussion with you privately if you like, you can email me at dror@beamr.com.
But what does that concretely mean, "lowest bitrate or file size possible"? What do you mean by "possible"?
You almost certainly mean choosing a lower bitrate whose numerical perceptual quality is similar to the video encoded at a higher bitrate. Of course, x264 can do that—that's what the CRF value is. It already has technology to choose the best bitrate per GOP given its perceptual model.
Even if I take everything you say at face value, your semantics, at minimum, are the snake oil. You make it sound like this perceptual compression technology doesn't exist, when it actually ships on by default in Handbrake.
I think what Daiz is talking about is snake oil of the technology, not semantic, variety.
So let's talk technology snake oil. Your special perceptual model might find situations where it could reduce the bitrate in a way that x264's model would disagree. But what about situations where x264's model is better? The end-user never gets to see where x264 makes a subjectively better image than your system does at a lower bitrate.
In other words, quality arbitrage: you can always claim to reduce bitrate by adjusting your model to be a bit more permissive than the competition. Knowing there is no rigorous numerical way to compare two perception-optimizing compressors, you can get away with "arbitrage" bitrate reductions.
Put another way, a lot of people are going to demand the wrong tests, because they don't understand the inherent contradiction of comparing two perception-optimizing compressors (like allegedly Beamr and x264's CRF model).
The way I'd know if your perceptual model were in fact better is if you could show me situations where it is wrong. In other words, convert your "lowest... possible" Beamr Perceptual Model parameter to a CRF parameter. You could do it subjectively. Find me situations where x264 chooses a lower bitrate than your model. At least if your model is falsifiable, it isn't snake oil.
Incidentally, Diaz did exactly this test. And your model calculate a worse bitrate than an equivalently-chosen CRF in all cases.
So your model isn't snake oil—it's just bad. Perhaps we would randomize the subjective differences, but my suspicion is the default Handbrake CRF (20.0) will work better more than 50% of the time for randomized videos against a randomized audience.
> my suspicion is the default Handbrake CRF (20.0) will work better more than 50% of the time for randomized videos against a randomized audience.
For those last few words there you actually got close to the problem, as I understand it from drorgill's explanation. So am I right to assume that you're critique, in this tone, is based solely on a "suspicion" of yours? As I read the OP this is absolutely not the test Daiz did...
Looks like Daiz did a similar test to the one I described below. Naturally we would need blindly randomized videos and randomized audiences, rather than just Daiz audience of one knowing exactly which videos were encoded by what. We'd also need some function converting the CRF parameter to the Beamr Perceptual Model parameter ("minimum possible" parameter), which we could obtain by knowing the Beamr parameter for a given CRF when Beamr and x264 choose the same exact bitrate.
randomized blind A/B testing really can make all the difference. they did the same on the Hydrogen forums, for testing lossy audio codecs, and if there was only a hint of information which bit was which, results would be heavily biased.
crazy, but that's how human perception seems to work. it also raises the question whether, at some point, this placebo effect might not be way stronger, than any actual perceptual differences left over after correcting for biases.
and if that's the case, maybe we don't need better codecs, but shinier TVs, and better people to convince us that video quality is better and more enjoyable. like snake-oil salesmen. or like that high end electronics brand that put a weight in their remote controls, just so it feels more 'solid' and high quality (brilliant idea, I forgot what brand, might've been Scandinavian).
Finding the optimum settings for a given video is a valuable product, and this makes the criticism of being just x264 irrelevant, but his quality comparison still seems valid. If Beamr is recompressing something to a lower quality at a given bitrate compared to standard techniques, this implies that you haven't actually solved the problem of finding the optimum settings. If the tool doesn't support this, it would probably be best to turn off the constant bitrate feature until it does support it well. If you make a feature available which is directly comparable to something else, you can't legitimately complain that people make the comparison.
We don't have a constant bitrate feature. And the comparison you refer to was not done on content encoded with Beamr Video, but on content encoded with "Beamr-like" settings for an x264 encoder. Since we are controlling the video encoding at the frame level, these comparisons are meaningless.
I'm going to answer you in detail, but it's going to take a while since I'm going to do some additional test encodes for it.
Also, you should note that I am only talking about your Beamr Video product in my post - I haven't used or tested your JPEG tools, so bringing them up here is largely irrelevant. Also, even if you have developed something effective for JPEG, does not mean you could develop something equally effective for a much more complex format like H.264.
> We reduce each JPEG file to the minimum file size possible without affecting its original quality.
This is blatantly incorrect. In files encoded with JPEG mini, there is visible banding. They are smaller, yes, but there is certainly a perceptual difference in image quality. I tried it myself.
When JPEGMini came out I thought it was a hoax. I've been working with various image compression tools since 1992, and was highly skeptical about their claims, but after encoding a ton of edge cases, I was convinced it was the real deal.
Have since encoded thousands of images for various clients with JPEGMini, and have never noticed ANY difference or persistent issues. Most of all, it saves me from having to experiment with individual image optimization settings. I always use it as a last step in every development project (last step because it has the annoying 'feature' that it overwrites the originals).
I dare you... Give me the original JPEG of your PNG samples (you DID start out with a JPEG, right?) and I'll repeat your experiment with my local JPEGMini install, then upload them to IMGUR for re-post here.
As to the issue at hand (Beamr/Snake-Oil): if Beamr saves me the trouble of manually having to fiddle with all kinds of optimization parameters to get very good result, much more difficult for video than JPEG, because scenes and requirements change, then that too is worth my time and money.
To be clear: I have nothing to do with Beamr or this company. I've been lurking around on HN for a long while, check my profile. The original Diaz post and claims like yours are simply a load of crock.
PS I know you can get better compression results with JPEG2000 and various more obscure formats, but the clincher for me has always been that the end result was straight ole JPEG. Works everywhere.
Ignoring the fact that the original image [1] had banding issues (e.g. top left), and ignoring the fact that JPEG is a format which optimizes file size by taking advantage of the limitations of the human eye as well as typical properties of REAL photographs (ie NOT cartoons, and NOT images with largely the same tone {'orangy' in this case}), I think you have to agree that my result from the standalone JPEGMini app [3], is markedly better than your "lossy" example [2]
Your lossy sample is brighter, has major artifacts around pointy hair bits, the sickle, etc. and in zoomed in mode, which is not how you should compare these things, there's a distinct lack of detail.
If you were to repeat the same comparison with a realistic photo, the differences between the original and the jpegmini version, there are some, but you have to look hard, would be even less noticeable.
Please note: JPEGMini does not allow me to set any parameters at all.
In short: a single drag/drop on my part reduced a file from 1.8MB to 410kB and differences are extremely minimal. Another win for jpegmini.
I used the exact same application as you did. JPEGmini lite from the App Store. I'm not sure what could account for the discrepancies between our examples. As you mentioned, there's no possible parameters either of us could have changed.
> and in zoomed in mode, which is not how you should compare these things
I see no issue with zooming to demonstrate already visible compression artefacts.
> ie NOT cartoons, and NOT images with largely the same tone
JPEG compression actually looks better on images with flat areas of color of gradient. This can be demonstrated by exporting an image in the format with and without a very slight gaussian blur added to the image. The results are typically a good deal smaller with the blur applied.
> I used the exact same application as you did. JPEGmini lite from the App Store. I'm not sure what could account for the discrepancies between our examples. As you mentioned, there's no possible parameters either of us could have changed.
I used the non-lite version (ie I paid for it). Version 1.4.2 to be exact (I see the latest version is 1.4.3). Not sure if the "full" and "lite" version are using different compression levels or algorithms. I do know that older versions had a much lower megapixel limit.
> I see no issue with zooming to demonstrate already visible compression artefacts.
I do, because that's the crux of the story. JPEGMini (and Beamr too I guess), provide VISUALLY similar results with smaller file size and with a minimum of effort required.
Loss of information is inherent to lossy compression. Achieving a file size reduction requires that sacrifices are made somewhere, typically by removing detail. The trick is making these sacrifices in the right places, so that before and after appear the same.
If the processed image is displayed at 800x600 on a monitor with 150DPI, one would make different choices/assumptions about what to sacrifice than if the resulting image is viewed at 300% magnification. JPEGMini's feat is making the right sacrifices (note that they do NOT change the compression method, the end result is a STANDARD jpeg file, not a special format).
> JPEG compression actually looks better on images with flat areas of color of gradient. This can be demonstrated by exporting an image in the format with and without a very slight gaussian blur added to the image. The results are typically a good deal smaller with the blur applied.
Correct, but photos are still very different from cartoons, vector graphics, text, etc (think: colors occurring in nature vs colors picked by a designer, inherent blurriness of large parts of a photo, very few hard edges in most photos, the human visual model - color, luminance vs chrominance, filling in the gaps etc etc).
That image has too much noise. You need smooth gradients to get banding. The pony, the smoothest part of the image, has a lot of sensor noise (more chroma than luma but still) in the 3-6 pixel frequency range.
I was trying to prove my photo point ("If you were to repeat the same comparison with a realistic photo, the differences between the original and the jpegmini version, there are some, but you have to look hard, would be even less noticeable.")
There's certainly less impact on that image. The lower left section looks awfully blocky, but that's somewhat to be expected given the size of the image. The main difference in all of these examples is the loss of CCD noise, which could be considered a good or bad thing depending on your aim.
The decision Beamr Video makes are "smarter" than x264's CRF mode, since they are based on a perceptual quality measure we have developed. This quality measure is similar to the one used in JPEGmini, our image optimization technology, and has been proven (in standard ITU BT.500 testing) to have higher correlation with subjective results than other quality measures such as SSIM.
I'm no expert on this matter, so apologies if this is a dumb question, but: has the perceptual quality measure used in CRF been subject to the same ITU BT.500 testing?
If it hasn't, then I'm afraid your case remains unproven.
If that is so, show examples of video files which prove it! Show us some uncompressed video files which compress both smaller and with better quality using Beamr (as compared to x264's CRF mode).
Being generous - It sounds like beamr has a tool that can choose, for a given input video, which minimum crf option will provide a 'transparent' transcode.
Care to elaborate on this? As someone who has spend a considerable amount of time with video encoding, please cite your so called "experts", or is this just another bold weightless claim?
>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:
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.
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.
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.
> 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.
I'll give you this Daiz: you have now done something that begins to resemble a fair evaluation of Beamr, and that's only 2 hours after you posted your original conclusion!
For the record: I have nothing to do with this Beamr thing, but I do feel sorry for those guys. Despite your 50 min evaluation here I'll give them the benefit of a doubt and conclude they're probably hard working honest people trying their best to build something valuable in this world, and sell it. If your analysis holds up they may have failed, but that's no crime.
You seem quick to dismiss his review. While the branding of "snake oil" may be an overly strong term, it might not be incorrect: the evidence I've seen thus far (as a user admittedly unfamiliar with the subject) does seem to point to profit off open-source work. But if we were always so quick to give the benefit of the doubt while ridiculing investigations as you did, the thievery would be out of control. I will say that this situation seems like we could take a lesson from Mr. Musk though, and make statements instead of accusations. I'll be interested to see how this turns out.
If you pay close attention to the lines around the woman's mouth in Clip 1, CRF 18.5 seems to have more defined lines and freckles (i.e. more signal in image processing parlance).
From the long answer above - and I'm no video expert - the tl;dr is that Beamr answers the following question and returns a video that fulfills the answer:
"Given that you are concerned with ZERO loss of quality in the output video, what is the optimal per-frame compression that minimizes output video size."
I am somone with a very low understanding of Video compression, who (working in a small company) had to create a "simple video compression system" for the dozen of videos we put online everyday.
I'm saying that becaouse I'm probably someone that may be interested in Beamr technology since my "video compression system" is mostly a bad mash up of mencoder and handbrake with a few tweaks that is used for automatically convert all our videos for the different bitrate/devices we stream to.
The problem is that most of what you find in your website or your comment is marketing enhanced technical dumbed down mumbo jumbo.
What someone with a little (very little) understanding of video compression would like to see is an example of Beamr working it's "magic" and see if it's really effective.
A simple test would be to take a random sizable selection (at least 5/600) of different videos from different sources encoded with Beamr or with a vanilla version of x264 or others encoders tools.
Then show us a chart (geeks love charts) of the difference in compression and (some examples of) the difference in quality to let us see how amazing Beamr actually is.
Dror, if you re-read the review, it's quite obvious that the root of the backlash is not in what you claim, but rather in not giving an explicit credit to x264 team.
To everyone else - there's a very simple resolution to this situation. In fact, it will straighten itself up in, because if what Beamr did is trivial and working, I doubt x264 project will have any problem replicating it. If it's not working, then Beamr video service won't take off. And, lastly, if it's working and non-trivial, then their claims are true. As others said, the only way to confirm or deny their claims is to test against larger collection of clips and with real people. Well, duh, that the exact opportunity that their video service is going to provide. Let's just wait and see how it plays out.
3) a 2-Mbit video compressed with x264 with reasonable settings.
Until you present evidence, that article has very valid criticisms, which you have not addressed. Instead you went full PR astroturfing telling how great your tech is.
I think what Dror is saying that if you take #3 and run it through their tool you'll get a smaller size with the same quality. So it's some sort of h.264 post-processor... I agree evidence would be nice.
That's not what I think he's saying. I think he's saying that the whole point of Beamr is to not have to choose a fixed 2 Mbps bitrate. Thus the test should be:
So the post should contain:
1) a random selection of high quality original videos (30-40 Mbit).
2) those videos compressed with Beamr.
3) those videos compressed with x264 - ALL WITH THE SAME OPTIONS - those options tuned to match the average bitrate of #2.
Notice the difference between #3 and what Diaz has done: he has tuned the parameters manually for each and every video file. IMHO that's a rather harsh comparison: "Hey scumbag! Your software is worthless because a really smart and dedicated human can do it just as well/better!!!"
bjornsing, I think you might not understand what Diaz is doing. He is not manually tuning the parameters for each video file. He is actually letting x264 automatically choose the bitrate and encoding parameters, to achieve a desired level of quality.
The way I understood it is they say they optimize bit rate for a given perceptual quality and their secret sauce is that they measure perceptual quality in a way that approximates what people actually see more closely. They "aim" for the same quality in the video you feed them and try and optimize bitrate. An example would be finding coefficients in a macroblock that could be further quantized without sacrificing perceived quality. So to me it makes some sense though I can't put a number of what you could gain with this sort of secret sauce, that is how much is there to squeeze out of already well optimized videos that use other measures. I would imagine the applying this secret sauce to the original video would be a better idea since quality measure is inherently something that depends on a reference. Almost by definition any change to a compressed video is reducing its quality (but perhaps they "reduce" things you can't see).
Since this is about perception it's really hard to measure. I looked at some of the comparisons people have done of the demo images and if you look carefully in some background areas you will see noticeable difference in quality between two images that people claim to be equal.
As your attention is naturally drawn to the foreground most people wouldn't notice that.
Beamr Video is not a bitrate-driven encoder - you cannot specify the bitrate of the output clip, so we cannot provide 2). We can only provide an output clip with the same quality as the input and lower bitrate, but we can't guarantee in advance what that bitrate would be. That is the basic difference between Beamr Video which is a quality-driven video optimization technology, and a regular video encoder that is typically bitrate-driven.
You could compress something with Beamr first, see what bitrate it spit out, then compress with standard encoder at the same bitrate. This isn't perfect since it's clearly favoring Beamr, but it would be somewhat useful.
How would this be "favoring Beamr"? I'd see it as piggybacking on a potentially useful Beamr innovation. Someone slightly more fanatic about IPR might even call it "theft".
As I understand it, the whole point of Beamr is that you don't have to manually tune the parameters for each video file.
It took me a few reads to see what you meant. I had taken Beamr to be about optimizing things like which what size blocks to use, how often to put i frames, and so on, which means better perceived quality at some bitrate. If it's always using the same settings and the only smartness is about what framerate to pick, then you would be correct.
Even if you compare #2 and #3 and they are similar quality, what would that prove? You could do #3 for a specific file after Beamr Video has processed it, but how would you know the right bitrate for #3 without applying Bearm Video in #2?
Independent person from the industry here following this (as I am sure there are many more onlookers to this thread).
drorgill i think now is the time to provide some hard empirical evidence on your part, given the initial claims and a sample test done here it is my feeling that it should be relatively trivial to provide a counter example. cheers.
Our technologies for image and video compression have received excellent reviews in the media, and have been tested and proven by industry experts. You can find the reviews online, and I would be happy to send you the quotes we got from the industry experts as well. Thousands of users are using our free online photo optimization service at JPEGmini.com daily, and thousands more have purchased JPEGmini for Mac to optimize images locally, and they are all very happy with these tools.
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. Based on analysis of the image or video using a perceptual quality measure we have developed, we adaptively set the encoding parameters for each image or video. So the amount of compression for each image or video clip is different, and depends on the content and original quality of that image.
Comparing the quality of a clip encoded in Beamr Video with the quality of the same clip encoded at the same bitrate using another encoder is meaningless, since part of the uniqueness of Beamr Video is "knowing" what is the right bitrate (actually the lowest bitrate possible) for encoding each video such that it stays perceptually identical to the original clip. Beamr Video is the only 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.
The same is true for our image technology: We reduce each JPEG file to the minimum file size possible without affecting its original quality. Of course, you can take a specific file and tune a regular JPEG encoder to reach the same size on that specific file. And you can also manually tune the quality for each image using a regular JPEG encoder by viewing the photo before and after compression. But there is no other technology that can take millions of photos and automatically adapt the size of each one to the minimum possible size while preserving quality.
The clips on our website are an initial demo of Beamr Video we are offering today, based on Blu-Ray sources. In a few weeks we will launch a cloud-based Beamr Video encoding service, where everyone will be able to process their own clips and reach their own conclusions. There are free trial versions of JPEGmini available for anyone to download and try. So again, I don't understand the basis of your "Snake Oil" claim. I would be happy to continue this discussion with you privately if you like, you can email me at dror@beamr.com.