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.
> 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.
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!
> It will most likely reduce the quality of the video
Of course. Anything else would be a mathematical impossibility.
> 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
This is besides the point though and makes things a bit more confusing :)
Because of the Pigeonhole Principle you must chose, .. actually there is no choice, in order to lose bits (file size), you have to dump some bits (information).
However, what you describe is generation-loss, and there is nothing about lossy compression that forces you to have generation-loss, it just depends on the codec. JPG does it, most audio and video codecs also do it. But using 2x2 sampling blocks is also lossy compression (x4 compression!!), but it only applies the first time: using 2x2 sampling blocks on something that's already pixelated won't change it anymore, and of course neither will it compress it any further.
> Now, of course, they're probably assuming you took the video, compressed it one time and then submitted it to them
"Took the video", from where though? This is important, see the other post up in the thread about use-cases. Most video an end-user can get their hands on is already compressed by the time they get it.
I'm assuming that, if you're streaming the video, you either have the original or got a copy from the content producer that's minimally compressed (like DV)
I don't think there's "raw video" today except for the most specific cases. (even REDCODE is lossy for video)
But I don't expect their customers to submit them a video downloaded from youtube.
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.
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.
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.
>I just provided a means of testing this aspect as well.
I agree that it would be an interesting test, but seeing that they're not actually offering a real cloud encoding service for users yet, the only people who could run tests against their product are people working at Beamr Video. Which obviously wouldn't make for very reliable test data.
(By the way, it's "CRF", not "CFR". "CFR" generally refers to "constant framerate" in the context of videos and video encoding, whereas x264's "CRF" stands for "constant rate factor" - but as said, people generally just call the CRF mode "constant quality mode".)
> re-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.
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.
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.