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

121–130 of 144 posts

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

#121

Post by maffydub »

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…

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.

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

#122

Post by tripzilch »

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…

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

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

#123

Post by tripzilch »

pudquick wrote: post #72

TL;D(id)R version: Beamr isn't claiming a superior encoder. They're claiming to provide a service for video compression that is similar to what the tools like optipng and jpegoptim do for images: recompression without (noticeable) loss. Their big claim to fame, however, is that they determine the "minimum" bitrate for your video to still look good. So, in theory, if I feed back in the compressed video they give me -…

> So, in theory, if I feed back in the compressed video they give me - Beamr should refuse to optimize it further because it should be as perfectly compressed as possible.

Nuh-uh, he claimed Beamr will reduce the bitrate of any video: http://news.ycombinator.com/item?id=5290308

You're giving them way too much benefit of the doubt, yes what you descibe above is what a sane video optimization algorithm along these lines would do, but that's specifically what we are all guessing (that would make sense) and not at all what Beamr has been claiming.

What about an arithmetic encoder on raw video that refuses to compress when it can't reduce file size (including headers) with the message "cannot optimize further without loss of quality". While I can't market it for 100x improved compression vs Blu-Ray, at least it does exactly what it says on the box!

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

#124

Post by raverbashing »

tripzilch wrote: post #123
pudquick wrote: post #72

TL;D(id)R version: Beamr isn't claiming a superior encoder. They're claiming to provide a service for video compression that is similar to what the tools like optipng and jpegoptim do for images: recompression without (noticeable) loss. Their big claim to fame, however, is that they determine the "minimum" bitrate for your video to still look good. So, in theory, if I feed back in the compressed video they give me -…

> So, in theory, if I feed back in the compressed video they give me - Beamr should refuse to optimize it further because it should be as perfectly compressed as possible. Nuh-uh, he claimed Beamr will reduce the bitrate of any video: http://news.ycombinator.com/item?id=5290308 You're giving them way too much benefit of the doubt, yes what you descibe above is what a sane video optimization algorithm along these line…

It will most likely reduce the quality of the video

I think someone did this experiment, of reencoding a jpg multiple times to see what happens, and of course, after some iterations you only get a blob

Because it's lossy compression, you can only do this once or twice without noticeable loss

Now, of course, they're probably assuming you took the video, compressed it one time and then submitted it to them

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

#125

Post by creamyhorror »

tripzilch wrote: post #122
drorgill wrote: post #60

Earlier quoted context omitted.

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…

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

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.

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

#126

Post by tripzilch »

raverbashing wrote: post #124
tripzilch wrote: post #123

Earlier quoted context omitted.

> So, in theory, if I feed back in the compressed video they give me - Beamr should refuse to optimize it further because it should be as perfectly compressed as possible. Nuh-uh, he claimed Beamr will reduce the bitrate of any video: http://news.ycombinator.com/item?id=5290308 You're giving them way too much benefit of the doubt, yes what you descibe above is what a sane video optimization algorithm along these line…

It will most likely reduce the quality of the video I think someone did this experiment, of reencoding a jpg multiple times to see what happens, and of course, after some iterations you only get a blob Because it's lossy compression, you can only do this once or twice without noticeable loss Now, of course, they're probably assuming you took the video, compressed it one time and then submitted it to them

> It will most likely reduce the quality of the video

Of course. Anything else would be a mathematical impossibility.

> I think someone did this experiment, of reencoding a jpg multiple times to see what happens, and of course, after some iterations you only get a blob

> Because it's lossy compression, you can only do this once or twice without noticeable loss

This is besides the point though and makes things a bit more confusing :)

Because of the Pigeonhole Principle you must chose, .. actually there is no choice, in order to lose bits (file size), you have to dump some bits (information).

However, what you describe is generation-loss, and there is nothing about lossy compression that forces you to have generation-loss, it just depends on the codec. JPG does it, most audio and video codecs also do it. But using 2x2 sampling blocks is also lossy compression (x4 compression!!), but it only applies the first time: using 2x2 sampling blocks on something that's already pixelated won't change it anymore, and of course neither will it compress it any further.

> Now, of course, they're probably assuming you took the video, compressed it one time and then submitted it to them

"Took the video", from where though? This is important, see the other post up in the thread about use-cases. Most video an end-user can get their hands on is already compressed by the time they get it.

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

#127

Post by raverbashing »

tripzilch wrote: post #126
raverbashing wrote: post #124

Earlier quoted context omitted.

It will most likely reduce the quality of the video I think someone did this experiment, of reencoding a jpg multiple times to see what happens, and of course, after some iterations you only get a blob Because it's lossy compression, you can only do this once or twice without noticeable loss Now, of course, they're probably assuming you took the video, compressed it one time and then submitted it to them

> It will most likely reduce the quality of the video Of course. Anything else would be a mathematical impossibility. > I think someone did this experiment, of reencoding a jpg multiple times to see what happens, and of course, after some iterations you only get a blob > Because it's lossy compression, you can only do this once or twice without noticeable loss This is besides the point though and makes things a bit m…

> "Took the video", from where though?

I'm assuming that, if you're streaming the video, you either have the original or got a copy from the content producer that's minimally compressed (like DV)

I don't think there's "raw video" today except for the most specific cases. (even REDCODE is lossy for video)

But I don't expect their customers to submit them a video downloaded from youtube.

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

#128

Post by Kesty »

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…

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.

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

#129

Post by fnordfnordfnord »

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…

>But there is no other technology that can do this automatically (and adaptively) for millions of photos.

Excluding of course, the for loop or the while loop; particularly when used in a shell/python/perl/etc script. Matlab is also particularly well suited for this. Then there are visual macro thingamajigs. iMacros for browser based repetitive tasks, which could then be used with an online image editor. Irfanview, I believe has batch image processing, as do many other popular photo/image editors. And last, but not least, Imagej.

You may have added feedback to the loop where many would have had none, but feedback is not a new or novel concept. The only thing I can see that is possibly non-trivial is your method for assessing quality of the output. Given the many high-quality image-processing libraries, and well-documented techniques available, and the subjective nature of assessing "quality" with respect to how an image "looks", I doubt there is anything original there. You've enhanced the workflow for casual users, the uninformed, and those who prefer to spend their time on something else. That arguably has value. While it seems a bit of a stretch to call it "technology" to this audience but, that is what the word means.

IMO, you'd receive a "warmer" welcome from the more technically-minded folks here if you'd dispense with the marketing hype (definitely stop making impossible claims), and show some real evidence of just how much "better" your output is over some reasonable defaults, including cases where your system fails to meet your stated goals (even a random quality assessment will get it right sometimes). Nobody is ever going to believe that any system as you've described works for every case, every time (simply impossible). In other words, you aren't going to sell any ice to these Eskimos.

edit: accidentally posted comment before I was finished blathering.

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

#130

Post by hakaaaaak »

jlgreco wrote: post #73
hakaaaaak wrote: post #54

It's too bad that more SaaS apps aren't held to the same level of scrutiny. Most stuff on HN is snakeoil.

Are there any particular examples that come to mind?

Whenever you go to a site and it promises something, you have to give it your email address to possibly get access to a beta later, and then it either never appears, doesn't live up to the hype, or pivots and becomes something you're not interested in. Or, how about something that promises it will be around forever, and doesn't. I won't name names.
Post reply on HN