10bit压制入门教程：deband、dither和x264编码

[zhongpang]

说到444，也请教个问题
同样的8bit rgb片源
在avs转成10bit yv12 交给x264 10bit 420输出
和在avs转成10bit yv24 交给 10bit x264输出
crf 一样（用的15），
其他参数除了output csp外，都是一样的
结果444码率还比420小10%
按照无压缩yuv来说，444应该比420多出1倍数据才对，即使经过预测、有损压缩也应该没有理由比420还小吧
难道片源太特殊了？明天换其他片源和无损压缩再试试

[upyzl]

说到444，也请教个问题
同样的8bit rgb片源
在avs转成10bit yv12 交给x264 10bit 420输出
和在avs转成10bit yv24 交给 10bit x264输出
crf 一样（用的15），
其他参数除了output csp外，都是一样的
结果444码率还比420小10%
按照无压缩yuv来说，444应该比420多出1倍数据才对，即使经过预测、有损压缩也应该没有理由比420还小吧
难道片源太特殊了？明天换其他片源和无损压缩再试试

没看懂你的描述……
是这样的过程么
1. 8bit RGB(Source) -> 10bit YUV 420(AVS) -> 10bit YUV 420(x264) -- A
2. 8bit RGB(Source) -> 10bit YUV 444(AVS) -> 10bit YUV 444(x264) -- B
B比A小10%

不过即使都是相同crf15也不能说明问题吧，网络烂开不了D9，可以去D9搜下x264开发者是怎么对crf定义的
要这么比较也许应该用qp或者控制到相同SSIM（？）

[zhongpang]

过程是
8bit rgb导入到avs，在avs里round－＞16bit yv24－round－＞10bit yv24

另外一个就多了在16bit yv24用bicubic downsampling 转到 yv12

然后交给x264

crf我觉得是恒定的视觉质量来为每帧动态分配qp（不过这个视觉质量依据是什么就不得而知了，等考完试去doom9看看）

细节较少的帧，可以用粗量化（高qp）
细节较多的帧，可以用细量化（低qp）

对于同样的帧，yv24的细节比yv12多些，所以i，p，b帧平均qp应该都比yv12高些，所以体积应该比yv12大些

如果用固定qp，那么yv24应该会比yv12大（还没试过），但视觉质量又不一样了

或许可以指定码率2pass，然后再比较ssim？
但是这样比较是压出来的420和源420比
压出来的444和源444比，这样做是否还有意义？
另外请教下如何用固定的ssim压？qp0除外

[mawen1250]

x264默认时，420下chroma-qp-offset=-2，444下chroma-qp-offset=4，chroma-qp-offset就是chroma相对luma的qp的增大值。
也就是说默认下，420编码时chroma分辨率只有luma的1/4，通过qp减小2来实现更好的质量；444编码时由于chroma平面和luma平面分辨率一样，所以chroma的qp增大4来降低一些质量并减小耗费的码率。这可能是为什么相同crf下444还会更小的原因。
至于要比较ssim/psnr的话，那我觉得是要把编码后的视频再转换成8bit RGB然后和source对比比较合适，直接用x264里的ssim肯定是不行的，对比的源都不一样。但问题就在于转换成RGB的方式最好能接近madVR的效果，还有我不知道RGB下有什么工具能对比SSIM/PSNR。

[06_taro]

前面的錯誤太多不知道怎麼吐槽了…
簡單找一個的話

444应该比420多出1倍数据才对，即使经过预测、有损压缩也应该没有理由比420还小吧

當然我可以回『10bit应该比8bit多出25%的数据才对，即使经过预测、有损压缩也应该没有理由比8bit还小吧』之類的…
不過問題的關鍵不在這裡
8bit rgb->16bit yuv444就當作用了Dither工具
後面的round具體是怎麼做的，沒有給出腳本，畢竟8bit rgb->16bit yuv444這個過程的round應該不是用我之前給的腳本，實時上這個過程avs內目前應該都是mt_lut默認的float->int的round
出yv12時是先轉yv24再轉yv12，為什麼要二次轉換而不是一步到位，沒有給出理由
avs內rgb->yuv444和rgb->yuv444->yuv420的結果本身不相同，所以x264的輸入源不相同，對比輸入源不相同的編碼結果很奇怪
不過內容的同crf不代表質量相同，crf是constant rate factor，不是constant quality，很多人以為crf相同時出來的質量相同，但是crf下受aq、mbtree、psy的影響非常大，源不同的話沒有參考意義
yv24比yv12細節更多，這又是一個沒有什麼根據的說法。yv24和yv12全是rgb轉換後出來的，如果8bit rgb到10bit yuv420的轉換有比較大的損失，那麼8bit rgb到10bit yuv444相比之下應該可以保留更多的細節。但是10bit的yuv420從數據量的角度上已經幾乎能保留全部的8bit rgb內容，yv24多出的數據到底是細節還是冗餘很值得懷疑。就好比輸入的是8bit的視頻，我shift到10bit數據量不會有任何變化，兩位lsb都是0，如果不壓縮的數據總量就說10bit比這個轉換前的8bit細節更多顯然是無稽之談。如果10bit yuv444多出的部分是冗餘的話，這種冗餘是order形式適合編碼（但是數據內容也許是不必要的冗餘甚至是錯誤的插補，反正不管哪一種都會影響到播放時渲染端轉換rgb的質量，因為前期的chroma upsampling目前看來似乎沒有比渲染端madVR做得更好的）還是不適合編碼的，沒有考慮進去
mawen上面提到的chroma-qp-offset確實也是測試結果的一個可能的原因。不過需要稍微更正一下，420下默認的chroma-qp-offset不是-2，444下也不是4。chroma-qp-offset的默認始終是0。但是這個offset根據psy-rd的設置會進行補償，隨著psy-rd/trellis的提高，chroma-qp-offset會逐步降低（是在設置的基礎上降低，譬如不設置時在默認的0的基礎上降低，設置時在設置值的基礎上降低），然後444下會對這個經過psy-rd補償後的chroma-qp-offset再加6，所以最終x264用的chroma-qp-offset是經過這一系列補償後的值。另外444下chroma計算ac energy的時候也有些影響，目前看來似乎444下ac energy的計算比較奇怪（也許是錯誤的），可能會導致aq與mbtree受影響。而且444出來時有不少人做過測試，有時候444比420出來的碼率更低，有時候則更高，想嚴謹地測試的話首先要考慮質量，其次還要大量的sample，光憑一個視頻的結果沒有說服力。D9上有個很微妙的測試裡umh+merange=9比除了merange=32之外的任何值的SSIM都要高，但是如果因此就說merange=9比12、16、24、48、64都好則顯然無法接受
還有一點，x264的版本也是有影響的。vanilla版的沒有加入skip depth filter的patch，10bit yuv的輸入會先upscale到16bit，再dither回10bit…

avs內Compare(a, b)可以得到PSNR，記得RGB是可用的
LZ想比較420和444的質量與編碼效率的話，x264內--tune psnr，然後取最開始的rgb與編碼完成後的yuv420/444轉換得到的rgb之間的psnr，繪出兩條psnr/bitrate曲線，看曲線就能比較了。當然這樣還是不能保證幾個過程中的chroma up/down-sampling沒問題。我個人認為這種沒有任何保障的chroma up/down-sampling能不做就盡量別做

[zhongpang]

您说的一次到位是什么意思？
Dither_convert_rgb_to_yuv(lsb=true,output="YV24")和
Dither_convert_rgb_to_yuv(lsb=true,output="YV12")
前者是经过RGB转YUV得到444数据
后者不是在得到444数据后再进行抽样得到420吗？

脚本是

代码： 全选

Dither_convert_rgb_to_yuv(lsb=true,output="YV24")
Dither_lut16("x 64 /", u=3, v=3)
Dither_lut16("x 6 <<", u=3, v=3)
f3kdb(Y=0,Cb=0,Cr=0,grainY=0,grainC=0,keep_tv_range=true,dither_algo=1,input_mode=1,input_depth=16,output_mode=2,output_depth=10)

10bit的yuv420從數據量的角度上已經幾乎能保留全部的8bit rgb內容

我不明白，一般图像，经过抽样后损失的色度数据，难道可以通过插补100%还原？
如果可以，那么说原来444的比420多出来的数据都是冗余的我不反对
经过验证，
用10bit 444压出来的视频，经过madVR渲染，从16bit round到8bit RGB，和源RGB对比，100%没有损失
用10bit 420压，和源对比，有损失