3 ms·

We're developing xvp8 too, which we will also license. But unlike h.264 (AFAIK), VP8 has a BSD-licensed encoder available. Even if you beat libvpx in speed an

We're developing xvp8 too, which we will also license. But unlike h.264 (AFAIK), VP8 has a BSD-licensed encoder available. Even if you beat libvpx in speed and/or quality, libvpx will probably be "good enough" for most people. I'm guessing your demand for xvp8 will be much lower, and that you won't be able to price it as high as x.264. Is filing for a patent that covers existing open source software suddenly "not bad"? That's not the accusation I cited. The accusation I cited was that they copied from h.264, which you later admitted might not be true. There are a few possibilities here: 5. They are using code that they have not yet publicly released. 6. They made an honest mistake. 7. They measure PSNR using a different tool, and the two tools have different measurements for some reason (I don't have enough expertise in this space to know if this is actually a possibility or not). There are lots of possibilities. That's why you should really get an explanation from them before you publicly call them liars.

DarkShikari 16y ago
Even if you beat libvpx in speed and/or quality, libvpx will probably be "good enough" for most people. Unlikely: a large percentage of the applications that license x264 are live-streaming apps of some sort (videoconferencing, broadcast, app streaming, etc) -- being slow is a deal-killer for these. But you are right that this does change things somewhat -- though I actually haven't thought too much about that. 5. They are using code that they have not yet publicly released. Likely false. According to my info so far, the tests were done using a daily autobuild from their own system (which, IIRC, builds from git). 7. They measure PSNR using a different tool, and the two tools have different measurements for some reason (I don't have enough expertise in this space to know if this is actually a possibility or not). There are two ways to measure PSNR: Overall/Global and Average. Both showed similar results here though, so that's unlikely to be the issues. 6. They made an honest mistake. Could be. If so, I hope they fix it. I toned down the original post, and in light of your comments, I've delayed making a blog post on the topic for at least a few days until I know exactly what's going on. Thanks for the advice.
- DarkShikari 16y ago
  And the end results. The numbers in the paper are correct. however: 1) The settings in the paper were lies. This will supposedly be fixed. This was supposedly unintentional. 2) The clips are indeed cherry-picked (libvpx loses by ~1db on foreman with the same settings). This may or may be fixed. This was intentional. All other criticisms of the paper are valid.
  - haberman 16y ago
    Cool, thanks for getting all the facts. Though I'm not sure "lies" is the right word for something that was supposedly unintentional.

DarkShikari 16y ago

Even if you beat libvpx in speed and/or quality, libvpx will probably be "good enough" for most people. Unlikely: a large percentage of the applications that license x264 are live-streaming apps of some sort (videoconferencing, broadcast, app streaming, etc) -- being slow is a deal-killer for these. But you are right that this does change things somewhat -- though I actually haven't thought too much about that. 5. They are using code that they have not yet publicly released. Likely false. According to my info so far, the tests were done using a daily autobuild from their own system (which, IIRC, builds from git). 7. They measure PSNR using a different tool, and the two tools have different measurements for some reason (I don't have enough expertise in this space to know if this is actually a possibility or not). There are two ways to measure PSNR: Overall/Global and Average. Both showed similar results here though, so that's unlikely to be the issues. 6. They made an honest mistake. Could be. If so, I hope they fix it. I toned down the original post, and in light of your comments, I've delayed making a blog post on the topic for at least a few days until I know exactly what's going on. Thanks for the advice.

DarkShikari 16y ago
And the end results. The numbers in the paper are correct. however: 1) The settings in the paper were lies. This will supposedly be fixed. This was supposedly unintentional. 2) The clips are indeed cherry-picked (libvpx loses by ~1db on foreman with the same settings). This may or may be fixed. This was intentional. All other criticisms of the paper are valid.
- haberman 16y ago
  Cool, thanks for getting all the facts. Though I'm not sure "lies" is the right word for something that was supposedly unintentional.