4 ms·

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

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

raverbashing 14y 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
- tripzilch 14y ago
  > 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.
  - raverbashing 14y ago
    > "Took the video", from where though? 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.

raverbashing 14y 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

tripzilch 14y ago
> 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.
- raverbashing 14y ago
  > "Took the video", from where though? 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.