(原)理解碼率控制模式(x264,x265,vpx)

理解碼率控制模式(x264,x265,vpx)

原文連接：https://slhck.info/video/2017/03/01/rate-control.html

翻譯：lihaiping1603@aliyun.com

 

前言：Variable vs. Constant Bitrate (可變碼率和固定碼率)

 

簡單地說，VBR讓編碼器爲難編碼的圖像使用更大的bits，而爲能簡單壓縮的節約bits. 那對於編碼壓縮什麼是簡單和難的呢？若是一個視頻中存在大量運動，那麼視頻中相鄰的視頻圖像幀之間的差別就會更大。同時，高空間細節和複雜的紋理也很難編碼。

 

你的編碼場景是什麼？

1，歸檔(存儲)：這種場景咱們可能要求文件的大小應該在儘量小的體積下具備儘量好的質量，可是您並不關心確切的大小。

2，流：您但願經過Internet發送文件，使用典型的視頻點播(VoD)流媒體解決方案，如HTTP漸進下載或HTTP自適應流媒體。您須要確保文件不超過特定的比特率，或者您須要以不一樣的名義比特率提供相同文件的不一樣表示(用於自適應流)。

3，實時流媒體(直播):你但願儘快的完成編碼，同時你也事先對視頻內容未知。

4，編碼設備：你想把你的文件作成DVD，藍光等等。您但願確保文件最終具備特定的大小。

 

碼率控制模式

須要注意的是:像x264這樣的編碼器在默認狀況下並不會沒必要要地用比特「填充」幀。這意味着若是你有一個很是容易編碼的場景，你的比特率可能老是低於你指定的。不要擔憂這個——只要記住，若是浪費的話，實現一個精確的比特率是沒有意義的。

1，Constant QP(CQP) :固定視頻量化參數

ffmpeg使用：

ffmpeg -i <input> -c:v libx264 -qp 23 <output>

量化參數控制幀中每一個宏塊的壓縮量.較大的值意味着更高的量化、更多的壓縮和更低的質量.QP在H.264中取值範圍從0到51，使用x264和x265能夠輕鬆地爲整個編碼過程設置一個固定的QP。注意:libvpx沒有固定的QP模式。

除非您知道本身在作什麼，而且明確地但願這樣，不然不要使用此模式!設置一個固定的QP意味着根據每一個場景的複雜性，產生的比特率會有很大的變化，這將致使輸入視頻的編碼效率很低。您可能會浪費空間，並且沒法控制實際的比特率。

Good for: Video encoding research，好處是針對視頻研究的場景
Bad for: Almost anything else      大部分的場景下都是很差的

請注意，Netflix建議使用固定qp編碼對每一個鏡頭進行編碼優化，以實現每一個場景的最佳編碼。然而，這須要大量的處理和個別編碼鏡頭的仔細組裝，因此它不是一個「一刀切」的方法，你應該使用，除非你有整個框架的實現。

Netflix參考連接：

https://medium.com/netflix-techblog/dynamic-optimizer-a-perceptual-video-encoding-optimization-framework-e19f1e3a277f

 

2，Average Bitrate(ABR)：平均碼率模式

ffmpeg使用:

ffmpeg -i <input> -c:v libx264 -b:v 1M <output>

避免使用此模式!一個主要的x264開發人員本身說，你不該該使用它。爲何?因爲編碼器不知道確切的前方時間，它將不得不猜想如何達到該比特率。這意味着速率自己會發生變化，特別是在剪輯開始的時候，在某一時刻達到目標。特別是HAS-type的流媒體，這致使巨大的質量差別在短片斷。

這不是一個恆定比特率模式!雖然ABR在技術上是一種VBR模式，但它並不比指定恆定的比特率好多少，由於它不能可靠地提供良好的質量。

Good for: Quick and dirty encodes  快速和下流的編碼
Bad for: Almost anything    大部分場景下是很差的

 

3，Constant Bitrate(CBR):固定碼率模式

ffmpeg使用(經過啓用nal-hrd選項強制編碼器始終使用特定的比特率)

ffmpeg -i <input> -c:v libx264 -x264-params "nal-hrd=cbr:force-cfr=1" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M <output>

這種模式下輸出文件須要指定爲ts格式，由於mp4格式不支持NAL stuffing（填充）。

注意:這種模式下，會比較浪費帶寬，若是你的視頻源是比較容易編碼的那種的話，但它能夠確保比特率在整個流中保持不變。在某些應用程序中使用這種模式可能有意義，可是您一般但願容許流在可能的狀況下使用較低的比特率。

Good for: Keeping a constant bitrate (duh); video streaming (e.g. Twitch)

Bad for: Archival; efficient use of bandwith

好處：在保持恆大的比特率和視頻流(例如twitch)場景有利

壞處：在存儲和高效利用帶寬的場景下是不利的。

4，2-Pass Average Bitrate(2-Pass ABR)：2-Pass平均碼率模式

ffmpeg使用:

ffmpeg -i <input> -c:v libx264 -b:v 1M -pass 2 <output>.mp4

容許編碼器進行兩次(或兩次以上)傳遞，使其可以及時估計前方的狀況。它能夠在第一輪計算編碼幀的成本，而後在第二輪更有效地利用可用的比特。這確保了在必定的比特率約束下，輸出質量是最好的。

這是對文件進行流編碼的最簡單方法。有兩點須要注意:你不知道結果的質量如何，因此你必須作一些測試來確保你的比特率對於一些複雜的內容來講是足夠高的。這種模式的另外一個缺點是可能會出現本地比特率峯值，這意味着您發送的比特率可能會超過您的客戶端可以接收到的比特率。至於選擇比特率，YouTube會給你推薦上傳的設置，但要記住，這些設置是爲了讓你上傳的質量更好而優化的，因此實際上你也能夠選擇更低的比特率。

Good for: Reaching a certain target bitrate; encoding for devices
Bad for: If you need quick encoding (e.g., live streaming)

好處是對於一些須要達到必定比特率的場景或者編碼設備是有利的。

而對於實時流或者直播這個是不利的。

youtube比特率選擇的參考連接：

https://support.google.com/youtube/answer/1722171?hl=en

以下：

 

 

5，Constant Quality(CQ)/Constant Rate Factor(CRF):恆定質量或者恆定速率因子模式

ffmpeg示例:

ffmpeg -i <input> -c:v libx264 -crf 23 <output>

在H.264和H.265中，CRF的範圍是從0到51(就像QP)。23是x264的良好默認值，28是x265的默認值。18 (x265爲24)應該在視覺上透明;任何更低的值均可能會浪費文件大小。±6的值將致使大約一半或兩倍的原始比特率。對於VP9, CRF能夠是0到63。推薦值爲15-35。
這種模式惟一的缺點是，您不知道最終的文件大小或比特率的波動。
請注意，雙通道和CRF編碼具備相同的比特率應該是相同的定性。

Good for: Archival; achieving the best possible quality
Bad for: Streaming; obtaining a certain bitrate / file size

對於存儲歸檔模式，這種是有利的，能實現最好的視頻質量。而對於流來講，或者得到必定碼率或者文件體積的來講，這種是不利的。

6，Constrained Encoding(VBV)：約束編碼模式VBV

VBV視頻緩衝驗證器提供了一種確保比特率被限制到某個最大值的方法。這對於流媒體很是有用，由於您如今能夠肯定在必定的時間範圍內不會發送比承諾的更多的比特。VBV既能夠與2-Pass VBR一塊兒使用(在兩個通道中都使用)，也能夠與CRF編碼一塊兒使用——它能夠「添加」到已經提供的速率控制模式中。後一種模式也稱爲「上限CRF」。

打開VBV的-maxrate和-bufsize選項來設置最大比特率和預期的客戶端緩衝區大小。

ffmpeg示例：

ffmpeg -i <input> -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M <output>

ffmpeg -i <input> -c:v libx265 -crf 28 -x265-params vbv-maxrate=1000:vbv-bufsize=2000 <output>

ffmpeg -i <input> -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f null /dev/null

ffmpeg -i <input> -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 2 <output>

注意:若是您對直播應用程序這樣作，而且但願加快編碼過程，那麼使用x264和x265的時候，能夠添加-tune zerolatency和- ultrafast選項。他們下降了你獲得必定比特率的質量，但大大加快了過程。對於libvpx-vp9，須要設置-quality realtime和-speed 5。有關更多信息，請參閱H.264和VP9指南。

如何設置bufsize?這取決於你但願比特率有多大的可變性。一個好的默認設置是將緩衝區大小設置爲最大速率的兩倍，可是建議根據流設置的不一樣而有所不一樣。若是您的客戶端緩衝區更小(大約幾秒鐘)，則bufsize應該與maxrate大小相同。若是您想約束流的比特率，請嘗試將bufsize設置爲最大比特率的一半或更少。

當您將VBV應用於CRF編碼時，訣竅是找到一個CRF值，該值平均會產生您所指望的最大比特率，但不會更多。若是你的編碼老是「最大化」你的最大比特率，你的CRF可能設置得過低了。在這種狀況下，編碼器試圖花費它沒有的比特。另外一方面，若是你有一個高的CRF，使比特率不老是達到最大，你仍然能夠下降它來得到一些質量。例如，你編碼在crf18沒有VBV。您的剪輯以3.0 Mbit/s的平均比特率結束。但你但願你的VBV設置上限剪輯1.5 Mbit/s，因此你須要把你的CRF下降到24來獲得一半的比特率。

Good for: Streaming under bandwith constraints; live streaming (with CRF, 1-pass); VoD streaming (with target bitrate, 2-pass)
Bad for: People who want to play around; archival

這個模式對於在必定受限的帶寬流媒體下和直播流(用crf,1-pass模式)，;VoD流媒體(使用目標比特率，2-pass)場景，是有好處的，而對於歸檔存儲場景，並非那麼有利。

 

7，實例比較演示

讓咱們從不一樣的比特率控制模式開始。左邊是3000 kbit/s，右邊是7500 kbit/s。我排除了其餘目標比特率，由於它們在圖中沒有表現出強烈的差別，由於比特率已經處於如此低的水平，編碼器在如何分配它上沒有太多的選擇。這些行是不一樣的剪輯從大巴克兔(BBB)和眼淚的鋼鐵(ToS)。這條線表明了對單個幀大小的LOESS(擬合)平滑——它指示了比特率在剪輯持續時間內的變化。

 

 

 

 

你能夠看到——尤爲是前四個內容——ABR(綠松石線)和ABR+VBV(紫色)錯誤地估計了剪輯的複雜性。事實上，大的巴克兔序列以漸隱、平滑的梯度和低運動開始，這意味着不須要不少位元來壓縮它以得到足夠好的質量。2-pass方法正確地以較低的比特率開始，並節省帶寬。視頻剪輯的最後三分之一包含了大量的空間細節，這使得2-pass模式消耗了更多它在開始時保存的比特。

對於基於質量的模式(CQP和CRF)，我只顯示CRF/QP 17和23的結果，這是質量範圍的「好」端(就像3000和7500 kbit/s是全高清視頻的「好」值)。曲線的順序是相反的——越低意味着質量越好:

 

 

 

 

在這裏，能夠看到與2-pass相同的趨勢:比特率跟隨內容的複雜性。然而，使用CRF時，它受到了更多的限制，能夠在不須要的地方保存數據。最有趣的狀況是左下角:CRF比常數QP節省比特率，就像它一般作的那樣，但它是以常數偏移量作到的。我不得不猜想爲何會這樣，也許這篇文章將會更新一些進一步的分析。

通常來講，咱們能夠看到CRF方法如何很好地匹配內容，只要咱們事先知道結果的平均比特率是多少……這就是CRF+VBV發揮做用的地方:

 

 

 

 

爲給定的CRF選擇正確的目標/最大比特率一般是猜想，徹底取決於源視頻。然而，當正確完成時，您不會對質量進行太多的限制，將其推到極限(如3000 kbit/s和CRF 17的狀況)。你也不想讓比特率變化太多。CRF 23是libx264的默認設置，您能夠看到，在給定適當的目標比特率設置(好比7500 kbit/s)的狀況下，這種編碼模式容許比特率的變化足以反映內容複雜性的差別，同時仍然符合VBV模型。

 

8，小結

理解不一樣的速率控制模式並不容易。不幸的是，最簡單的解決方案(只指定比特率)是徹底不推薦的，可是Web一直使用這種方法傳播代碼示例。

總結一下，根據你的用例，你應該這樣作:

檔案- CRF，給你想要的質量。
流-2-pass(雙通道)CRF或ABR與vbv恆定的比特率。
實時流媒體-一遍CRF或ABR與vbv恆定的比特率，或CBR，若是你能夠浪費比特。
設備編碼——一般是2-pass ABR。

 

轉載請註明出處：https://www.cnblogs.com/lihaiping/p/11726306.html