Don't Buy the Snake Oil of Beamr Video

https://gist.github.com/Daiz-/5043109

by Daiz • 13 years ago

245 137 13 years ago

gist.github.com

metajack• 13 years ago

At least it is not as bad as Pixelon:

http://web.archive.org/web/20000711031951/http://www.thestan...

wmf3• 13 years ago

ICVT actually developed some interesting algorithms, but it's a shame they're letting marketing hyperbole overshadow it. Another case where technical innovation doesn't sell, I guess.

Daiz7• 13 years ago

Even if they had actually developed some "interesting algorithms", they sure don't seem to be using them, at least not in the actual video encoding process. There's really no other explanation for the fact that you can end up with practically identical video to Beamr's examples when using largely identical settings and bitrate with vanilla x264.

LocalPCGuy• 13 years ago

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.

haven• 13 years ago

The folks behind Beamr H.264 also have a 'patent pending', proprietary JPEG image "recompression technology": http://www.jpegmini.com/

I'm curious what an analysis of one of their JPEG's would show?

dangrossman• 13 years ago

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.

drorgill8• 13 years ago

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

wmf3• 13 years ago

JPEGmini operates on a similar principle to Beamr. The JPEGs coming out of your camera are compressed with a very high (wasteful) quantizer setting, so JPEGmini analyzes the image and recompresses with a much lower but visually identical quantizer setting.

mistercow5• 13 years ago

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 their encoded resolution.

In other words, the JPEGmini version is nothing special. If you save a JPEG at 85% quality and look at 1/4 scale, it will look exactly the same as a JPEG saved at 99% quality at 1/4 scale. And it will look just as good as if you pass it through Beamr's software.

bjornsing8• 13 years ago

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.

alpb• 13 years ago

I'm not a native speaker and thus not good at phrases. Can anybody explain the "snake oil" please?

ars• 13 years ago

http://en.wikipedia.org/wiki/Snake_oil

Basically a fake remedy that actually does nothing.

WillyF• 13 years ago

http://en.wikipedia.org/wiki/Snake_oil

lem72• 13 years ago

Snake oil is an expression that originally referred to fraudulent health products or unproven medicine but has come to refer to any product with questionable or unverifiable quality or benefit. By extension, a snake oil salesman is someone who knowingly sells fraudulent goods or who is himself or herself a fraud, quack, charlatan, and the like.

rdl2• 13 years ago

The irony is that the original "snake oils" actually were effective, just mislabeled (contained no actual snakes).

"Snake oil" as used today in tech is the opposite -- accurately labeled, but ineffective.

wahsd• 13 years ago

Which pretty much describes about 90% of the American economy.

e40• 13 years ago

I'm surprised you didn't think of google. The first hit explains it quite well.

stevewilhelm• 13 years ago

http://lmgtfy.com/?q=snake+oil

alan_cx• 13 years ago

You have now the official definition of snake oil, but in my experience what it often means is a knee jerk reaction against something that fall out of common acceptance, and then too often becomes mere insult.

Witness here how certain posters seem determined to trash the product. No matter what the defenders say, they simply must come back with something, and they will keep going until the defenders simply give up. Notice each attempt subtly shifting the goal posts each time the defending argument is put.

Do I want to post examples? Absolutely no. All that will do is end up the same way. No matter what I say, there will be endless comebacks until people get annoyed with the whole thing ending up in a similar cycle. I'll leave it as one of those things a read can decide for themselves.

So be careful, the use of the term snake oil can tell you as much about the person using the term as it can the target.

niggler2• 13 years ago

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?

Daiz7• 13 years ago

A video standard essentially defines a set of methods for compressing video - it's up to the encoding applications to decide how to apply those methods and where. Basically, the smarter decisions the encoder can make, the higher quality results it will produce. This is why all H.264 encoders are not created equal.

As an example of "techniques" that can be applied to compressing videos, one of the reasons why x264 is considered the best H.264 encoder out there is due to its advanced psychovisual optimizations - these are basically methods that will increase the perceived visual quality for human viewers, but decreases the quality in the eyes of metrics like PSNR and SSIM.

calinet6• 13 years ago

The techniques that could be applied in the domain of standard H.264 video are called "H.264."

Hello71• 13 years ago

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

niggler2• 13 years ago

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

Xcelerate• 13 years ago

I've found that most claims of extreme video or image compression don't hold up under scrutiny. There's just too much research that has to go into it and so many tradeoffs to consider.

However, I know of one program that does in fact meet its claims: DLI Image Compression (https://sites.google.com/site/dlimagecomp/)

It only compresses images, and it is extremely slow at it too. But apparently it's better than anything out there. Dark Shikari (x264 developer) says [1]:

> I’ve seen that one before; iirc, last I tested it, it was competitive with x264 and even beat it significantly at times. Given that it was adapted for insanely high compression times, of course, this is not very surprising. Still rather impressive.

[1] http://x264dev.multimedia.cx/archives/541

drorgill8• 13 years ago

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 been tested and proven by industry experts. You can find the reviews online, and I would be happy to send you the quotes we got from the industry experts as well. Thousands of users are using our free online photo optimization service at JPEGmini.com daily, and thousands more have purchased JPEGmini for Mac to optimize images locally, and they are all very happy with these tools.

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. Based on analysis of the image or video using a perceptual quality measure we have developed, we adaptively set the encoding parameters for each image or video. So the amount of compression for each image or video clip is different, and depends on the content and original quality of that image.

Comparing the quality of a clip encoded in Beamr Video with the quality of the same clip encoded at the same bitrate using another encoder is meaningless, since part of the uniqueness of Beamr Video is "knowing" what is the right bitrate (actually the lowest bitrate possible) for encoding each video such that it stays perceptually identical to the original clip. Beamr Video is the only technology that can adaptively reduce the bitrate of any clip to the minimum amount possible, while ensuring that quality of the output clip is perceptually identical to the quality of the input clip.

The same is true for our image technology: We reduce each JPEG file to the minimum file size possible without affecting its original quality. Of course, you can take a specific file and tune a regular JPEG encoder to reach the same size 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 take millions of photos and automatically adapt the size of each one to the minimum possible size while preserving quality.

The clips on our website are an initial demo of Beamr Video we are offering today, based on Blu-Ray sources. In a few weeks we will launch a cloud-based Beamr Video encoding service, where everyone will be able to process their own clips and reach their own conclusions. There are free trial versions of JPEGmini available for anyone to download and try. So again, I don't understand the basis of your "Snake Oil" claim. I would be happy to continue this discussion with you privately if you like, you can email me at dror@beamr.com.

rorrr3• 13 years ago

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.

drorgill8• 13 years ago

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 typically bitrate-driven.

YZF2• 13 years ago

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.

teraflop• 13 years ago

What you've described sounds a lot like x264's --crf option, which adaptively chooses a bitrate based on the input. How is Beamr different?

drorgill8• 13 years ago

The decision Beamr Video makes are "smarter" than x264's CRF mode, since they are based on a perceptual quality measure we have developed. This quality measure is similar to the one used in JPEGmini, our image optimization technology, and has been proven (in standard ITU BT.500 testing) to have higher correlation with subjective results than other quality measures such as SSIM.

chadnickbok• 13 years ago

Being generous - It sounds like beamr has a tool that can choose, for a given input video, which minimum crf option will provide a 'transparent' transcode.

kevinpet3• 13 years ago

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 probably be best to turn off the constant bitrate feature until it does support it well. If you make a feature available which is directly comparable to something else, you can't legitimately complain that people make the comparison.

drorgill8• 13 years ago

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.

doctorpangloss2• 13 years ago

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 you say at face value, your semantics, at minimum, are the snake oil. You make it sound like this perceptual compression technology doesn't exist, when it actually ships on by default in Handbrake.

I think what Daiz is talking about is snake oil of the technology, not semantic, variety.

So let's talk technology snake oil. Your special perceptual model might find situations where it could reduce the bitrate in a way that x264's model would disagree. But what about situations where x264's model is better? The end-user never gets to see where x264 makes a subjectively better image than your system does at a lower bitrate.

In other words, quality arbitrage: you can always claim to reduce bitrate by adjusting your model to be a bit more permissive than the competition. Knowing there is no rigorous numerical way to compare two perception-optimizing compressors, you can get away with "arbitrage" bitrate reductions.

Put another way, a lot of people are going to demand the wrong tests, because they don't understand the inherent contradiction of comparing two perception-optimizing compressors (like allegedly Beamr and x264's CRF model).

The way I'd know if your perceptual model were in fact better is if you could show me situations where it is wrong. In other words, convert your "lowest... possible" Beamr Perceptual Model parameter to a CRF parameter. You could do it subjectively. Find me situations where x264 chooses a lower bitrate than your model. At least if your model is falsifiable, it isn't snake oil.

Incidentally, Diaz did exactly this test. And your model calculate a worse bitrate than an equivalently-chosen CRF in all cases.

So your model isn't snake oil—it's just bad. Perhaps we would randomize the subjective differences, but 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.

bjornsing8• 13 years ago

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

nwh6• 13 years ago

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

james33• 13 years ago

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

Daiz7• 13 years ago

I'm going to answer you in detail, but it's going to take a while since I'm going to do some additional test encodes for it.

Also, you should note that I am only talking about your Beamr Video product in my post - I haven't used or tested your JPEG tools, so bringing them up here is largely irrelevant. Also, even if you have developed something effective for JPEG, does not mean you could develop something equally effective for a much more complex format like H.264.

Daiz7• 13 years ago

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 following:

>The decision Beamr Video makes are "smarter" than x264's CRF mode, since they are based on a perceptual quality measure we have developed.

Let's see how well that measures up to reality then, shall we? For this comparison, I used the same four clips as earlier, and ran each of them against the following command line:

  x264 --crf 18.5

That's it. Completely default settings, with the exception of setting the CRF to 18.5 for everything. This shall be our vanilla x264 equivalent of your "technology that can adaptively reduce the bitrate of any clip to the minimum amount possible, while ensuring that quality of the output clip is perceptually identical to the quality of the input clip". Since we're using the same value for everything, it involves as much choosing on the user end as your service would. Now then, let's see how your "smarter than CRF" technology actually fares against x264's CRF. Here are the results:

* Clip 1 - http://check2pic.ru/compare/26755/ (CRF 18.5 encode is ~11.7% smaller)

* Clip 2 - http://check2pic.ru/compare/26756/ (CRF 18.5 encode is ~4.4% smaller)

* Clip 3 - http://check2pic.ru/compare/26757/ (CRF 18.5 encode is ~17% smaller)

* Clip 4 - http://check2pic.ru/compare/26758/ (CRF 18.5 encode is ~19.5% smaller)

( The full videos are available here: http://blisswater.info/video/beamr/set3/ )

As we can see from the comparisons, x264, at defaults setting and CRF 18.5, can produce practically identical visual results (as in you wouldn't notice any quality difference in action), while producing smaller bitrates all over the board. Looks like your supposedly "smarter than CRF" technology for choosing bitrates isn't so smart after all, eh?

In short, even if you have developed some sort of quality-based bitrate-choosing technology of your own, in practice it still seems to lose consistently to x264's CRF mode (and since x264 actually allows you to control the CRF value, it's much more versatile than your "no quality settings at all, we know best" offering). As such, given the substantial claims about the capabilities of your technology, the Snake Oil verdict shall remain.

drorgill8• 13 years ago

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 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. And this is exactly what Beamr Video guarantees.

bjornsing8• 13 years ago

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.

optimiz3• 13 years ago

If you pay close attention to the lines around the woman's mouth in Clip 1, CRF 18.5 seems to have more defined lines and freckles (i.e. more signal in image processing parlance).

Judson• 13 years ago

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

wyck2• 13 years ago

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

abcd_f2• 13 years ago

Dror, if you re-read the review, it's quite obvious that the root of the backlash is not in what you claim, but rather in not giving an explicit credit to x264 team.

To everyone else - there's a very simple resolution to this situation. In fact, it will straighten itself up in, because if what Beamr did is trivial and working, I doubt x264 project will have any problem replicating it. If it's not working, then Beamr video service won't take off. And, lastly, if it's working and non-trivial, then their claims are true. As others said, the only way to confirm or deny their claims is to test against larger collection of clips and with real people. Well, duh, that the exact opportunity that their video service is going to provide. Let's just wait and see how it plays out.

Kesty• 13 years ago

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.

jcromartie• 13 years ago

A company called RayStream tried to pull something like this a while back. Maybe Beamr actually has a proprietary video compression algorithm...

http://news.ycombinator.com/item?id=3211630

antonb2011• 13 years ago

A lot of these companies, like Beamr, with extraordinarily technological claims tend to be preparations for stock pump and dump schemes. Usually their parent company will eventually be listed on:

http://stockpromoters.com/

Tim Sykes talks a lot about this stuff on his website.

chebert• 13 years ago

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. Why? Because people are usually too ignorant (not necessarily a bad thing) to know what is good for them.

Anyway. Props to you guys (drorgil) for making a good product and standing by it.

alexdowad3• 13 years ago

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

hakaaaaak2• 13 years ago

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

jlgreco• 13 years ago

Are there any particular examples that come to mind?

hakaaaaak2• 13 years ago

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.

photorized• 13 years ago

May I just say I love threads like this. VCs should read these discussions.

pudquick4• 13 years ago

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 should refuse to optimize it further because it should be as perfectly compressed as possible.

Someone please do this test.

Then, more importantly, redo the test but modify those option strings embedded in the video (as mentioned in OP) so that it can't cheat and detect a "perfect" video by noticing its own proprietary app name or a previously seen checksum of the file.

I'd love to see the results.

If it can't detect perfection, letting the user recompress video over and over again until it slides into digital blocks of moving mush, then there really is no difference between this service and using a CRF of 18.5 as mentioned elsewhere in this thread.

glomph• 13 years ago

In this post: http://news.ycombinator.com/item?id=5290308 he seems to claim both that beamr it can compress any file and that it is a downfall of x264 that it would continue to compress a file when reapplied.

Weird.

pudquick4• 13 years ago

Yeah, this response is partly why I suggested that testing protocol.

Daiz7• 13 years ago

>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 retaining their resolution, quality, and - most importantly - their industry-standard H.264 format. It works on all frame-sizes up to and including 4K

All the writing out there pretty much implies that thanks to Beamr Video's new technology, H.264 suddenly compresses up to four times better. Which is obviously not the case. No site is talking about "how most videos have 'too much' bitrate and how Beamr Video can select a much lower bitrate that is enough for the video to still look good", because that would be much more along the lines of what they're actually trying to do.

Anyway, there's something else that came to my mind from the discussion in this thread. Check out this section from a PR piece of theirs[1]:

>Online streaming services such as Netflix, Amazon and iTunes typically encode full HD (1080p) streams at 5-6 Megabits per second (Mbps). Utilizing Beamr Video optimization can reduce the required bitrate for full HD streaming to around 3-4 Mbps, enabling smoother playback, support for customers with lower broadband connectivity, and significant delivery cost savings to the streaming service providers.

Let's stop and think about this for a moment. As we have learned today:

* Beamr Video is not going to offer any kind of quality / filesize control in their service. Not even any kind of upper or lower bounds.

* Beamr Video is intended for re-encoding existing lossy video.

* Re-encoding from lossy to lossy is always going to introduce generation loss to some degree.

Combine these two facts, and you'll realize that for content providers like Netflix, Amazon and iTunes, this service is completely and utterly useless. When you're doing online streaming, bitrate matters. These services should all be encoding their video streams from very high quality sources (higher than what can be found on Blu-rays). If they ran these sources through Beamr, they'd only get a single video out of it, most likely at a bitrate far larger than what they're willing to stream (as demonstrated on Beamr's page, Blu-ray sources are enough to make for 9-30 Mbps streams on average, while, as the quoted section mentions, streaming services usually offer 1080p video around 5-6 Mbps). Thus, it rules Beamr out for this kind of straight encoding from high quality sources for online streaming use cases.

Now, they could encode all their streams like usuals, in different resolutions and bitrates, and then run these streams through Beamr, but does that make any damn sense? No, it does not. As I've proven, at the same bitrate, Beamr offers nothing over x264, so if any legitimate service wanted to offer their videos at smaller bitrates, they could just encode their videos straight to those bitrates from the high quality sources. Or, in case of something like Netflix that already encodes videos to several different bitrates, they could simply drop the higher-end streams. Not to mention that 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.

It's also the same situation with any digital video download services: If they wanted to offer lower-bitrate content, they could just encode the content directly to said lower bitrates. And since any legit digital video downloads are DRM'd up the bum (man, why must the legitimate digital video download market suck so much?), you, as an user, would not be able to make the video smaller through Beamr either.

So I guess the big question is: What actual use cases does this service have? Re-encoding Blu-ray sources isn't really that feasible for end users either, since what kind of user would have the patience to upload several dozens of gigabytes to Beamr with a regular consumer internet connection (unless they have Google Fiber or something)?

I guess ultimately this leaves us with regular users wanting to compress their videos taken with mobile phones or something, but if they for example want to put these videos up on YouTube, then there's really no reason for them to upload the full-sized original video to Beamr, wait for them to re-encode it, download it, and then upload that to YouTube, which is going to re-encode it again, when they could simply upload the original full-sized video straight to YouTube and have it be re-encoded only once.

[0] http://www.redsharknews.com/distribution/item/455-beamr-clai...

[1] http://www.prnewswire.com/news-releases/beamr-unveils-breakt...

[2] http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#...

pudquick4• 13 years ago

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 response to your tests, they claimed they were selling intelligent settings and "the lowest bitrate".

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

Terretta• 13 years ago

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.

tripzilch4• 13 years ago

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

raverbashing2• 13 years ago

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

midvar3• 13 years ago

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 a revolution in online video and allude that it's all your work. No reference to x264 at all on your site, which I guess is your right having paid the license fee. Still not impressive for anyone looking at your product, how it works, or wondering about the toolchain involved.

How about submitting some patches and pull requests to the tool that makes your product possible? Oh wait, that's right, you'll take that product that's 99% not your work and make as much money as you can.

Are you gonna approach all the big sites using x264 and try to convince them to change to beamr? No, I didn't think so. Snake Oil semantics for the uninformed.

As a wonderful T-Shirt I saw once states " My free software runs your company ".

UPDATE

Actually I've thought long and hard about this. They might not be so blameworthy or snake oily, they might just be using FAR too broad of explanations for what they've done. We've all jumped on them because it was almost like they've said they created a new encoder.

The possibility I didn't really think of is that they have coded their own proprietary solution that, as the media put it loosely in the original piece posted here : "According to the company, the compression method mimics the human eye and removes elements that would not have been processed by the human eye in the first place." [1]

Now I don't know if their solution; #1 Directly changes/effects the x264 source code, or #2 is something that runs before encoding and simply determines x264 settings to be used. Or even a mixture of both.

#1 If the changes are to x264 itself, I shake my head and my fist at them and again point to the years of open free development done in x264. (Most notable in this case it's amazing psy optimizations which do exactly what this company is claiming to have advanced ... it adjusts quality internally for the human eyes perception instead of metrics like PSNR and SSIM.) Submit a patch!

#2 If their software is completely separate and determines x264 settings via their proprietary methods, then what they've done is not so ridiculous.

They've done a confusing job explaining things, but I can imagine at least one scenario:

----- A user uploads a home video to their servers.

Their software scans it and takes careful note of scenes with high levels of movement, scenes with human shapes moving, scenes with human faces, scene's that match algorithms for water, grass, natural environs etc etc

They then parse those notes and either set x264's many advanced settings globally, or perhaps even change each scene's x264 settings accordingly. ---

Who knows.... It's been interesting following this nonetheless,

[1] http://nocamels.com/2013/02/beamr-can-cut-video-file-size-by...

wmf3• 13 years ago

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

midvar3• 13 years ago

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

creamyhorror2• 13 years ago

> Their software scans it and takes careful note of scenes with high levels of movement, scenes with human shapes moving, scenes with human faces, scene's that match algorithms for water, grass, natural environs etc etc

The funny thing is, this is the sort of thing that H.264 encoders intrinsically do. x264 has some fairly advanced algorithms in it to optimize for human visual perception (thanks DarkShikari, akupenguin, et al).

I assume these guys are basically determining settings to feed to x264. (They can't be modifying x264 itself since they'd then need to submit their source code changes upstream, if I've read the other replies right.)

If all they're doing is turning x264's settings knobs, they'll have to have studied the effects of those knobs in depth. I can hardly see how any analysis they're doing can be usefully turned into settings for x264. I find it a bit difficult to phrase my reasoning, but I'll try:

-----

- Trying to outdo x264's analysis at optimizing for perceptual quality while still depending on it is like trying to optimize a car engine from the driver's seat. It's not likely to happen.

- x264's settings are, generally speaking, macroscopic - they apply to the whole video segment. (You can apply different settings to different segments, but in the end your control is still limited by whatever knobs x264 offers.)

- If there were a way to optimize things better than x264 has, it almost certainly requires working directly within the encoder's analysis code itself rather than carrying out a pre-encoding analysis process and then fiddling with rough-control knobs. I simply doubt the complex interplay of settings within x264 lends itself to mere knob-turning. Many of the settings are mainly for making tradeoffs among the impossible trinity of encoding speed vs output quality vs output bitrate, rather than to allow the encoder to improve the output perceptually (because that's x264's job).

- Even if they managed to build a pre-analysis model that figures out decent settings to feed into x264, it would break to some extent whenever x264's code/algos are changed. That doesn't seem like a stable base to build a business on.

- All the above reasoning is overkill, because the settings the Beamr encoder turned out look outright silly to me: setting b-frames to 0 is just shooting x264 in the foot (b-frames are central to bitrate savings through discarding unnecessary visual data). Plus it turns off mb-tree and psy in 3 out of 4 samples, which basically discards two of x264's more powerful adaptive bitrate-vs-quality features. (mb-tree detects motion and saves bits on and around moving objects; psy is various optimizations for psychological quality perception, e.g. grain level.) It's just plain regressive.

-----

More fundamentally, the claim that "a minimum bitrate for visually lossless encoding of a video can be found" is quite doubtful, because of the fuzziness of the claim and its assumptions. The trouble is, a pure marketing line like this is easy to sell to a non-technical crowd. And x264 is good enough that anyone re-encoding a crappy source with it will find good bitrate savings, even with dumb settings.

Anyone looking to encode video in the cloud should instead use a well-priced, well-tuned service that doesn't overstate its case. Daiz suggested Zencoder, so it's probably a good bet. People who just want to shrink videos should grab Handbrake or any other x264-using encoder package, and use one of the presets (or just stick to the defaults). The result will probably be better than this service, as things stand.

(Thanks for patrolling the video frontier, Daiz.)

xooyoozoo• 13 years ago

> If there were a way to optimize things better than x264 has, it almost certainly requires working directly within the encoder's analysis code itself rather than carrying out a pre-encoding analysis process and then fiddling with rough-control knobs. I simply doubt the complex interplay of settings within x264 lends itself to mere knob-turning.

You're treating x264 like some box of black magic.

As far as the perceptual tunings go, x264 already provides the three most important knobs (aq, psy-rd, psy-trellis) that, due to their nature, can't be a "one size fit all" deal. x264 makes no attempt to guess which of those settings would fit your source best and only offer a conservative Default and a series of tunings for marginally more fine-grained control.

A hypothetical, "better" approach would be to have an amazingly intelligent first pass be done to split the movies into scenes and calculate the perceptual weights for each scene. That way, in a movie like Kill Bill, the animated, fast-action, and talking-head scenes would all be perceptually optimized, as they all need vastly differently settings. Splitting the movies into zones also open up a whole plethora of options for fine-tuning quality. Again, you can always reach these options from the command line.

(Also, x264's psy-rd is hilariously unoptimized for high-stress bitrates. I'm not sure if the purported "service" being discussed in this thread can handle those bitrates, but it's an area needing massive tweaks. x264's main role seem to be high-quality archiving, however, so this is merely a tangent.)

> Even if they managed to build a pre-analysis model that figures out decent settings to feed into x264, it would break to some extent whenever x264's code/algos are changed. That doesn't seem like a stable base to build a business on.

One could just not update, or only update the required parts. I assume reading and modifying code is already a prerequisite here.

yarou• 13 years ago

It's highly ironic that Daiz is commenting on other encoders, when his encodes tend to be bloated. :)

wyck2• 13 years ago

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.

beagle32• 13 years ago

The important underlying issue that some people take for granted, and some are completely unaware of:

Most h264 encoders suck. If you take an h264 recording from your camcorder / phone / ip camera / blu ray rip, and push it through x264 (and no special configuration), you usually get 30% bit rate reduction with no loss of quality. With tweaking, you very often get 50%-75% bit rate reduction with no loss of quality, but you have to actually tweak. (e.g., I'm getting ~65% bit rate reduction on h264 streams coming out of Axis IP cameras by running through x264 with -tune slow ant no other change).

Beamr's claim to fame appears to be that they automate this tweaking. Diaz' claim seems to be that "--crf 18.5" is a tweak that can consistently deliver better bitrate reduction than Beamr.

My opinion: If you can use the x264 commandline, Beamer is probably overpriced for you. But if you're a professional photographer with no serious computer skills, Beamr might be useful for you. (Assuming they actually deliver something better than --crf 18.5 ; a claim of which I have no knowledge, but I will assume for the sake of argument)

rb2k_• 13 years ago

If anybody is interested to read up on the rate control algorithms that x264 provides (and what this seems to be mostly about):

http://git.videolan.org/?p=x264.git;a=blob_plain;f=doc/ratec...

There is a also an interesting thread related to CRF on the doom9 forums:

http://forum.doom9.org/showthread.php?t=116773

bconway• 13 years ago

For similar benchmark fallacies (and straight up scams) discussed previously, see "A web video company that is most likely a hoax" -

http://news.ycombinator.com/item?id=3211630

http://seekingalpha.com/article/316946-raystream-remains-und...

messel2• 13 years ago

No doubt. Still looking forward to wider acceptance of h265 which has real gains in quality/bit

Don't Buy the Snake Oil of Beamr Video

Related Stories