5 ms·

Let that sink in: '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 pla

Let that sink in: '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.

JoshTriplett 9y ago
On the flip side, as the encoder gets better, the quality and bitrate will improve as well, not just the encoding time.
homero 9y ago
Netflix yes, others no, most videos aren't played often
- gpm 9y ago
  Certainly some videos on youtube, and which ones should be pretty predictable.
  - estebank 9y ago
    It doesn't even need to be predictable, just reactive.
whatever_dude 9y ago
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.
duskwuff 9y ago
The same thing was true of H264 when it first came out. Reference encoders/decoders are always incredibly slow -- they're written to be correct, not fast.
- ksec 9y ago
  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.
  - ec109685 9y ago
    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 http://cseweb.ucsd.edu/~gmporter/papers/nsdi17-excamera.pdf
BurningCycles 9y ago
>The codec is good, but the encoder has a long way to go. 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.

JoshTriplett 9y ago

On the flip side, as the encoder gets better, the quality and bitrate will improve as well, not just the encoding time.

homero 9y ago

Netflix yes, others no, most videos aren't played often

gpm 9y ago
Certainly some videos on youtube, and which ones should be pretty predictable.
- estebank 9y ago
  It doesn't even need to be predictable, just reactive.

whatever_dude 9y ago

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.

duskwuff 9y ago

The same thing was true of H264 when it first came out. Reference encoders/decoders are always incredibly slow -- they're written to be correct, not fast.

ksec 9y ago
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.
- ec109685 9y ago
  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 http://cseweb.ucsd.edu/~gmporter/papers/nsdi17-excamera.pdf

BurningCycles 9y ago

>The codec is good, but the encoder has a long way to go. 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.