News for hackers. Stuff that matters.
Re:AV1 beats x264 and libvpx-vp9 in practical use case by ksec on Wednesday April 11, 2018 @01:02AM (#16808197)
Many continue to use this comparison.

H264 Reference Encoder wasn't even tuned for anything. Not even quality. Hence why we not only get much better speed in x264, but also higher quality.

And the Reference Encoder ( JM ) was only 250 times slower when it first came out. It truly was a pieces written to be correct rather then anything else. And there was some easy wins to get it 10x - 20x faster within a matter of weeks.

Now Av1 is nearly 10000x slower, that is if you manage to speed it up 100x it is still 100x slower. The codec right now was tuned for quality metrics. They were trying to hit PSNR, SSIM and even VRMF at 30% higher then VP9 at all cost. Which is not the same as JM.

I dont doubt they could speed it up. But by how much. Some even mention it is only usable by companies with Scale, well this is so far from truth. You dont gain much economy of scale once you past certain level of compute. What cost $1M dollar to encode at facebook now cost $1B or $10B as it stands. People seems to have a real lack of sense in scale of how much 1000x is. Or even 10K x. Your compute cost is going to be dictated by CPU manufacturer or silicon prices. And that 30% of bitrate reduction is not going to save you money from the insane increase of compute. Especially if you are Netflix with Appliance sitting at ISP's DC.

Not long ago I asked how are we going to get the encoding speed to some sane's time. Like 10x of x264 High Quality. Turns out it will very likely have to disable certain tools set now being used, which means a reduction of quality. But I believe it will still be better then x265 at the end. The tools available for AV1 is quite massive.

Right now we have xvc which is looking more like an H.266 encoder, and offer 30% improvement over AV1 if you want to believe PSNR and SSIM. But it is even slower then AV1.

Re:AV1 beats x264 and libvpx-vp9 in practical use case by p0nce on Wednesday April 11, 2018 @08:48AM (#16810547)
It seems AV1 allows to rotate reference blocks in inter prediction. I wonder what an algorithm that would search for a prediction MV would look like (not even counting bidir).

Even without rotation, MV search can get sophisticated and not exactly intuitive in a typical encoder. And with HEVC having "merge" that win that much bits, it's not like there was so much bits left to earn with the predictor itself.

Re:AV1 beats x264 and libvpx-vp9 in practical use case by ec109685 on Wednesday April 11, 2018 @01:10AM (#16808231)
To get to “sane time”, you break up the video and have more than one encoder running at a time: http://cseweb.ucsd.edu/~gmporter/papers/nsdi17-excamera.pdf
Re:AV1 beats x264 and libvpx-vp9 in practical use case by akvadrako on Wednesday April 11, 2018 @08:51AM (#16810569)
That's only going to give you a 4x improvement on typical devices and is something HEVC can do too.
Re:AV1 beats x264 and libvpx-vp9 in practical use case by ec109685 on Friday April 13, 2018 @12:01AM (#16827049)
Why only 4x? Video can be subdivided into more pieces.
Re:AV1 beats x264 and libvpx-vp9 in practical use case by bwbw223 on Saturday April 14, 2018 @12:11AM (#16835815)
Because most devices are quad-core. After a certain point context-switches create a diminishing return.
Re:AV1 beats x264 and libvpx-vp9 in practical use case by ec109685 on Saturday April 14, 2018 @10:56AM (#16837561)
Distribute across multiple machines.