"Our testing shows AV1 surpasses its stated goal of 30% better compression than VP9, and achieves gains of 50.3%, 46.2% and 34.0%, compared to x264 main profile, x264 high profile and libvpx-vp9, respectively.
"However, AV1 saw increases in encoding computational complexity compared with x264 main, x264 high and libvpx-vp9 for ABR mode. Encoding run time was 9226.4x, 8139.2x and 667.1x greater, respectively…"
'Encoding run time was 9226.4x, 8139.2x and 667.1x greater, respectively…'
The codec is good, but the encoder has a long way to go. This places it squarely in the realm of only worth it right now if you're serving the same video millions of times (someone graph this?).
It's a bit hyperbolic to claim that this is a 'practical use case', but maybe at Facebook/Netflix/YouTube's scale, it is. But it will be exciting to watch this space.
> the main focus of current AV1 development is on speed optimization to make it practical for use in production systems
Remember: first make it work, then make it right, then make it fast. Seems they're only starting the 3rd step now.
I haven't tried AV1 yet, but the only way I was able to encode with x265 in a reasonable amount of time was to shard the job over multiple machines and then join the file back together at the end.
x264 is a software-only encoder that provides no hooks into hardware acceleration. Their ffmpeg command line indicates that no hardware acceleration hooks of ffmpeg were used.
[1] https://github.com/webmproject/libvpx/blob/master/CHANGELOG [2] https://gist.github.com/Brainiarc7/24de2edef08866c3040805048... [3] https://cgit.freedesktop.org/libva/commit/?id=fb57f5c15e72c3... [4] https://en.wikipedia.org/wiki/VP9#Hardware_implementations
But, and it’s hard to understate this, software like x264 has many man years of intricate and clever optimization work under its belt. Just look through some of the development history to see the kind of hoops jumped through and low level clock tick counting tweaks that have been made.
Also, I believe in general the expectations around AV1 have always been set realistically in the sense most are expecting that it will likely always require more compute to achieve a significant portion of any superior compression.
Important as those caveats may be, clearly there is a long way to go and you may still legitimately ask how do we know a 3 orders of magnitude deficit can be made practical?
In truth we don’t know with certainty where it will end up, that is true. However the bet was not made by guessing. There has been lots of investigation and analysis of what kind of implementations may be possible including design review with hardware engineers for that side of things.
So essentially it’s designed to outperform the current state of the art, and some high stakes educated projections have been made that it will become practical within a timeframe that still makes AV1 competitive enough to be a worthwhile value proposition.
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.
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.
AOM dev here. I'd love you to be right, but that's unfortunately not the case. They're written to improve VQ.
Regarding the "written to be correct" part of your sentence:
There's no emphasis on correctness. For monthes, aomenc has been accidentaly using different transforms sets for 8 bit and 10 bits. It also used to compute its RDO based on the legacy probability model (non-CDF) although the result was binarized using the new one (CDF)). Moreover, serious regressions (decoder can't decode the encoder's output, lossy lossless) are introduced almost every day (!), fixed the next day.
Now, regarding the "not fast" part of your sentence:
There's been a lot of work on SIMD (Current aomenc performance is measured with SIMD optimizations). Actually, the code features complex mechanisms (C header file generation from Perl scripts at configure time) to handle the dispatching between the optimizations. To make the matter worse, almost all the pixel prediction code is physically duplicated in two versions: the generic code that uses 16-bit pixels, and the 8-bit optimized code that uses 8-bit pixels. All of these are actually huge hindrances to performance-unrelated developments.
It really wouldn't be that surprising if we're still using video encoders with efficiencies somewhere in the h264-AOM range 1000 years from now. Cases where the tradeoffs make higher efficiency worthwhile are hard to come by.
True, but it hasn't been optimized as of yet, I'm pretty sure there are a lot of low-hanging fruits once they start converting code hot paths into hand-optimized assembly.
That said, no matter how much optimization it gets, it will be slower than equally optimized HEVC, h264 given that AV1 is a more complex codec.