Hacker News Reader

Comment by drorgill | Hacker News Reader

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.

View on HN

You could compress something with Beamr first, see what bitrate it spit out, then compress with standard encoder at the same bitrate. This isn't perfect since it's clearly favoring Beamr, but it would be somewhat useful.

How would this be "favoring Beamr"? I'd see it as piggybacking on a potentially useful Beamr innovation. Someone slightly more fanatic about IPR might even call it "theft".

As I understand it, the whole point of Beamr is that you don't have to manually tune the parameters for each video file.

It took me a few reads to see what you meant. I had taken Beamr to be about optimizing things like which what size blocks to use, how often to put i frames, and so on, which means better perceived quality at some bitrate. If it's always using the same settings and the only smartness is about what framerate to pick, then you would be correct.

Ok,

1) Compress the original with x264, target around 2mbit

2) Compress the result of #1 with your algorithm.

3) Compress the original with x264, target the bitrate of the result of #2

Compare #2 and #3

Even if you compare #2 and #3 and they are similar quality, what would that prove? You could do #3 for a specific file after Beamr Video has processed it, but how would you know the right bitrate for #3 without applying Bearm Video in #2?

I'm not on one side or the other here, but...

What would prove your claims?

Independent person from the industry here following this (as I am sure there are many more onlookers to this thread).

drorgill i think now is the time to provide some hard empirical evidence on your part, given the initial claims and a sample test done here it is my feeling that it should be relatively trivial to provide a counter example. cheers.

He could start by actually displaying an understanding of how video compression works, maybe.

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

Reply on news.ycombinator.com