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

61–70 of 144 posts

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

#61

Post by DrJosiah »

bjornsing wrote: post #56
LocalPCGuy wrote: post #51

Earlier quoted context omitted.

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

Actually, no. What Diaz showed is that Beamr is offering nothing that actually improves either visual quality or bitrate; every setting that their method uses actually reduces quality compared to default x264 settings.

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

#62

Post by waterlesscloud »

drorgill wrote: post #42
rorrr wrote: post #38

Earlier quoted context omitted.

Ok, 1) Compress the original with x264, target around 2mbit 2) Compress the result of #1 with your algorithm. 3) Compress the original with x264, target the bitrate of the result of #2 Compare #2 and #3

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?

I'm not on one side or the other here, but...

What would prove your claims?

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

#63

Post by doctorpangloss »

bjornsing wrote: post #45
doctorpangloss wrote: post #31

Earlier quoted context omitted.

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…

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

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.

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

#64

Post by Daiz »

drorgill wrote: post #60
Daiz wrote: post #55

Earlier quoted context omitted.

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

>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.

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

#65

Post by bjornsing »

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…

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.

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

#66

Post by Judson »

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…

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."

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

#67

Post by crynix »

mistercow wrote: post #57
drorgill wrote: post #50

Earlier quoted context omitted.

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…

I hope you're aware imgur compresses images that you upload to it regardless of whether they were already compressed.

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

#68

Post by james33 »

nwh wrote: post #36
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…

> 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.

Can you give examples? I've compressed thousands of files with JPEGmini and never found any banding or other loss of quality.

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

#69

Post by mistercow »

bjornsing wrote: post #52
mistercow wrote: post #35

Earlier quoted context omitted.

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.

I see now that this is what they purport to do. However I still maintain that the presentation is dishonest. Showing a comparison at 25% scale gives the impression that the tool is better at choosing "nearly lossless" setting than it really is. Look at the dog image, which on their demo appears to be identical to the original.

Now look at it at 100% scale: http://imgur.com/z12mHnd . Block artifacts galore. Now sure, it may still do a better job than just choosing a constant quality setting and applying it across the board. But the demo doesn't show us that. It doesn't even make the right kind of comparison.

What we need is a comparison of choosing a single quality level, and using JPEGmini. To be useful, here's the kind of demo we'd need to see.

On the right side: five JPEGs saved with JPEGmini, having a total file size of X, shown at 100% resolution.

On the left side: five JPEGs saved with a constant quality setting, chosen so that the total file size is X, also shown at 100% resolution.

Then we'd honestly know whether the program is worth using.

My guess? Probably not. The train station image, for example, is so grainy that you can compress it to damn near 600KB (50% in GIMP) before the artifacts are really noticeable (and well beyond that if you scale it down to 25% afterward). So did JPEGmini's visual model detect this and cut the bitrate down accordingly? No, it decided that the image should be saved at the equivalent of 83%, making the file more than twice as large as necessary. And this is on an image that was presumably handpicked as a shining example of how well the product works.

My guess is that if you just chose around a 75% quality setting and compressed all of your JPEGs that way, you'd do just as well as JPEGmini.

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

#70

Post by bgruber »

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…

i would appreciate an explanation of what you mean by "without affecting its original quality." We're talking about lossy compression, so whether that goal is achieved is purely subjective, isn't it?
Post reply on HN