

Don't Buy the Snake Oil of Beamr Video - Daiz
https://gist.github.com/Daiz-/5043109

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

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

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

~~~
Daiz
>Did you test several parameters

Nope. I just picked a value and tested what I'll get with it. Also, it doesn't
matter where the number comes from. As long as I'm not changing it for
different videos, the bitrate selection is completely up to x264's CRF mode.
And what do you know, here it produced smaller results than your technology
while providing the same level of quality!

>Would you apply the same CRF parameter of 18.5 to any video file to reduce
its bitrate?

That's what I did for all the test videos here, and it produced better results
compared to your technology on all of them (basically identical quality,
smaller filesizes).

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

Constant lossy re-encoding is going to degrade video quality no matter what -
nothing is going to change that. Not your technology, not x264's CRF. Why are
you even bringing up something as silly as this?

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

I have just demonstrated that encoding with x264 --crf 18.5 is a more
effective solution than your technology on all your presented test cases. You
have given us absolutely nothing to actually "guarantee" your claims, which is
exactly why your product is Snake Oil.

~~~
abcd_f
> it produced better results compared

"better" = "smaller files"

But how did the visual quality compare between the original and two compressed
versions (yours and Beamr's)?

------
midvar
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...](http://nocamels.com/2013/02/beamr-can-cut-video-file-size-by-half-
without-losing-quality/)

~~~
wmf
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>

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

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

~~~
midvar
^ The man himself. My mind is now at rest, and I look forward to your report.

I too would be rather surprised if they changed anything but the program name.

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

~~~
Daiz
>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...](http://www.redsharknews.com/distribution/item/455-beamr-claims-up-
to-75-reduction-in-h-264-bitrates-and-works-with-4k)

[1] [http://www.prnewswire.com/news-releases/beamr-unveils-
breakt...](http://www.prnewswire.com/news-releases/beamr-unveils-breakthrough-
video-delivery-technology-with-unprecedented-75-percent-bitrate-
reduction-190832551.html)

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

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

~~~
Daiz
>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".)

~~~
pudquick
Thank you, fixed

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

------
metajack
At least it is not as bad as Pixelon:

[http://web.archive.org/web/20000711031951/http://www.thestan...](http://web.archive.org/web/20000711031951/http://www.thestandard.com/article/display/0,1151,16368,00.html)

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

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

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

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

~~~
niggler
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

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

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

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

~~~
mistercow
I see now that this is what they purport to do. However I still maintain that
the presentation is dishonest. Showing a comparison at 25% scale gives the
impression that the tool is better at choosing "nearly lossless" setting than
it really is. Look at the dog image, which on their demo appears to be
identical to the original.

Now look at it at 100% scale: <http://imgur.com/z12mHnd> . Block artifacts
galore. Now sure, it may still do a better job than just choosing a constant
quality setting and applying it across the board. But the demo doesn't show us
that. It doesn't even make the right _kind_ of comparison.

What we need is a comparison of choosing a single quality level, and using
JPEGmini. To be useful, here's the kind of demo we'd need to see.

On the right side: five JPEGs saved with JPEGmini, having a total file size of
X, shown at 100% resolution.

On the left side: five JPEGs saved with a constant quality setting, chosen so
that the total file size is X, also shown at 100% resolution.

Then we'd honestly know whether the program is worth using.

My guess? Probably not. The train station image, for example, is so grainy
that you can compress it to damn near 600KB (50% in GIMP) before the artifacts
are really noticeable (and well beyond that if you scale it down to 25%
afterward). So did JPEGmini's visual model detect this and cut the bitrate
down accordingly? No, it decided that the image should be saved at the
equivalent of 83%, making the file more than twice as large as necessary. And
this is on an image that was presumably handpicked as a shining example of how
well the product works.

My guess is that if you just chose around a 75% quality setting and compressed
all of your JPEGs that way, you'd do just as well as JPEGmini.

~~~
bjornsing
I agree 100% on the proposed comparison. In fact I proposed the same for a
fair evaluation of Beamr video above. :)

For the rest, I have no idea. I've never used anything Beamr.

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

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

~~~
bjornsing
Yea, but what Daiz proves in the OP is that he personally can do a better job
than this so-called "algorithm". I hear his next project will be proving the
worthlessness of spell checkers by simply beating them, at spelling. That
paper clip thing in Word is such Snake Oil! ;)

For the record I have nothing to do with this Beamr, but I do feel sorry for
the those guys. The marketing speak on their website may be a little
hyperbole, but there's nothing fraudulent there that I can see. I don't think
they deserve this treatment.

UPDATE: LocalPCGuy, sorry for posting this as a reply to your comment. You
obviously get it.

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

~~~
bjornsing
> _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 no idea, I've never used it. But
what I can say for sure is that Daiz has not made a fair evaluation of the
technology in the OP.

~~~
toddmatthews
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

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

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

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

------
rb2k_
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...](http://git.videolan.org/?p=x264.git;a=blob_plain;f=doc/ratecontrol.txt;hb=HEAD)

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

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

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

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

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

~~~
SwellJoe
"were effective" for what purpose? And do you have a source for that?

~~~
rdl
[http://www.scientificamerican.com/article.cfm?id=snake-
oil-s...](http://www.scientificamerican.com/article.cfm?id=snake-oil-salesmen-
knew-something)

real Chinese snake oil was essentially some kind of omega-3 rich thing for
topical application.

And, from the wikipedia: <http://en.wikipedia.org/wiki/Snake_oil>

"snake oil" as sold in the US was essentially capsaicin, which is used today,
both as a topical treatment and others, for a variety of muscle/bone/tissue
ailments. <http://en.wikipedia.org/wiki/Capsaicin#Medical>

Whereas snake oil in cryptography tends to be worse. In practice even snake
oil algorithms are probably enough protection for short-term, limited use (no
one is going to devote real cryptanalysis resources to high school notes), but
it can encourage people to have a false sense of security and do things they
wouldn't otherwise, or it ends up getting used for purposes not originally
intended.

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

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

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

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

~~~
jlgreco
Are there any particular examples that come to mind?

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

------
bconway
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...](http://seekingalpha.com/article/316946-raystream-remains-under-
scrutiny-even-fails-to-disclose-loss-of-one-alleged-customer)

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

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

