Live data from Hacker News

Don't Buy the Snake Oil of Beamr Video

gist.github.com

91–100 of 144 posts

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

#91
post #44
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?

You can minify code ensuring absolute correctness or make substitutions that are almost always correct.

For example, there are some cases where you could replace tests like `x===y` with `x==y` but this may not work in all cases. If you accept imperfect translation, then this is a valid technique, but it should be clear that the translation isn't perfect.

The reason why my question is different is because I'm asking about the constraints on the format. For example, is run-length encoding (RLE) acceptable? That wouldn't be acceptable for a .BMP bitmap

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

#92
post #81

Earlier quoted context omitted.

>Beamr isn't claiming a superior encoder. Their sure make it sound like it in their marketing material. Hell, they've even gotten articles written about them that start like this[0]: New technology from video encoding experts Beamr claims to be able to out-perform the new H.265 format by merely encoding H.264 better. Their video optimisation apparently reduces the bitrate of video streams by up to four times, while r…

Just for clarification - I completely agree with the testing that you have done here. I think you've proven that it's easier to get better results with CRF settings alone and that they're likely using x264 as the encoder behind the scenes. I should have prefaced my commentary and noted that it was a response to the ("clarified") claims in this thread, from Beamr, about what the Beamr service actually provides. In res…

>I just provided a means of testing this aspect as well.

I agree that it would be an interesting test, but seeing that they're not actually offering a real cloud encoding service for users yet, the only people who could run tests against their product are people working at Beamr Video. Which obviously wouldn't make for very reliable test data.

(By the way, it's "CRF", not "CFR". "CFR" generally refers to "constant framerate" in the context of videos and video encoding, whereas x264's "CRF" stands for "constant rate factor" - but as said, people generally just call the CRF mode "constant quality mode".)

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

#93
post #53

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

"I hate choosing compression settings" -- but you don't have to. Diaz has shown in this thread, that a free, open-source encoder can automatically choose settings for you which work better than Beamr's.

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

#94
post #92

Earlier quoted context omitted.

Just for clarification - I completely agree with the testing that you have done here. I think you've proven that it's easier to get better results with CRF settings alone and that they're likely using x264 as the encoder behind the scenes. I should have prefaced my commentary and noted that it was a response to the ("clarified") claims in this thread, from Beamr, about what the Beamr service actually provides. In res…

>I just provided a means of testing this aspect as well. I agree that it would be an interesting test, but seeing that they're not actually offering a real cloud encoding service for users yet, the only people who could run tests against their product are people working at Beamr Video. Which obviously wouldn't make for very reliable test data. (By the way, it's "CRF", not "CFR". "CFR" generally refers to "constant fr…

Thank you, fixed

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

#95
post #81

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

>Beamr isn't claiming a superior encoder. Their sure make it sound like it in their marketing material. Hell, they've even gotten articles written about them that start like this[0]: New technology from video encoding experts Beamr claims to be able to out-perform the new H.265 format by merely encoding H.264 better. Their video optimisation apparently reduces the bitrate of video streams by up to four times, while r…

Not trying to pile on, but Daiz's comment...

> re-encoding with Beamr could potentially make the streaming experience worse due to the fact that Beamr does not seem to set any VBV options[2] for their encodes

...is crucial if you're sharing video online. As a video delivery network (VDN), we run into badly encoded streams all the time. Clients can play the files locally, but after uploading to us the files don't stream or stream badly when trying to play online. Daiz's comment mentions one of the more subtle causes of such problems.

If you are streaming video to end users, which is what most people here on HN are doing with video, keep in mind that users' bandwidths are generally constant. Someone with a 756kbps DSL line cannot magically download at 3 mbps during the explosive parts of your video.

Most encoding guides you find around with x264 settings are for your own content on your own computer, and neglect the options necessary to ensure your video doesn't use up bits faster than your pipe can refill them. Most pro encoding tools miss these settings as well.

In the old days (Windows Media) for the best streaming video quality, you could use constant bit rate (CBR) but define a long window for the CBR measurement, say, 15 seconds. That would give you variable bitrate from second to second (say, a scene change), but limit your bitrate to the CBR over any given 15 second window.

x264 has options that allow the same thing, essentially defining how many bits you need to have in reserve to encode complex parts from, and what constant rate can refill the reserve. For a good streaming experience, this is more important than "frame by frame quality". Casual users might not notice a 10% difference in picture quality, but everyone notices if the stream pauses.

Here's an explanation or two:

http://codesequoia.wordpress.com/2010/04/19/what-are-cbr-vbv...

http://aviadr1.blogspot.com/2010/12/vbv-for-dummies.html

See link [2] in parent comment for the VBV settings you need.

All this said, I can see a use case for Beamr for utterly non technical users that want to archive their own video from Bluray or DVD or broadcast quality digital sources. Looks like this tool can approximate a reasonable guess at perceptual quality with "zero config". As others have said here, I personally prefer to do that by having a multicore encoder and let x264 apply as much look ahead and calculation as it can to take advantage of motion calculation and perceptual quality. Play around with those settings till you hit an encoding time that you're happy with, then with those set, find the CRF that looks good to you, and you're pretty much set from then on. Just encode future videos to that CRF and you'll be happy with the quality -- x264 will pick unique bit rates tuned for each video that give you the PQ you want.

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

#96

Earlier quoted context omitted.

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.

> 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

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

#98
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?

If you compare #2 and #3 and they are similar quality, it would prove your product is essentially not doing better than x264.

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

#99
post #88

Earlier quoted context omitted.

When JPEGMini came out I thought it was a hoax. I've been working with various image compression tools since 1992, and was highly skeptical about their claims, but after encoding a ton of edge cases, I was convinced it was the real deal. Have since encoded thousands of images for various clients with JPEGMini, and have never noticed ANY difference or persistent issues. Most of all, it saves me from having to experime…

> 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 [2]

[1] https://dl.dropbox.com/u/139377/ThreePonies/00-ORIGINAL.jpg (1.8MB)

[2] https://dl.dropbox.com/u/139377/ThreePonies/01-YOUR-LOSSY.jp... (121kB)

[3] https://dl.dropbox.com/u/139377/ThreePonies/02-MY-LOSSY%28JP... (410kB)

Your lossy sample is brighter, has major artifacts around pointy hair bits, the sickle, etc. and in zoomed in mode, which is not how you should compare these things, there's a distinct lack of detail.

If you were to repeat the same comparison with a realistic photo, the differences between the original and the jpegmini version, there are some, but you have to look hard, would be even less noticeable.

Please note: JPEGMini does not allow me to set any parameters at all.

In short: a single drag/drop on my part reduced a file from 1.8MB to 410kB and differences are extremely minimal. Another win for jpegmini.

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

#100
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 even possible to make money by selling unmodified open source with some slick marketing, which really tends to annoy hackers because it implies that the marketing is worth more than the code...)

Also, "you must provide your source code modifications back to x264 LLC" http://x264licensing.com/faq

Post reply on HN