"When AV1 was first released, the coding speed was slow and the time was too long, which seriously affected the availability of the encoder. With continuous optimization, its coding time has been greatly improved and can almost be used.
When I first tested AV1 coding in August 2018, its coding speed was very slow, which seriously affected the potential availability of the codec. This is illustrated in Table 1. Unless otherwise stated, all encoding time data is based on my HP zbook laptop (configured with a single 2.8 GHz Intel Xeon e3-1505m V5 CPU). In addition, libvpx is the implementation of VP9 in ffmpeg, and all references to AV1 refer to the AV1 codec available in ffmpeg.
Table 1. Encoding time when AV1 is first released
Since the end of 2018, I wrote that researchers reported that AV1 coding time was as low as 10 times libvpx coding time. When I recently started a codec evaluation project, I wondered if the time matched. I have just finished that project. Table 2 shows the current situation. I know what you're thinking. The quality of vmaf video compression last year was 96.18; The mass quoted in Table 2 is 95.55. Since six VMF points are required to produce a significant difference, even the most sensitive observers will not notice this.63 difference.
Table 2. Current optimized encoding time of AV1
According to the evaluation of other codecs in August 2018, the encoding time of AV1 is about three times that of x265 and libvpx. As you will see below, things are not exactly the same, and I'm not completely fair to other codecs, but nevertheless, its acceleration is quite amazing, don't you think so?
If you are very concerned about TL / DR, you can skip to table 6 and see the comparison with other codecs. If you want to take the time to understand how I did that, let's go into detail.
Increase of encoder speed
The command string used in our initial test is as follows:
If the same string is used for the current version of ffmpeg (I tested the n-93083-g8522d219ce version), the encoding time decreases from 226080 seconds (45k multiplied by real time) to 18196 seconds (about 3639 times real time), and the speed is increased by about 12 times. Although still 63 times slower than x265 and 80 times slower than libvpx, we can see the results shown in Table 3. The vmaf score of AV1 file created in Table 3 is 95.91, so the quality decline is very small and not obvious compared with 96.18 last year.
Table 3. Using the original command line with the current code (AOM improvements)
Table 3 shows the comparison of the performance of the two in our preliminary test. All other encoding time reductions are related to changes in the encoding string.
Find the best speed / quality tradeoff for AV1
Most codecs have presets that allow you to weigh the quality of coding time. For example, for x264 and x265, preset names include slow, very slow, fast, very fast, and medium. AV1 is used and controlled by CPU usedswitch by default. You can see that I use CPU used8in pass 1 and CPU used0in pass 2 in the above batch.
If you load the AV1 help description in ffmpeg (ffmpeg - H encoder = libaom-av1), you will see the following:
When using libvpx and AV1, the first delivery quality does not affect the second delivery, so you usually run the first delivery with the fastest / lowest quality setting. In Google's August first look direction, I run the second pass with the highest quality, namely CPU used 0. The encoding time was too slow and I didn't take the time to try these settings, as I did with x264, x265 and libvpx.
Figure 1 shows the charts I usually create for each CODEC / preset / encoder before I start rigorous testing or production coding. The red line tracks the available quality, while the blue line tracks the encoding time. For example, in CPU used5, the encoding time is 6.63% of the maximum (00:20:06 compared with 5:03:16), and the quality is 99.64% of the maximum (95.56 vmaf compared with 95.91).
Figure 1. Mass / speed curve of AV1
If you are a researcher trying to measure the absolute best quality of a particular codec, you can ignore the graph and encode at CPU used 0. If you are a video producer, you may use CPU used 5 coding, because lower settings can save the least time, while higher settings can maximize the quality. Of course, according to the numbers shown in Figure 1, if you choose to use cpu-use8, no one will think you are crazy. Suppose you code with CPU used 5, table 4 shows a comparison of coding times.
Table 4. Current version of ffmpeg, CPU used 5
Can a single five second clip encoding accurately predict the quality / speed curve of a wider range of clips encoded at multiple data rates? In my recently completed project, I used the same method on different codecs to predict the quality difference between preset use and maximum quality (and preset cutting) based on the curve of single coding of 5-second test clip, which is 1.3% (coding time from 18 minutes to 3 minutes). Then I measured the actual difference between the preset and the maximum mass of five grades and six test segments, and the actual difference was 1.4%. Therefore, although more data is always better, a single encoding should be a fairly accurate predictor.
That is, in my book "digital video coding", I used eight clips to create similar curves for x264, x265 and libvpx, with an average duration of about 2 minutes. Before I start to use a new codec or encoder (especially AV1) for strict coding, I will test a similar or larger number of samples.
Run multiple threads
In a recent project, I asked Google if there were other ways to speed up coding. An engineer suggested:
If you can use multiple threads when running the encoder, it helps the encoder speed. For HD and above resolutions, we recommend using tiles. Using blocks will lead to quality degradation. My old test shows that the loss is about 0.6% when using 2 blocks and about 1.3% when using 4 blocks.
I haven't tested 4K clips myself, so I give some suggestions here. For 1080p, use 2 tiles and 8 threads: "-- tile columns = 1 -- tile rows = 0 -- threads = 8
For 4K, use 4 tiles and 16 threads: "-- tile columns = 1 -- tile rows = 1 -- threads = 16" (even try: 8 tiles / 32 threads: "-- tile columns = 2 -- tile rows = 1 -- threads = 32") "
Before implementing blocks and threads in this project, I tested 1080p and 4K files, this time on my HP z840 40 core workstation, and used multiple threads. I used the recommended 1080p setting and the second set of 4K settings (- - tile columns = 2 -- tile rows = 1 -- threads = 32). Table 5 shows the results. At 1080p, the coding time decreases by 41.66%, while for 4K, the coding time decreases by 70.56%. The quality difference between the two cases is negligible.
Table 5. Deploying multiple threads in other test codes
For the test fragments applied to zbook test platform, deploy -- tile columns = 1 -- tile rows = 0 -- threads = 8, and their coding time on CPU used 5 decreases from 20:06 to 12:16, as shown in Table 2. At the same time, the vmaf index also fell sharply by 0.01 points (from 95.56 points to 95.55 points).
In fact, it should be clear that the operations added to the ffmpeg command string are as follows:
The settings displayed by Google engineers are likely to be AOM encoders that work independently of ffmpeg. Please note that these settings are not currently in the AV1 codec's ffmpeg help file, but try to see if you get the same results (Note: these settings are not recorded in the old version of ffmpeg I checked when studying this article, but tiles, tile columns, tile rows and row MT are recorded in the current version of AV1 help file in ffmpeg.)
Although these settings do not increase the encoding speed of any particular encoding run, they may not increase the encoding throughput on any given system. This is because they do not seem to improve coding efficiency. In itself, they seem to allow each individual coding to consume more CPU resources, which is a zero sum number on any given system.
Although there is no perfect mapping of numbers, in essence, we are not processing two codes at the same time on the same system. Each code generates a 5-minute code segment in an hour, but processing a code. Its running speed is twice that of this code and generates a 10 minute code segment per hour. In both cases, the overall system throughput is 10 minutes per hour, but the working speed of multithreaded coding is twice that of the former. If you are creating an encoder that processes multiple encodings in parallel, you may not want to use these settings. If you run an ffmpeg instance on your system, you will almost certainly do so.
Therefore, readers may now understand that I began to say that I was not comparing the differences between the two, and I was unfair to other codecs. X264, x265 and libvpx have their own quality / speed curves. If we want to apply the "practical" setting to AV1, we should make the same setting for these three codecs.
Specifically, if we use speed 2 for libvpx (instead of the highest quality speed 0) and slow preset for x264 and x265 (instead of very slow), we will get the time shown in Table 6. This makes the production cost of AV1 almost 20 times that of x265 and libvpx, which is only applicable to the number of viewers with high coding of 6 and 7 digits. So far, companies such as Netflix, Facebook and Youtube (as well as members of the AOM alliance) have often used new codecs to make videos. Impressive growth, I believe there will be more.
The vmaf scores I show in Table 6 are for reference only; A single 5-second 1080p encoding is easier than the encoded 3 Mbps, and the editing is not enough to draw any quality related conclusions. Instead, you need to view the rate distortion curve and BD rate comparison from multiple clips. I will update the results of AV1 audit in the next few weeks to create relevant comparative data.
Table 6. Speed comparison using the most "practical" settings.
In the meantime, if you are encoding AV1, try using different CPU usage settings and tiles and threads, and see if the results are similar. If you read any AV1 comparison comments referring to the encoding time, please check and review the CPU usage settings used by the researchers. If not specified, the default value is 1, which may not be used by real producers. If it is CPU used 0, although it can be said that it is suitable for academic research, the coding time has nothing to do with the way real producers actually use codecs.
To help those who want to try these new settings, here is the final version of the ffmpeg command string., Read the full text, the original title: AV1 coding time decreases, close to the use level
The source of the article: [micro signal: livevideostack, WeChat official account: microwave radio Forum] welcome to add attention! Please indicate the source of the article“
Our other product:
