Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Buy the Snake Oil of Beamr Video

gist.github.com

Post reply on HN
Print view View original

51–60 of 144 posts

Re: Don't Buy the Snake Oil of Beamr Video

#51

Post by LocalPCGuy »

Daiz wrote: post #5
wmf wrote: post #3

ICVT actually developed some interesting algorithms, but it's a shame they're letting marketing hyperbole overshadow it. Another case where technical innovation doesn't sell, I guess.

Even if they had actually developed some "interesting algorithms", they sure don't seem to be using them, at least not in the actual video encoding process. There's really no other explanation for the fact that you can end up with practically identical video to Beamr's examples when using largely identical settings and bitrate with vanilla x264.

There actually is an argument that if they can do as good a job as a manual encoding but automate the process, that is valuable, even if the encoding process is the same as the manual process. If you had thousands of videos to encode, they all probably wouldn't be optimally encoded at the exact same settings, and automating that task could save a significant amount of time.

Re: Don't Buy the Snake Oil of Beamr Video

#52

Post by bjornsing »

mistercow wrote: post #35
haven wrote: post #4

The folks behind Beamr H.264 also have a 'patent pending', proprietary JPEG image "recompression technology": http://www.jpegmini.com/ I'm curious what an analysis of one of their JPEG's would show?

Downloading the ros-k sample and playing with it in GIMP, it looks like exactly the same kind of chicanery using a few simple steps: 1. The "original" image is saved at a very high JPEG quality setting, somewhere around 99% by GIMP's figuring 2. The "JPEGmini" version is saved with a slightly lower, but still high quality setting of about 85%. 3. The "comparison" on the website shows the images scaled down to 25% of…

Well, yes. But I think the whole point of this technology is that you don't have to come up with the 85% number.

It can be a lot of work to find the lowest quality setting that will be perceived as (near) lossless. Think millions of files.

Re: Don't Buy the Snake Oil of Beamr Video

#53

Post by chebert »

At first I was all, "oh man -- another small company trying to rip me off."

Then I was all, "oh man -- this actually seems like a pretty cool product"

I actually hate choosing compression settings, so for a piece of software to choose compression settings for me seems really nice.

Up to 4x -- so what if it is "over the top"? That's advertising. You present your best results. You pick the stuff that sounds the best. Why? Because people are usually too ignorant (not necessarily a bad thing) to know what is good for them.

Anyway. Props to you guys (drorgil) for making a good product and standing by it.

Re: Don't Buy the Snake Oil of Beamr Video

#55

Post by Daiz »

drorgill wrote: post #19

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…

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.

Re: Don't Buy the Snake Oil of Beamr Video

#56

Post by bjornsing »

LocalPCGuy wrote: post #51
Daiz wrote: post #5

Earlier quoted context omitted.

Even if they had actually developed some "interesting algorithms", they sure don't seem to be using them, at least not in the actual video encoding process. There's really no other explanation for the fact that you can end up with practically identical video to Beamr's examples when using largely identical settings and bitrate with vanilla x264.

There actually is an argument that if they can do as good a job as a manual encoding but automate the process, that is valuable, even if the encoding process is the same as the manual process. If you had thousands of videos to encode, they all probably wouldn't be optimally encoded at the exact same settings, and automating that task could save a significant amount of time.

Yea, but what Daiz proves in the OP is that he personally can do a better job than this so-called "algorithm". I hear his next project will be proving the worthlessness of spell checkers by simply beating them, at spelling. That paper clip thing in Word is such Snake Oil! ;)

For the record I have nothing to do with this Beamr, but I do feel sorry for the those guys. The marketing speak on their website may be a little hyperbole, but there's nothing fraudulent there that I can see. I don't think they deserve this treatment.

UPDATE: LocalPCGuy, sorry for posting this as a reply to your comment. You obviously get it.

Re: Don't Buy the Snake Oil of Beamr Video

#57

Post by mistercow »

drorgill wrote: post #50
lwat wrote: post #43

Earlier quoted context omitted.

I downloaded the pic of the dog, opened the 'Original' in Paint.net, re-saved it at the same filesize as the JPEGmini version and it's indistinguishable from the other two versions. JPEGmini doesn't seem to do anything that I can't already do in any image editor. Looks like snake oil to me.

Note my previous reply on this issue: JPEGmini adaptively encodes each JPEG file to the minimum file size possible without affecting its original quality (the output size is of course different for each input file). You can take a specific file and tune a regular JPEG encoder to reach the same size as JPEGmini did on that specific file. And you can also manually tune the quality for each image using a regular JPEG en…

>JPEGmini adaptively encodes each JPEG file to the minimum file size possible without affecting its original quality

That is indeed what the FAQ says, but that being the case, the tool does not actually work very well, and the presentation is incredibly dishonest. The fact is that the JPEGmini versions of these images do lose noticeable quality, but Beamr is hiding this by giving a demo where the images are shown at 25% scale.

Take the dog image, for example. Using the slider, you'd think that JPEGmini nailed it; no visible artifacts whatsoever. But let's look at a section of the image at 100% scale, and see if this tool is really that impressive: http://imgur.com/z12mHnd

...holy block artifacts Batman!

Re: Don't Buy the Snake Oil of Beamr Video

#59

Post by Pitarou »

drorgill wrote: post #28
teraflop wrote: post #23

Earlier quoted context omitted.

What you've described sounds a lot like x264's --crf option, which adaptively chooses a bitrate based on the input. How is Beamr different?

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.

Now we're getting to the nub.

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.

Re: Don't Buy the Snake Oil of Beamr Video

#60

Post by drorgill »

Daiz wrote: post #55
drorgill wrote: post #19

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…

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 foll…

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.

Post reply on HN