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

101–110 of 144 posts

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

#101

Post by notlisted »

notlisted wrote: post #99
nwh wrote: post #88

Earlier quoted context omitted.

> The original Diaz post and claims like yours are simply a load of crock. > you DID start out with a JPEG, right? I hope you like My Little Pony. > then upload them to IMGUR for re-post here I wouldn't try uploading JPEG images to Imgur, they get put through a compressor. Original — http://d.pr/GIWO+ Lossy — http://d.pr/XIUf+

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…

To add to my my point, check out these two real pictures, hope you like pink bags:

OriginalPony [1] - 451kB - https://dl.dropbox.com/u/139377/ThreePonies/ponyphoto2-origi...

JPEGMiniPony [2] - 151kB - https://dl.dropbox.com/u/139377/ThreePonies/ponyphoto2-jpegm...

Now tell me, where is the banding?

(CC, source: http://www.flickr.com/photos/dreamcicle/3552305929/sizes/l/i... )

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

#102

Post by nwh »

notlisted wrote: post #99
nwh wrote: post #88

Earlier quoted context omitted.

> The original Diaz post and claims like yours are simply a load of crock. > you DID start out with a JPEG, right? I hope you like My Little Pony. > then upload them to IMGUR for re-post here I wouldn't try uploading JPEG images to Imgur, they get put through a compressor. Original — http://d.pr/GIWO+ Lossy — http://d.pr/XIUf+

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

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.

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

#103

Post by nwh »

notlisted wrote: post #101
notlisted wrote: post #99

Earlier quoted context omitted.

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…

To add to my my point, check out these two real pictures, hope you like pink bags: OriginalPony [1] - 451kB - https://dl.dropbox.com/u/139377/ThreePonies/ponyphoto2-origi... JPEGMiniPony [2] - 151kB - https://dl.dropbox.com/u/139377/ThreePonies/ponyphoto2-jpegm... Now tell me, where is the banding? (CC, source: http://www.flickr.com/photos/dreamcicle/3552305929/sizes/l/i... )

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.

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

#104

Post by YZF »

bjornsing wrote: post #49
YZF wrote: post #37

Earlier quoted context omitted.

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

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.

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

#105

Post by midvar »

wmf wrote: post #100
midvar wrote: post #79

It's good to see a response from Beamr staff. Perhaps rhetorical but.... How do you feel licensing an amazing open source tool, adding a few patches you feel needed for perceptual quality in crf encodes, and then calling it your own product? Even a "patent pending" product? You've done one small bit of coding, building upon the _years_ of work that open source devs have done. You present this minorly tweaked x264 as…

Apparently ICVT paid for x264: http://x264licensing.com/adopters In general, the market tends to solve the "you've done one small bit of coding" problem; if a proprietary product is only epsilon better than the open source version then people will only be willing to pay epsilon for it. Conversely, if people are willing to pay real money for that small bit of coding, then by definition it must be a valuable bit. (It's…

^ "you must provide your source code modifications back to x264 LLC"

Very nice find, I'm ridiculously happy that that provision is in there.

So then it may well be they have their own software that determines x264 settings as I outlined above.

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

#106

Post by wyck »

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…

> proven by industry experts.

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?

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

#107

Post by wyck »

This reminds me of the hey days or porn, remember when it was powering innovation? Anyway there were Snake Oil video's salesmen all over the place, wrapping windows media and real play encoders into 6 figure custom super amazing but actually nothing special systems.

And people did buy them.

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

#108

Post by notlisted »

nwh wrote: post #102
notlisted wrote: post #99

Earlier quoted context omitted.

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

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

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

#109

Post by DarkShikari »

midvar wrote: post #105
wmf wrote: post #100

Earlier quoted context omitted.

Apparently ICVT paid for x264: http://x264licensing.com/adopters In general, the market tends to solve the "you've done one small bit of coding" problem; if a proprietary product is only epsilon better than the open source version then people will only be willing to pay epsilon for it. Conversely, if people are willing to pay real money for that small bit of coding, then by definition it must be a valuable bit. (It's…

^ "you must provide your source code modifications back to x264 LLC" Very nice find, I'm ridiculously happy that that provision is in there. So then it may well be they have their own software that determines x264 settings as I outlined above.

I'm going to check with CoreCodec (the folks helping us administer x264 LLC) and see what's going on here. If they're abusing the terms of the license, we'll make sure things get fixed. If not, we'll publish all the changes they've made -- and honestly, I would be shocked if they've done anything significant besides change the program name.

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

#110

Post by beagle3 »

toddmatthews wrote: post #96
bjornsing wrote: post #74

Earlier quoted context omitted.

> What Diaz showed is that Beamr is offering nothing that actually improves either visual quality or bitrate Well too bad Beamr never made that claim (AFAIK). What Beamr does claim is that their software can automatically find settings (per frame) that will compress a certain video file to it's smallest size without affecting quality (too much - in some subjective measure). I'm not saying that Beamr is great. I have…

From Beamr's site "Beamr Video is capable of reducing the bitrate of H.264 video streams by up to 75% (4X), while preserving their visual quality." sounds like they are claiming to work wonders on your bitrate. I think Diaz just pointed out that these claims are dubious at best

> I think Diaz just pointed out that these claims are dubious at best

He did no such thing. He just pointed out that you can get the same benefits from using x264 directly.

Most people just take the h264 stream they got from their phone / camera / BluRay rip. These are horribly compressed. x264 can consistently improve those without degrading quality by 30% without much tweaking, and by 50-70% with some tweaking.

Apparently, Beamr saves you some tweaking. Diaz' claim is that the tweaking saved is ridiculously minimal and does not warrant all the hyperbole around beamr.

Post reply on HN