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

41–50 of 144 posts

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

#41

Post by drorgill »

kevinpet wrote: post #30
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…

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

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.

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

#42

Post by drorgill »

rorrr wrote: post #38
drorgill wrote: post #26

Earlier quoted context omitted.

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

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?

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

#43

Post by lwat »

drorgill wrote: post #33
dangrossman wrote: post #12

Earlier quoted context omitted.

The files in the before/after preview slider are exactly the same file size when they're supposed to be showing how their compressed image looks as good as the original. They're also not the same files you get when you click the download button.

Those are just preview files used for fast page load, but they are based on resized versions of the original and the JPEGmini version. You are welcome to download the original and JPEGmini full resolution files, and compare them at "Actual Size" (100% zoom).

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.

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

#44

Post by Hello71 »

niggler wrote: post #11

They explicitly state "The technology works in the domain of standard H.264 video, resulting in video streams that are fully compatible with any media player or consumer device." Assuming H.264 compatibility, what techniques could be applied to compressing videos?

> Assuming JavaScript compatibility, what techniques could be applied to minifying code?

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

#45

Post by bjornsing »

doctorpangloss wrote: post #31
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…

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

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

#46

Post by [deleted] »

drorgill wrote: post #33
dangrossman wrote: post #12

Earlier quoted context omitted.

The files in the before/after preview slider are exactly the same file size when they're supposed to be showing how their compressed image looks as good as the original. They're also not the same files you get when you click the download button.

Those are just preview files used for fast page load, but they are based on resized versions of the original and the JPEGmini version. You are welcome to download the original and JPEGmini full resolution files, and compare them at "Actual Size" (100% zoom).

[deleted]

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

#48

Post by bjornsing »

kevinpet wrote: post #34
drorgill wrote: post #26

Earlier quoted context omitted.

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

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.

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

#49

Post by bjornsing »

YZF wrote: post #37
rorrr wrote: post #22

Earlier quoted context omitted.

So post 1) a high quality original video (30-40 Mbit). 2) a 2-Mbit video compressed with your algorithm. 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. PROVE YOUR CLAIMS.

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

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

#50

Post by drorgill »

lwat wrote: post #43
drorgill wrote: post #33

Earlier quoted context omitted.

Those are just preview files used for fast page load, but they are based on resized versions of the original and the JPEGmini version. You are welcome to download the original and JPEGmini full resolution files, and compare them at "Actual Size" (100% zoom).

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 encoder by viewing the photo before and after compression. But there is no other technology that can do this automatically (and adaptively) for millions of photos.
Post reply on HN