11 ms·

I'd assume encoding was largely software-based using a POC encoder while x264/vp9 video encoders probably already take advantage of hardware acceleration shortc

I'd assume encoding was largely software-based using a POC encoder while x264/vp9 video encoders probably already take advantage of hardware acceleration shortcuts evolved over many years. > 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.

written 9y ago
x264 is a software codec.
voltagex_ 9y ago
x264 runs circles around all the hardware accelerated encoders, at least quality wise. 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.
- aidenn0 9y ago
  x265 gets ~10fps on veryslow with 480p video on a recent workstation. Intel and AMD are pretty much tied there because Intel's per-core performance is significantly higher for x265, but AMD has more cores.
niftich 9y ago
libvpx, the VP9 encoder library used in this test, has no support for any hardware encoder blocks for VP9 [1], so it does everything in software. There are ways [2] to compile some support into ffmpeg-with-libvpx that makes it able to invoke the hardware encoder in newer Intel CPUs (Skylake or newer) [3][4] (using vp9_vaapi) but it's doubtful that this was used, since their command-line switches indicate nothing of the sort. 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 https://github.com/webmproject/libvpx/blob/master/CHANGELOG [2] https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3 https://gist.github.com/Brainiarc7/24de2edef08866c3040805048... [3] https://cgit.freedesktop.org/libva/commit/?id=fb57f5c15e72c39efeb2a10492a327110d6a06c8&utm_source=anzwix https://cgit.freedesktop.org/libva/commit/?id=fb57f5c15e72c3... [4] https://en.wikipedia.org/wiki/VP9#Hardware_implementations https://en.wikipedia.org/wiki/VP9#Hardware_implementations
- lallysingh 9y ago
  but let's remember that x264 has had a lot of time to find drop optimizations in simd use and time for CPUs to start optimising for it as a use case.
WhitneyLand 9y ago
No, it wasn’t hardware against software. 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.

written 9y ago

x264 is a software codec.

voltagex_ 9y ago

x264 runs circles around all the hardware accelerated encoders, at least quality wise. 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.

aidenn0 9y ago
x265 gets ~10fps on veryslow with 480p video on a recent workstation. Intel and AMD are pretty much tied there because Intel's per-core performance is significantly higher for x265, but AMD has more cores.

niftich 9y ago

libvpx, the VP9 encoder library used in this test, has no support for any hardware encoder blocks for VP9 [1], so it does everything in software. There are ways [2] to compile some support into ffmpeg-with-libvpx that makes it able to invoke the hardware encoder in newer Intel CPUs (Skylake or newer) [3][4] (using vp9_vaapi) but it's doubtful that this was used, since their command-line switches indicate nothing of the sort. 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 https://github.com/webmproject/libvpx/blob/master/CHANGELOG [2] https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3 https://gist.github.com/Brainiarc7/24de2edef08866c3040805048... [3] https://cgit.freedesktop.org/libva/commit/?id=fb57f5c15e72c39efeb2a10492a327110d6a06c8&utm_source=anzwix https://cgit.freedesktop.org/libva/commit/?id=fb57f5c15e72c3... [4] https://en.wikipedia.org/wiki/VP9#Hardware_implementations https://en.wikipedia.org/wiki/VP9#Hardware_implementations

lallysingh 9y ago
but let's remember that x264 has had a lot of time to find drop optimizations in simd use and time for CPUs to start optimising for it as a use case.

WhitneyLand 9y ago

No, it wasn’t hardware against software. 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.