8bit和10bit視頻編碼的優(yōu)劣對比

之前我也發(fā)了貼說明10bit壓制的優(yōu)勢以及播放方法，也提供了一些自壓的10bit視頻供測試：/thread-708211-1-1.html當(dāng)然光提供10bit視頻的確很難讓人信服其優(yōu)勢，于是我今天就做了個8bit與10bit編碼的對比測試。壓制方法：使用06_taro的x264編譯版：/newbbs/viewtopic.php?f=8&t=219SAP的EPx264壓制腳本：/newbbs/viewtopic.php?f=8&t=168前者就是帶patch以及位深轉(zhuǎn)換修復(fù)的x264編譯版。后者是個方便的腳本，可以實(shí)現(xiàn)1stpass使用指定的CRF（固定質(zhì)量模式，數(shù)值越低質(zhì)量越好）編碼，然后2ndpass使用1stpass判定出來的碼率進(jìn)行編碼。所以下文所說的CRF指的都是1stpass使用的，實(shí)際上還是2pass（二次編碼）模式。8月31日新增3個高壓視頻測試：碼率大約1230kbps的720p，K-ON!的NCED加上雪飄的華麗字幕（做成了內(nèi)嵌，因?yàn)橥鈷斓脑挄浅：腃PU資源）。8bit和10bit在色彩過渡區(qū)域有著巨大差距。碼率大約700kbps的AnohanaEP01的ED，加上雪飄的字幕做成內(nèi)嵌。用了2passbitrate=4000壓的PlanetEarth1080i25版本（fakeinterlaced）EP01前2分鐘的片段，封裝了1條DTS-HDHR音軌和9條PGS字幕（包括DIY中字）。http://u?115?com/folder/f02c9c0983f這里要強(qiáng)調(diào)的關(guān)鍵的一點(diǎn)就是抖動（dither），我們用的TN屏都是6bit的，卻能顯示8bit的色彩，就是因?yàn)槭褂昧薲ither，舉個例子，就是反復(fù)顯示16和17兩個值來達(dá)到16.5的效果，通過改變其比例，可以實(shí)現(xiàn)16-17之間的某個值。但是一個平滑的8bit數(shù)據(jù)在dither成6bit以后，不光有質(zhì)量上的損失，而且因?yàn)閐ither以后的數(shù)據(jù)不平滑，所以更難以壓縮，于是在進(jìn)行編碼壓縮后，平滑的8bit數(shù)據(jù)所占容量比dither的6bit數(shù)據(jù)所占容量更小。稍微要注意的一點(diǎn)是，在顯示領(lǐng)域上用的dither是時間上的變化；而在視頻、圖像領(lǐng)域上的dither是空間上的，也就是畫面內(nèi)的dither處理，放大以后就會看到類似于噪點(diǎn)的點(diǎn)狀分布?，F(xiàn)在的藍(lán)光原盤是8bit的，質(zhì)量好的原盤制作看不到banding就是因?yàn)槎秳犹幚?，同時噪點(diǎn)這種高頻信息也具有視覺效果上抑制banding產(chǎn)生的作用。但無論是抖動還是噪點(diǎn)，都是十分耗費(fèi)碼率的，所以重編碼時就會有很大的問題。現(xiàn)在的10bit編碼的優(yōu)勢之一（除此之外還有其他在編碼上的優(yōu)勢），就是通過10bit編碼可以獲得平滑的色彩過渡，而最終播放時可以dither成8bit輸出給顯示器，也能獲得接近10bit的效果，由于輸出的時候并不需要壓縮，所以dither的8bit并沒有給顯示帶來影響。但是如果拿這個dither的8bit來進(jìn)行視頻編碼，如果要保留這些dither的信息，就要耗費(fèi)比10bit編碼高出50%以上的碼率，而如果不用這么高的碼率，dither信息會有所丟失，于是色彩過渡就變得不平滑了。片源為Clannad-AfterStory~NCOP的第0幀到第299幀，最后我用3種不同的CRF值及mbtree,其他所有參數(shù)都固定，分別用8bit和10bit壓制，獲得了6個片段，下載地址，包括了所有記錄信息的log：/file/bhu5jbti以下均使用縮略圖，要獲得完整PNG圖片請點(diǎn)擊，最佳的比較方法是下載下來然后全屏進(jìn)行比較。一、來自原盤的截圖原盤的前13秒是碼率最高的部分，也是暗場/噪點(diǎn)最多的部分，所以比較有參考價值。二、 使用CRF=16開啟mbtree8bit的log：x264[info]:SSIMMeanY:0.9879862(19.203db)x264[info]:encoded300frames,1.49fps,10841.03kb/sx264[info]:frameI:4AvgQP:12.68size:170163x264[info]:frameP:70 AvgQP:18.35size:82105x264[info]:frameB:226AvgQP:20.25size:4658110bit的log：x264[info]:SSIMMeanY:0.9891903(19.662db)x264[info]:encoded300frames,1.05fps,10247.70kb/sx264[info]:frameI:4AvgQP:28.91size:146955x264[info]:frameP:70AvgQP:30.35size:76692x264[info]:frameB:226AvgQP:32.31size:44562三、 使用CRF=16關(guān)閉mbtree8bit的log：x264[info]:SSIMMeanY:0.9904566(20.203db)x264[info]:encoded300frames,1.10fps,16238.86kb/sx264[info]:frameI:4AvgQP:11.55size:196421x264[info]:frameP:71AvgQP:13.52size:115905x264[info]:frameB:225AvgQP:16.98size:7281310bit的log：x264[info]:SSIMMeanY:0.9914928(20.702db)x264[info]:encoded300frames,0.79fps,15401.50kb/sx264[info]:frameI:4AvgQP:23.74size:197882x264[info]:frameP:70AvgQP:25.75size:109516x264[info]:frameB:226AvgQP:29.19size:69161四、使用CRF=18關(guān)閉mbtree8bit的log：x264[info]:SSIMMeanY:0.9875204（19.038db）x264[info]:encoded300frames,1.35fps,10924.29kb/sx264[info]:frameI:4AvgQP:12.45size:187823x264[info]:frameP:71 AvgQP:15.62size:81799x264[info]:frameB:225AvgQP:19.29size:4678410bit的log：x264[info]:SSIMMeanY:0.9887816（19.501db）x264[info]:encoded300frames,0.96fps,10382.31kb/sx264[info]:frameI:4AvgQP:24.94size:188878x264[info]:frameP:70 AvgQP:27.96size:76864x264[info]:frameB:226AvgQP:31.37size:44698結(jié)論：要展現(xiàn)10bit壓制在畫質(zhì)和壓縮率上的雙重優(yōu)勢，可以將BD的截圖（所在時間段碼率為33Mbps）、CRF16關(guān)閉mbtree時8bit的截圖（13Mbps）、CRF18關(guān)閉mbtree時10bit的截圖（5Mbps），放在一起對比，很明顯的是有損編碼后的結(jié)果10bit更加接近原盤，而視頻里這1秒中10bit的碼率只有8bit的5/13。當(dāng)然，這也是在這種暗場+色彩過渡畫面情況下的結(jié)論，這也正是10bit優(yōu)勢很大的一塊，在一般情況的畫面上不會有這么巨大的差距，但是25%的壓縮率優(yōu)勢是''保底〃的。mbtree的碼率控制我算是體會到了，在相同CRF的情況下，開啟mbtree能讓最終碼率降低三分之一?？此坪芎玫靥岣吡藟嚎s率，CRF18關(guān)閉mbtree，和CRF16開啟mbtree，平均碼率是差不多的。但是我查看其碼率的分布時，發(fā)現(xiàn)CRF16開啟mbtree在暗場的時間段（也就是我截圖的部分）只分配了2100-2500kbps的碼率。CRF18關(guān)閉mbtree在同一時間段則分配了5000-6000kbps。于是可以看出，mbtree給這種看似比較簡單的場景分配的碼率更少，而給高動態(tài)場景分配的碼率更多。直接導(dǎo)致在這種暗場碼率明顯分配不足，所以很多壓制現(xiàn)在都不使用mbtree，它帶來的劣勢可能比優(yōu)勢更多。而在這種碼率分配不足的情況下，8bit壓制產(chǎn)生了明顯的banding（色彩平滑過渡區(qū)域由于可用顏色不足產(chǎn)生的色帶），而10bit由于其64-940的取值范圍，在這種低碼率高量化的前提下就能保持一個平滑的色彩過渡。所以開啟mbtree的截圖中對比那么明顯，就可以看成是碼率較低的情況下10bit相對8bit的畫質(zhì)優(yōu)勢（在截圖的那一段中碼率分配較少）。但即使是CRF16關(guān)閉mbtree，有著16Mbps的平均碼率，這段暗場的碼率分配也給了12-13Mbps，也能明顯看出10bit編碼的結(jié)果有著更平滑的色彩過渡，而量化造成的畫面改變也比8bit編碼的結(jié)果要?。▽Ρ仍P的截圖），在許多細(xì)節(jié)區(qū)域，明顯10bit編碼的結(jié)果與原盤更為接近。從上面提供的log里的x264info可以看出：相同參數(shù)下，10bit編碼的最終平均碼率始終比8bit要小一點(diǎn)，而SSIM值（與源的一種相似度算法）比8bit更高，主觀畫面質(zhì)量通過上面的截圖對比也已經(jīng)很明顯了。10bit的編碼速度也比8bit要慢大約28%。同時也能看到，相同參數(shù)下，10bit編碼后幀的平均QP（量化值）比8bit的結(jié)果高大約12,這也是很正常的結(jié)果，在10bit下QP值就是要高出這么多。5.至于為什么原盤也是8bit，卻沒有明顯的banding，可以通過截圖看出來，有一些類似噪點(diǎn)和抖動的結(jié)果，在AVS后處理中，加噪點(diǎn)和抖動處理都可以一定程度上地去掉banding（主要是視覺效果上，Luma的取值范圍16-235依舊沒變）。而原盤由于有較高的碼率，較小的量化，所以它可以容納下這些噪點(diǎn)和抖動，從而沒有顯示出明顯的bandingo而重編碼的過程，首先就是碼率肯定比原盤低，不然就失去了其意義，如果我用CRF12開啟mbtree，用8bit也可以壓制出和原盤十分接近的畫面，但是碼率則是從原盤的33.5Mbps降到了23.1Mbps，這已經(jīng)失去了重編碼的價值了。所以當(dāng)我要控制重編碼的碼率在合理的范圍內(nèi)，也就意味著有一定程度的量化，量化后的結(jié)果導(dǎo)致原盤中的這些噪點(diǎn)抖動沒有保持下來，于是在8bit壓制下banding就出現(xiàn)了，而10bit下由于其大生的精度高的優(yōu)勢，即便使用比8bit更高的量化，依然能獲得很好的還原質(zhì)量。6,我這里所說的也只是展現(xiàn)了10bit壓制一方面的優(yōu)勢，另外在量化方面的優(yōu)勢并沒有明顯體現(xiàn)出來，或者說截圖對比起來沒有banding的視覺區(qū)別明顯。但通過多次對比我可以肯定的是，相同碼率下10bit在細(xì)節(jié)方面的還原也是比8bit好的。7,但是也并非是所有的碼率下10bit都能獲得優(yōu)勢，假如是毫無量化的無損壓縮（qp=0），10bit只是比8bit占更多空間而已，沒有任何其他區(qū)別（因?yàn)楝F(xiàn)在都是8bit的片源），不過又有誰會去用視頻的無損壓縮呢？10bit的優(yōu)勢也是體現(xiàn)在量化上更高精度換來的更高壓縮率。而我也嘗試開啟mbtree，指定4000kbps的平均碼率用2pass去壓這個1080p的片段，于是在這段暗場只分配到了600kbps的碼率，在如此低的碼率下，8bit的畫面已經(jīng)相當(dāng)糟糕，而10bit的畫面比8bit更糟糕?？梢钥闯?，10bit在有損編碼上的優(yōu)勢也是有限度有范圍的，如果你用極端的碼率去編碼，那10bit便不能體現(xiàn)出其優(yōu)勢。所以在我們正常使用的碼率范圍內(nèi)，10bit也正是發(fā)揮其優(yōu)勢最大的地方，這也是為什么我們要普及10bit壓制的原因。引用一段ssnake蛇大的話：/bbs/thread-28754-1-1.htmlFANSUB到底是生產(chǎn)環(huán)境還是測試環(huán)境呢？我也不知道。反正在K-ON!上我是真的被問煩了，或許我一開始就應(yīng)該按生產(chǎn)環(huán)境的標(biāo)準(zhǔn)做，即只用完全成熟的技術(shù)（比如srt字幕、2.33版VSFilter支持的assspec），實(shí)現(xiàn)不好的功能統(tǒng)統(tǒng)