AV1很強?。?/strong>本文是入門向，且是寫給自己看的文章，非常流水賬，也懶得給相關(guān)的內(nèi)容放鏈接，本文的內(nèi)容大多來自互聯(lián)網(wǎng)，你也可以花上幾個小時來自己了解這些東西（

相對于H.265以及HEVC來說，AV1的編碼不會擁有漫無休止的授權(quán)費（AOMedia是這么說的，但也有一個公司（版權(quán)流氓？）幾年前跳出來說成立了專利池之類的，還說AOMedia說的是謊言，具體你去他們官網(wǎng)看看就知道了（官網(wǎng)還有5G什么什么的，懶得看），此外，中國的編碼AVS系列好像也是不會擁有漫無休止的授權(quán)費的）

好，進入正題。由于硬件不支持（包括顯卡和核芯顯卡），顯卡hevc渲染體積大于h265（這個可以上veryslow甚至placebo?），種種原因，最后接觸研究了一下AV1這個東西。

（順便說說，軟件解碼好像大多用的dAV1d，也許是因為是目前最好的)

AV1有三大軟件編碼（好像還有個谷歌的？據(jù)說慢，懶得查）

libaom-AV1

aom應(yīng)該就是aomedia的意思，這是AOMedia 概念驗證的產(chǎn)物，后面也有優(yōu)化，畫質(zhì)最好。

-cpu-used n (越高越快，越低越慢但是會處理得更好。n=[0,8]，其中7,8在加上-usage realtime時可用，脫離ffmpeg再加realtime可以解鎖9和10）

-row-mt n (0單線程，1多線程）

-tiles axb (如2x2,1x4,4x1，這個我用2x2,但不清楚具體情況?？梢杂脕?strong>加快解碼速度，應(yīng)該和編碼沒關(guān)系吧……假如2x2,那就是4tiles，原文說Enabling row-mt is only faster when the CPU has more threads than the number of encoded tiles.就是說假如16核心的cpu設(shè)置了16個tiles，多線程和速度就和單線程一樣？那太可怕了（

-crf n （n=[0,63]，0的時候會產(chǎn)生更大的文件，63文件就小了，但是更糊，如果計算時間長一點說不定就可以好一些，這是個時間和空間的取舍。什么信息熵信息論邊際效應(yīng)的，不懂）

----上方的參數(shù)夠我用了，還有一些其他的參數(shù)，比如控制比特率等等……自己去看----

沒有介紹到的東西：-strict experimental，-b:v，minimum and maximum bitrate，-movflags +faststart，two-pass encoding，Average Bitrate，maximum keyframe interval，10-bit support，lossless encoding

壓制一個對質(zhì)量要求不太高的素材：


ffmpeg -i output.mp4 -c:v libaom-AV1 -cpu-used 6 -crf 63 -row-mt 1 -tiles 2x2 aom.mp4


壓制后大?。?.54M，速度：0.25x，總計1分40秒

libsvtAV1

svt不清楚是什么意思，編碼器與Intel 、 Netflix有關(guān)，性能優(yōu)化好（一般cpu全核心跑滿，上面那個aom用那個參數(shù)大概全核心70%）

-preset n (n=[0,13]，越大越快，據(jù)說0的速度很極端的慢，所以最好用1或者干脆用libaom）

-crf n （同libaom的參數(shù)）

---------------------

沒有介紹到的東西：tuning for visual quality，fast-decode，keyframe interval，film grain synthesis

同樣是那個素材：

ffmpeg -i output.mp4 -c:v libsvtAV1 -preset 10 -crf 63 output_AV1_fast.mp4


壓制后大?。?.85M，速度2.46x，總計11秒

ffmpeg -i output.mp4 -c:v libsvtAV1 -preset 6 -crf 63 output_AV1_slow.mp4


壓制后大?。?.42M，速度0.5x，時間48秒（順帶一提，preset5 是1分52秒）


librAV1e（rust AV1 encoder）

簡單從零開始的社區(qū)驅(qū)動型開發(fā)的編碼器（好像和Mozilla有關(guān)系？我不清楚，自己去查）

這個編碼器在快速編碼的時候效果不怎么好，大概就是慢速的時候?qū)Π挡考毠?jié)掌握的更好。但是很多feature，應(yīng)該還有很多bug……

-speed n (n=[-1,10]，10最快，-1自動，默認是0）

-tiles n（n=[-1,你的cpu線程數(shù)]，其中-1自動，自動默認是0。這個tiles和上面那個aom不同，設(shè)置成16就能全核運行，設(shè)置成0就只有單線程……）

-qp n（n=[-1,255]，類似于上面兩個的crf，但卻好像有點額定質(zhì)量的意思，不懂，建議用-b:v)

--low-latency（低延遲，可以犧牲畫質(zhì)加速）

這個太復(fù)雜了。-----------

反正效果沒有上面兩個好就是了。

ffmpeg -i output.mp4 -c:v librAV1e -b:v 1000000 -tiles 16 -rAV1e-params speed=10:low_latency=true:no-scene-detection=1? output_rAV1e_fast.mp4

這是我能做到的最快的配置了，然而速度很慢（

由于debian上的0.5幾的版本用的是sse指令集，為了用上avx2指令集的0.6版本還可以這樣子（在不重新安裝ffmpeg的情況下）：

ffmpeg -i ./output.mp4 -pix_fmt yuv420p -r 60 -f yuv4mpegpipe - | ./rAV1e - -o - --speed=10 -b 1000 --low-latency --no-scene-detection --tiles 16 --threads 16 | ffmpeg -i - -c:v copy 1.mp4

這個 | 和 - 的搭配…… - 代表（輸出到/輸入自）（管道/標準輸入輸出），反正我作為一個linux用戶表示學到了（

總結(jié)

rAV1e就算用最快的參數(shù)也快不到哪里去，而且質(zhì)量一般，也許在慢的時候可以比aom快（但是在畫面靜止的時候aom和svt可以更快地省略式編碼，而rAV1e卻會照單全收，具體可以看那幾百條issue和doc，反正我是頭暈了（哪怕開著翻譯……）而且有bug，比如遇到亮度快速變化的時候，同時設(shè)置的speed不是10的時候……這屬于是“未完成”的AV1編碼器。

svt-AV1是最快的，當你設(shè)置13的preset+63的crf，就可以得到 BV1J14y1U7ss 的畫質(zhì)啦（

aomAV1的畫質(zhì)應(yīng)該是最好的，但是慢起來是真的慢。

所以呢？我的結(jié)論是：不在意時間：動態(tài)細節(jié)怪請比較rAV1e 最新版和加了參數(shù)的svt，靜態(tài)的可以比較加了參數(shù)的svt和aom。在意時間：svt默秒全。以上就是AV1軟編碼的全部內(nèi)容，不在意體積大小和弱設(shè)備軟解高清能力的用h265、hevc、h264顯然更好。

這就是幾天時間隨便查找的知識，文章有誤建議評論，要是不懂可別問我（例如ffmpeg壓制相關(guān)的，我知道的不比你知道的多）。什么？你問ffmpeg怎么安裝？看到這篇文章的你是幸運的，我的回答是，假如你想獲得救贖的話，去用linux吧（