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