Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
AV1 encoding is now only 2x slower than x265. See the latest results here.
Though FFmpeg took 50 minutes to produce a test file that both x264 and x265 encoded in about two minutes, the Alliance for Open Media’s aomenc encoder, running the same version of AV1 (version 2) produced the file in about 15 minutes. So FFmpeg’s slow AV1 encoding performance on Windows appears to be a compiling issue that can and probably will be overcome, not a codec issue.
Still working on the AV1 encoding comparison and have some interesting findings to report.
By way of background, when the Alliance for Open Media (AOM) released version 2.0 in May, Google Principle Engineer and Engineering Director Yaowu Xu published a post on LinkedIn that promised up to 430x speed improvements in AV1. However, when I first compared AV1 encoding times with x264 and x265 in this article, I clocked x264 at 2:09 (min:sec), x265 at 2:18, and AV1 at 50:43. You can see the encoding strings used here. Last time I looked at encoding speed (see Good News: AV1 Encoding Times Drop to Near-Reasonable Levels), AV1 was about 14 times slower than x265, so it appeared that AV1 had regressed.
Question 1 was whether the version of FFmpeg I was testing used AV1 version 1 or 2? Thought it appeared that FFmpeg used version 2 from the build notes, performance seemed to indicate otherwise. Help came from two sources; Sebastien Faure, Global Integration Manager at CrossKnowledge, shared in a Tweet that showed that current versions of FFmpeg were running version 2.0. An engineer from Google also advised:
You can do a quick test with a 1 frame encode using something like:
ffmpeg -i <video> -strict -2 -c:v libaom-av1 -frames:v 1 -loglevel debug /tmp/out.ivf
then look for a line like this early in the output:
[libaom-av1 @ 0x55988999b540] 2.0.0-284-gcfd029691
I did this and confirmed that the build of FFmpeg that I was working with, downloaded from Zeranoe on July 16, 2020, was using version 2.0.
Then I encoded the same file with the Alliance for Open Media’s aomenc.exe, and it produced the same file in 14:56 as compared to 50:43 for FFmpeg, about 70% faster and only seven times slower than x265. The VAMF score was 94.53 compared to FFmpeg’s 94.43, so about the same.
Why the difference? I asked the engineer at Google in this dialog which I’ll share in full:
Me: Is this an optimization that the folks at Zeranoe can deploy, or will their implementation always be slower than aomenc?
Google: This would require a change on their end for how libaom is configured and built. libvpx appears to be correct in that binary so it might be an issue with the mingw target used to produce the windows binaries.
Me: Could a reasonably proficient programmer compile a version of FFmpeg that would match aomenc’s performance for a specific platform? If so, what would they have to do?
Google: There are generic instructions as well as guides for particular platforms:
https://trac.ffmpeg.org/wiki/CompilationGuide/Generic
https://trac.ffmpeg.org/wiki/CompilationGuide
The difficulty can be in getting all the external libraries included that you need.
So, what does all this mean? Well, if you’re running on Linux you should benchmark the speed difference between FFmpeg and aomenc yourself, since the times may be much closer.
On Windows, I’m guessing that FFmpeg’s AV1 encoding performance will soon be much closer to aomenc. In the short term, if you’re benchmarking AV1 encoding on Windows, use aomenc, not FFmpeg. And if you’re integrated AV1 encoding into a WIndows-based workflow, considering using aomenc until FFmpeg’s encoding times catch up.
