obs直播軟件里qsv的速率控制方式有：CBR、VBR、VCM、CQP、AVBR、ICQ、LA-ICQ、LA，而x264的碼率控制方式僅有CBR、ABR、VBR、CRF四種，極客灣也進(jìn)行過(guò)介紹（https://www.bilibili.com/video/av37424012），這里大致翻譯了一下Intel開(kāi)發(fā)者社區(qū)里的一篇文章（在Google翻譯的基礎(chǔ)上進(jìn)行一些微調(diào)，原文地址：https://software.intel.com/zh-cn/articles/common-bitrate-control-methods-in-intel-media-sdk）。

英特爾?MediaSDK中的比特率控制方法（BRC）

由Surbhi M.發(fā)布于2014年8月19日，更新于2016年5月2日

介紹

想要通過(guò)?IntelMedia?SDK?或?Intel?MediaServer?Studio中?的相同組件提高編碼質(zhì)量？?有兩個(gè)主要的方式：

1. 編碼器算法/參數(shù)（包括“宏”算法調(diào)整復(fù)雜性權(quán)衡，如質(zhì)量預(yù)設(shè)/目標(biāo)使用）

2. 比特率控制

Intel Media SDK提供了許多方法來(lái)設(shè)置比特率控制以滿(mǎn)足您的需求。

可用的比特率控制算法

英特爾編碼器包括多種類(lèi)型的比特率控制，每種控制都針對(duì)不同類(lèi)型的用例而設(shè)計(jì)。?沒(méi)有通用的選擇在所有場(chǎng)景中都是最佳選擇。?選擇最符合您要求的模式（適用于AVC編解碼器）：

建議?：

• Lookahead（LA）通常是編碼為長(zhǎng)期目標(biāo)比特率，并且單個(gè)幀延遲不是首要關(guān)注點(diǎn)時(shí)，最佳畫(huà)質(zhì)的選擇 - 例如，文件轉(zhuǎn)碼。

• CBR是穩(wěn)定比特率和低延遲的最佳通用選項(xiàng)，VCM也可能是某些視頻會(huì)議案例的理想選擇。

• 對(duì)于游戲/顯示流媒體，最佳選擇是QVBR，它提供最佳的主觀視頻質(zhì)量與網(wǎng)絡(luò)要求的幀大小容差。

• x264的默認(rèn)速率控制（FFmpeg的默認(rèn)h264方式）是CRF。?這允許比特率波動(dòng)以維持目標(biāo)質(zhì)量水平。?Media SDK的ICQ和LA_ICQ是這類(lèi)算法的最佳匹配。

測(cè)量比特率的困難

與未壓縮視頻不同，編碼比特流的幀大小預(yù)計(jì)會(huì)有很大差異。?IDR和I幀可以比伴隨的P幀和B幀大一個(gè)數(shù)量級(jí)或更大。?這是視頻壓縮的核心思想之一：P幀和B幀存儲(chǔ)差異，不對(duì)整個(gè)圖像進(jìn)行編碼。?B幀往往小于P幀。?內(nèi)容差異/場(chǎng)景變化可能導(dǎo)致進(jìn)一步的變化。?此外，存在分層B幀，其提供良好的有效壓縮效率并限制誤差的傳播，就尺寸方面而言，這些幀更接近P幀。

HRD / VBV合規(guī)性

假設(shè)參考解碼器（HRD），以前稱(chēng)為來(lái)自mpeg2時(shí)代的視頻緩沖驗(yàn)證器（VBV），是“漏桶”模型，如果比特流符合，則增加任何符合解碼器將能夠接收流的可能性。按預(yù)期沒(méi)有延遲或丟幀。?如果編碼流的目標(biāo)受眾包括低成本硬件解碼器而沒(méi)有用于通用計(jì)算機(jī)的大多數(shù)處理器可用的額外緩沖+錯(cuò)誤恢復(fù)，則這尤其必要。

HRD是一種簡(jiǎn)化模型，假設(shè)數(shù)據(jù)是根據(jù)各個(gè)幀大小到達(dá)但以給定比特率退出。?目標(biāo)是保持緩沖區(qū)或“桶”不受下溢或上溢的影響。

• 當(dāng)輸入數(shù)據(jù)幀不像HRD的指定退出速率那樣快地提供新數(shù)據(jù)時(shí)，發(fā)生下溢（緩沖區(qū)空）。

• 當(dāng)緩沖區(qū)的退出速率不足以在新幀到達(dá)時(shí)吸收新幀時(shí)，會(huì)發(fā)生上溢（緩沖區(qū)超出滿(mǎn)）。

對(duì)于具有小緩沖區(qū)的硬件解碼器，上溢和下溢可能意味著丟幀和其他不良的最終用戶(hù)體驗(yàn)。?但是，保持HRD一致性可能很昂貴。?例如，在某些情況下，必須重新編碼幀。?它還會(huì)增加BRC算法的復(fù)雜性和性能影響。?因此，最好先了解何時(shí)需要。

BRC算法的類(lèi)型

專(zhuān)家算法

恒定QP（CQP）提供最大的控制和最佳性能。?毫無(wú)疑問(wèn)，使用英特爾編解碼器可以通過(guò)CQP和自定義內(nèi)容分析獲得最佳編碼效率。?CQP通常也具有顯著的性能優(yōu)勢(shì)。?CQP最接近參考實(shí)現(xiàn)。?它是訪問(wèn)編解碼器功能和測(cè)量編碼器參數(shù)/算法權(quán)衡效果的最直接方式，也是評(píng)估其他編解碼器算法實(shí)現(xiàn)的最明確方法。

毫無(wú)疑問(wèn)：如果沒(méi)有額外的開(kāi)發(fā)，這項(xiàng)工作就無(wú)法完成。?簡(jiǎn)單地為所有幀設(shè)置一個(gè)全局QP而不進(jìn)行內(nèi)容分析/動(dòng)態(tài)調(diào)整很可能比其他BRC替代品具有更低的比特率和質(zhì)量。?CQP的主要缺點(diǎn)是它完全取決于應(yīng)用程序的量化器選擇。?由于QP與感知質(zhì)量或結(jié)果比特率之間沒(méi)有簡(jiǎn)單或線性映射，因此必須建立一個(gè)反饋系統(tǒng)來(lái)分析內(nèi)容并適應(yīng)每個(gè)幀大小的結(jié)果。

然而，CQP模式解鎖了最復(fù)雜的內(nèi)容分析類(lèi)型，它提供了廣泛的創(chuàng)新領(lǐng)域，利用計(jì)算機(jī)視覺(jué)和感知敏感內(nèi)容分析，跨幀和使用每MB QP調(diào)整。?
缺乏分析意味著CQP通常是最快（最低復(fù)雜度）的BRC方法，盡管應(yīng)用程序級(jí)別所需的額外工作通常會(huì)超過(guò)這個(gè)。?由于CQP最好留給專(zhuān)家用戶(hù)，本文的其余部分將重點(diǎn)關(guān)注“自動(dòng)”BRC算法。

遺留算法

從音頻和視頻壓縮開(kāi)始的標(biāo)準(zhǔn)/傳統(tǒng)算法是CBR和VBR：

恒定比特率（CBR）?
在該方法中，當(dāng)比特流幀的大小小于滿(mǎn)足HRD要求所需的大小時(shí)，編碼器執(zhí)行填充（將零添加到編碼幀的末尾）。?CBR“優(yōu)化”恒定的數(shù)據(jù)流，這意味著總體比特率的很大一部分被浪費(fèi)在填充上而不是用于編碼幀細(xì)節(jié)。?CBR的目標(biāo)是提供恒定的數(shù)據(jù)流，這主要導(dǎo)致未使用的容量。?此方法可用于歷史/遺留原因?。?這是許多Media SDK示例中使用的默認(rèn)BRC方法。

BufferSizeInKB是CBR的重要參數(shù)。?較小的BufferSizeInKB意味著較小的幀大小變化。?在非常小的緩沖區(qū)大小下，維護(hù)HRD變得越來(lái)越困難，但這是降低CBR峰值的最佳方法。?較大的緩沖區(qū)意味著可以允許更多變化以在需要時(shí)保持質(zhì)量。?一個(gè)這樣的例子是使用教程來(lái)更改緩沖區(qū)inKB以查看瞬時(shí)比特率的變化。?

這里以Kbps使用的比特率表示在被編碼的幀的周期內(nèi)的變化。?可編碼為4000kbps（目標(biāo)比特率）的最小緩沖區(qū)大小為34KB，低于此編碼器會(huì)拋出錯(cuò)誤。?在該變化開(kāi)始變得飽和之后，瞬時(shí)比特率的變化從34KB到1000KB。?可以看到最小的變化，緩沖區(qū)大小等于200KB。?但是，如果可以容忍大的變化，那么其他BRC模式可能更合適。?對(duì)于不同的輸入，該值將是不同的，并且對(duì)于不同比特率的編碼也將是不同的。

可變比特率（VBR）?
該方法允許更多比特率變化以匹配輸入的復(fù)雜性，即將更高比特率分配給諸如場(chǎng)景改變和低比特率到更復(fù)雜場(chǎng)景的復(fù)雜場(chǎng)景。?它試圖實(shí)現(xiàn)?更小的整體文件大小，但也會(huì)產(chǎn)生不可預(yù)測(cè)的峰值。?該方法通過(guò)允許比特率更多地波動(dòng)并且還通過(guò)禁用填充來(lái)提供總體更好的比特率質(zhì)量。?這是Media SDK教程中使用的默認(rèn)方法。?但是，對(duì)于需要低延遲且必須保持目標(biāo)比特率的情況子集，應(yīng)考慮VBR。

使用Media SDK教程運(yùn)行比較VBR和CBR的測(cè)試。

前瞻算法

Lookahead是VBR的擴(kuò)展，代表了英特爾編解碼器自動(dòng)BRC的重大進(jìn)步。?它可以提供大量的質(zhì)量改進(jìn)，有時(shí)這種改進(jìn)比選擇更的目標(biāo)使用率更大，與CBR / VBR的FPS /信道容量大致相同。?它應(yīng)被視為許多文件到文件轉(zhuǎn)碼方案的默認(rèn)選擇。

Lookahead為關(guān)鍵的VBR / CBR挑戰(zhàn)提供了答案：可以預(yù)見(jiàn)到像I幀和場(chǎng)景變化這樣的大幀大小變化的原因。?分析幀的緩沖區(qū)（長(zhǎng)度可配置前瞻深度參數(shù)）以查找潛在的比特率中斷。?這允許具有兩遍編碼的許多優(yōu)點(diǎn)的“預(yù)覽”或“前瞻”。?實(shí)際上，具有提前通知，更高的可變性和更長(zhǎng)的延遲的VBR。

它的工作原理是在實(shí)際編碼之前對(duì)包括復(fù)雜性，相對(duì)運(yùn)動(dòng)和依賴(lài)性在內(nèi)的數(shù)十個(gè)幀進(jìn)行廣泛分析。?它在幀之間分配可用的比特預(yù)算，以產(chǎn)生最佳的編碼質(zhì)量。?它在快速運(yùn)動(dòng)視頻和計(jì)算機(jī)動(dòng)畫(huà)上產(chǎn)生了良好的效果。?此外，還改進(jìn)了SSIM，PSNR和主觀視頻質(zhì)量等客觀指標(biāo)。?它適用于任何GOP模式，但B幀的存在提供了最佳質(zhì)量增益。?一個(gè)副作用是它顯著增加編碼延遲和內(nèi)存消耗。?對(duì)于這種增加的延遲，它可能不是游戲直播的最佳選擇。

LookAheadDepth?，一個(gè)指定超前速率控制算法深度的參數(shù)。?它是編碼前分析的幀數(shù)。?有效值范圍為10到100.要指示SDK編碼器使用默認(rèn)值，應(yīng)用程序應(yīng)將此字段歸零。?此模式中唯一可用的速率控制參數(shù)是mfxInfoMFX :: TargetKbps。?其他兩個(gè)參數(shù)MaxKbps和InitialDelayInKB將被忽略。?必須初始化Media SDK以使用API版本1.7或更高版本才能使用Media SDK方法。

Lookahead僅適用于英特爾?Iris?Pro圖形，英特爾?Iris?圖形和Haswell架構(gòu)（第四代核心版）上的英特爾?高清顯卡以及前向。?支持隔行掃描和漸進(jìn)式內(nèi)容。?

特殊用途算法

ICQ / LA_ICQ?：這些算法專(zhuān)注于維持目標(biāo)質(zhì)量水平（大致相當(dāng)于CBR 1-51量化）。?它們?cè)试S比CBR / VBR / lookahead更大的變化。

• ICQ（智能CQ）模式保持給定的質(zhì)量水平

• LA_ICQ為算法添加了超前緩沖區(qū)

QVBR：還通過(guò)mfxCodingOption3設(shè)置目標(biāo)質(zhì)量等級(jí)，QVBRQuality參數(shù)，以及可能需要限制可變性的場(chǎng)景的目標(biāo)比特率，例如游戲/顯示流場(chǎng)景。?該算法試圖以最少的比特來(lái)實(shí)現(xiàn)主觀質(zhì)量，同時(shí)嘗試保持比特率恒定并且遵循HRD合規(guī)性。?QVBR從第4代Intel?Core處理器（代號(hào)Haswell）開(kāi)始支持。

VCM?：這是一種專(zhuān)門(mén)的視頻會(huì)議模式。?在某些視頻會(huì)議場(chǎng)景中，它可以在較低的比特率下提供更高的質(zhì)量。

注意?：對(duì)于AVC編解碼器，Look Ahead（LA），LA_ICQ，LA_HRD，VCM，QVBR在軟件實(shí)現(xiàn)中不可用。?有關(guān)最新更新和詳細(xì)信息，請(qǐng)查看發(fā)行說(shuō)明?。

其他參數(shù)?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

BRCParamMultiplier?，一個(gè)參數(shù)，指定比特率控制參數(shù)的乘數(shù)。?實(shí)現(xiàn)更高的比特率是有用的。?該乘法器與TargetKbps目標(biāo)比特率（mfxU16）相乘，可實(shí)現(xiàn)相當(dāng)高的比特率（經(jīng)過(guò)驗(yàn)證，最高可達(dá)200mbps）。?請(qǐng)記住，此乘數(shù)也會(huì)影響B(tài)ufferSizeInKB，IntialDelayInKB和MaxKbps。?下表顯示了使用此參數(shù)時(shí)的方案。

我使用了simple_encode教程（取自Media Solution Portal上的教程）對(duì)720p -?Park Joy無(wú)壓縮視頻進(jìn)行編碼，以便通過(guò)BRCParamMultiplier和沒(méi)有BRCParamMultiplier實(shí)現(xiàn)更高的比特率，結(jié)果如下：?

該表顯示在60Mbps之后，傳統(tǒng)方法沒(méi)有達(dá)到更高的比特率。?在這些情況下，建議您使用BRCParamMultipler超過(guò)60Mbps，并確保相應(yīng)地修改Maxlength和BufferSizeInKB。?BRCParamMultiplier是在Media SDK API 1.3版本中引入的。