mawen1250 - 2011/8/29 23:59:00
之前我也发了贴说明10bit压制的优势以及播放方法，也提供了一些自压的10bit视频供测试：http://www.keyfc.net/bbs/showtopic-47312.aspx
当然光提供10bit视频的确很难让人信服其优势，于是我今天就做了个8bit与10bit编码的对比测试。
对10bit压制感兴趣的可以使用这个：http://u.115.com/file/clfqqg99
应该很容易就能学会的。
压制方法：
使用06_taro的x264编译版：http://www.nmm-hd.org/newbbs/viewtopic.php?f=8&t=219
SAP的EP x264压制脚本：http://www.nmm-hd.org/newbbs/viewtopic.php?f=8&t=168
前者就是带patch以及位深转换修复的x264编译版。后者是个方便的脚本，可以实现1st pass使用指定的CRF（固定质量模式，数值越低质量越好）编码，然后2nd pass使用1st pass判定出来的码率进行编码。所以下文所说的CRF指的都是1st pass使用的，实际上还是2pass（二次编码）模式。
片源为Clannad ~After Story~ NCOP的第0帧到第299帧，最后我用3种不同的CRF值及mbtree，其他所有参数都固定，分别用8bit和10bit压制，获得了6个片段，下载地址，包括了所有记录信息的log：
http://u.115.com/file/bhu5jbti
以下均使用缩略图，要获得完整PNG图片请点击，最佳的比较方法是下载下来然后全屏进行比较。
一、来自原盘的截图
原盘的前13秒是码率最高的部分，也是暗场/噪点最多的部分，所以比较有参考价值。
二、使用CRF=16 开启mbtree
8bit的log：
x264 [info]: SSIM Mean Y:0.9879862 (19.203db)
x264 [info]: encoded 300 frames, 1.49 fps, 10841.03 kb/s
x264 [info]: frame I:4 Avg QP:12.68 size:170163
x264 [info]: frame P:70 Avg QP:18.35 size: 82105
x264 [info]: frame B:226 Avg QP:20.25 size: 46581
10bit的log：
x264 [info]: SSIM Mean Y:0.9891903 (19.662db)
x264 [info]: encoded 300 frames, 1.05 fps, 10247.70 kb/s
x264 [info]: frame I:4 Avg QP:28.91 size:146955
x264 [info]: frame P:70 Avg QP:30.35 size: 76692
x264 [info]: frame B:226 Avg QP:32.31 size: 44562
8bit截图
10bit截图
三、使用CRF=16 关闭mbtree
8bit的log：
x264 [info]: SSIM Mean Y:0.9904566 (20.203db)
x264 [info]: encoded 300 frames, 1.10 fps, 16238.86 kb/s
x264 [info]: frame I:4 Avg QP:11.55 size:196421
x264 [info]: frame P:71 Avg QP:13.52 size:115905
x264 [info]: frame B:225 Avg QP:16.98 size: 72813
10bit的log：
x264 [info]: SSIM Mean Y:0.9914928 (20.702db)
x264 [info]: encoded 300 frames, 0.79 fps, 15401.50 kb/s
x264 [info]: frame I:4 Avg QP:23.74 size:197882
x264 [info]: frame P:70 Avg QP:25.75 size:109516
x264 [info]: frame B:226 Avg QP:29.19 size: 69161
8bit截图
10bit截图
四、使用CRF=18 关闭mbtree
8bit的log：
x264 [info]: SSIM Mean Y:0.9875204 (19.038db)
x264 [info]: encoded 300 frames, 1.35 fps, 10924.29 kb/s
x264 [info]: frame I:4 Avg QP:12.45 size:187823
x264 [info]: frame P:71 Avg QP:15.62 size: 81799
x264 [info]: frame B:225 Avg QP:19.29 size: 46784
10bit的log：
x264 [info]: SSIM Mean Y:0.9887816 (19.501db)
x264 [info]: encoded 300 frames, 0.96 fps, 10382.31 kb/s
x264 [info]: frame I:4 Avg QP:24.94 size:188878
x264 [info]: frame P:70 Avg QP:27.96 size: 76864
x264 [info]: frame B:226 Avg QP:31.37 size: 44698
8bit截图
10bit截图
结论：
1.要展现10bit压制在画质和压缩率上的双重优势，可以将BD的截图（所在时间段码率为33Mbps）、CRF16关闭mbtree时8bit的截图（13Mbps）、CRF18关闭mbtree时10bit的截图（5Mbps），放在一起对比，很明显的是有损编码后的结果10bit更加接近原盘，而视频里这1秒中10bit的码率只有8bit的5/13。
当然，这也是在这种暗场+色彩过渡画面情况下的结论，这也正是10bit优势很大的一块，在一般情况的画面上不会有这么巨大的差距，但是25%的压缩率优势是“保底”的。
2.mbtree的码率控制我算是体会到了，在相同CRF的情况下，开启mbtree能让最终码率降低三分之一。看似很好地提高了压缩率，CRF18关闭mbtree，和CRF16开启mbtree，平均码率是差不多的。
但是我查看其码率的分布时，发现CRF16开启mbtree在暗场的时间段（也就是我截图的部分）只分配了2100-2500kbps的码率。CRF18关闭mbtree在同一时间段则分配了5000-6000kbps。
于是可以看出，mbtree给这种看似比较简单的场景分配的码率更少，而给高动态场景分配的码率更多。直接导致在这种暗场码率明显分配不足，所以很多压制现在都不使用mbtree，它带来的劣势可能比优势更多。
而在这种码率分配不足的情况下，8bit压制产生了明显的banding（色彩平滑过渡区域由于可用颜色不足产生的色带），而10bit由于其64-940的取值范围，在这种低码率高量化的前提下就能保持一个平滑的色彩过渡。
所以开启mbtree的截图中对比那么明显，就可以看成是码率较低的情况下10bit相对8bit的画质优势（在截图的那一段中码率分配较少）。
3.但即使是CRF16关闭mbtree，有着16Mbps的平均码率，这段暗场的码率分配也给了12-13Mbps，也能明显看出10bit编码的结果有着更平滑的色彩过渡，而量化造成的画面改变也比8bit编码的结果要小（对比原盘的截图），在许多细节区域，明显10bit编码的结果与原盘更为接近。
4.从上面提供的log里的x264 info可以看出：
相同参数下，10bit编码的最终平均码率始终比8bit要小一点，而SSIM值（与源的一种相似度算法）比8bit更高，主观画面质量通过上面的截图对比也已经很明显了。10bit的编码速度也比8bit要慢大约28%。
同时也能看到，相同参数下，10bit编码后帧的平均QP（量化值）比8bit的结果高大约12，这也是很正常的结果，在10bit下QP值就是要高出这么多。
5.至于为什么原盘也是8bit，却没有明显的banding，可以通过截图看出来，有一些类似噪点和抖动的结果，在AVS后处理中，加噪点和抖动处理都可以一定程度上地去掉banding（主要是视觉效果上，Luma的取值范围16-235依旧没变）。而原盘由于有较高的码率，较小的量化，所以它可以容纳下这些噪点和抖动，从而没有显示出明显的banding。
而重编码的过程，首先就是码率肯定比原盘低，不然就失去了其意义，如果我用CRF12开启mbtree，用8bit也可以压制出和原盘十分接近的画面，但是码率则是从原盘的33.5Mbps降到了23.1Mbps，这已经失去了重编码的价值了。
所以当我要控制重编码的码率在合理的范围内，也就意味着有一定程度的量化，量化后的结果导致原盘中的这些噪点抖动没有保持下来，于是在8bit压制下banding就出现了，而10bit下由于其天生的精度高的优势，即便使用比8bit更高的量化，依然能获得很好的还原质量。
6.我这里所说的也只是展现了10bit压制一方面的优势，另外在量化方面的优势并没有明显体现出来，或者说截图对比起来没有banding的视觉区别明显。但通过多次对比我可以肯定的是，相同码率下10bit在细节方面的还原也是比8bit好的。
7.但是也并非是所有的码率下10bit都能获得优势，假如是毫无量化的无损压缩（qp=0），10bit只是比8bit占更多空间而已，没有任何其他区别（因为现在都是8bit的片源），不过又有谁会去用视频的无损压缩呢？10bit的优势也是体现在量化上更高精度换来的更高压缩率。
而我也尝试开启mbtree，指定4000kbps的平均码率用2pass去压这个1080p的片段，于是在这段暗场只分配到了600kbps的码率，在如此低的码率下，8bit的画面已经相当糟糕，而10bit的画面比8bit更糟糕。可以看出，10bit在有损编码上的优势也是有限度有范围的，如果你用极端的码率去编码，那10bit便不能体现出其优势。
所以在我们正常使用的码率范围内，10bit也正是发挥其优势最大的地方，这也是为什么我们要普及10bit压制的原因。
引用一段ssnake蛇大的话：http://flsnow.net/bbs/thread-28754-1-1.html
最后2句就是K-ON！的ED歌曲最后一句，意思是：
因为我们还会进步，所以偶尔也会跑调。
当然光提供10bit视频的确很难让人信服其优势，于是我今天就做了个8bit与10bit编码的对比测试。
对10bit压制感兴趣的可以使用这个：http://u.115.com/file/clfqqg99
应该很容易就能学会的。
压制方法：
使用06_taro的x264编译版：http://www.nmm-hd.org/newbbs/viewtopic.php?f=8&t=219
SAP的EP x264压制脚本：http://www.nmm-hd.org/newbbs/viewtopic.php?f=8&t=168
前者就是带patch以及位深转换修复的x264编译版。后者是个方便的脚本，可以实现1st pass使用指定的CRF（固定质量模式，数值越低质量越好）编码，然后2nd pass使用1st pass判定出来的码率进行编码。所以下文所说的CRF指的都是1st pass使用的，实际上还是2pass（二次编码）模式。
片源为Clannad ~After Story~ NCOP的第0帧到第299帧，最后我用3种不同的CRF值及mbtree，其他所有参数都固定，分别用8bit和10bit压制，获得了6个片段，下载地址，包括了所有记录信息的log：
http://u.115.com/file/bhu5jbti
以下均使用缩略图，要获得完整PNG图片请点击，最佳的比较方法是下载下来然后全屏进行比较。
一、来自原盘的截图
原盘的前13秒是码率最高的部分，也是暗场/噪点最多的部分，所以比较有参考价值。
二、使用CRF=16 开启mbtree
8bit的log：
x264 [info]: SSIM Mean Y:0.9879862 (19.203db)
x264 [info]: encoded 300 frames, 1.49 fps, 10841.03 kb/s
x264 [info]: frame I:4 Avg QP:12.68 size:170163
x264 [info]: frame P:70 Avg QP:18.35 size: 82105
x264 [info]: frame B:226 Avg QP:20.25 size: 46581
10bit的log：
x264 [info]: SSIM Mean Y:0.9891903 (19.662db)
x264 [info]: encoded 300 frames, 1.05 fps, 10247.70 kb/s
x264 [info]: frame I:4 Avg QP:28.91 size:146955
x264 [info]: frame P:70 Avg QP:30.35 size: 76692
x264 [info]: frame B:226 Avg QP:32.31 size: 44562
8bit截图
10bit截图
三、使用CRF=16 关闭mbtree
8bit的log：
x264 [info]: SSIM Mean Y:0.9904566 (20.203db)
x264 [info]: encoded 300 frames, 1.10 fps, 16238.86 kb/s
x264 [info]: frame I:4 Avg QP:11.55 size:196421
x264 [info]: frame P:71 Avg QP:13.52 size:115905
x264 [info]: frame B:225 Avg QP:16.98 size: 72813
10bit的log：
x264 [info]: SSIM Mean Y:0.9914928 (20.702db)
x264 [info]: encoded 300 frames, 0.79 fps, 15401.50 kb/s
x264 [info]: frame I:4 Avg QP:23.74 size:197882
x264 [info]: frame P:70 Avg QP:25.75 size:109516
x264 [info]: frame B:226 Avg QP:29.19 size: 69161
8bit截图
10bit截图
四、使用CRF=18 关闭mbtree
8bit的log：
x264 [info]: SSIM Mean Y:0.9875204 (19.038db)
x264 [info]: encoded 300 frames, 1.35 fps, 10924.29 kb/s
x264 [info]: frame I:4 Avg QP:12.45 size:187823
x264 [info]: frame P:71 Avg QP:15.62 size: 81799
x264 [info]: frame B:225 Avg QP:19.29 size: 46784
10bit的log：
x264 [info]: SSIM Mean Y:0.9887816 (19.501db)
x264 [info]: encoded 300 frames, 0.96 fps, 10382.31 kb/s
x264 [info]: frame I:4 Avg QP:24.94 size:188878
x264 [info]: frame P:70 Avg QP:27.96 size: 76864
x264 [info]: frame B:226 Avg QP:31.37 size: 44698
8bit截图
10bit截图
结论：
1.要展现10bit压制在画质和压缩率上的双重优势，可以将BD的截图（所在时间段码率为33Mbps）、CRF16关闭mbtree时8bit的截图（13Mbps）、CRF18关闭mbtree时10bit的截图（5Mbps），放在一起对比，很明显的是有损编码后的结果10bit更加接近原盘，而视频里这1秒中10bit的码率只有8bit的5/13。
当然，这也是在这种暗场+色彩过渡画面情况下的结论，这也正是10bit优势很大的一块，在一般情况的画面上不会有这么巨大的差距，但是25%的压缩率优势是“保底”的。
2.mbtree的码率控制我算是体会到了，在相同CRF的情况下，开启mbtree能让最终码率降低三分之一。看似很好地提高了压缩率，CRF18关闭mbtree，和CRF16开启mbtree，平均码率是差不多的。
但是我查看其码率的分布时，发现CRF16开启mbtree在暗场的时间段（也就是我截图的部分）只分配了2100-2500kbps的码率。CRF18关闭mbtree在同一时间段则分配了5000-6000kbps。
于是可以看出，mbtree给这种看似比较简单的场景分配的码率更少，而给高动态场景分配的码率更多。直接导致在这种暗场码率明显分配不足，所以很多压制现在都不使用mbtree，它带来的劣势可能比优势更多。
而在这种码率分配不足的情况下，8bit压制产生了明显的banding（色彩平滑过渡区域由于可用颜色不足产生的色带），而10bit由于其64-940的取值范围，在这种低码率高量化的前提下就能保持一个平滑的色彩过渡。
所以开启mbtree的截图中对比那么明显，就可以看成是码率较低的情况下10bit相对8bit的画质优势（在截图的那一段中码率分配较少）。
3.但即使是CRF16关闭mbtree，有着16Mbps的平均码率，这段暗场的码率分配也给了12-13Mbps，也能明显看出10bit编码的结果有着更平滑的色彩过渡，而量化造成的画面改变也比8bit编码的结果要小（对比原盘的截图），在许多细节区域，明显10bit编码的结果与原盘更为接近。
4.从上面提供的log里的x264 info可以看出：
相同参数下，10bit编码的最终平均码率始终比8bit要小一点，而SSIM值（与源的一种相似度算法）比8bit更高，主观画面质量通过上面的截图对比也已经很明显了。10bit的编码速度也比8bit要慢大约28%。
同时也能看到，相同参数下，10bit编码后帧的平均QP（量化值）比8bit的结果高大约12，这也是很正常的结果，在10bit下QP值就是要高出这么多。
5.至于为什么原盘也是8bit，却没有明显的banding，可以通过截图看出来，有一些类似噪点和抖动的结果，在AVS后处理中，加噪点和抖动处理都可以一定程度上地去掉banding（主要是视觉效果上，Luma的取值范围16-235依旧没变）。而原盘由于有较高的码率，较小的量化，所以它可以容纳下这些噪点和抖动，从而没有显示出明显的banding。
而重编码的过程，首先就是码率肯定比原盘低，不然就失去了其意义，如果我用CRF12开启mbtree，用8bit也可以压制出和原盘十分接近的画面，但是码率则是从原盘的33.5Mbps降到了23.1Mbps，这已经失去了重编码的价值了。
所以当我要控制重编码的码率在合理的范围内，也就意味着有一定程度的量化，量化后的结果导致原盘中的这些噪点抖动没有保持下来，于是在8bit压制下banding就出现了，而10bit下由于其天生的精度高的优势，即便使用比8bit更高的量化，依然能获得很好的还原质量。
6.我这里所说的也只是展现了10bit压制一方面的优势，另外在量化方面的优势并没有明显体现出来，或者说截图对比起来没有banding的视觉区别明显。但通过多次对比我可以肯定的是，相同码率下10bit在细节方面的还原也是比8bit好的。
7.但是也并非是所有的码率下10bit都能获得优势，假如是毫无量化的无损压缩（qp=0），10bit只是比8bit占更多空间而已，没有任何其他区别（因为现在都是8bit的片源），不过又有谁会去用视频的无损压缩呢？10bit的优势也是体现在量化上更高精度换来的更高压缩率。
而我也尝试开启mbtree，指定4000kbps的平均码率用2pass去压这个1080p的片段，于是在这段暗场只分配到了600kbps的码率，在如此低的码率下，8bit的画面已经相当糟糕，而10bit的画面比8bit更糟糕。可以看出，10bit在有损编码上的优势也是有限度有范围的，如果你用极端的码率去编码，那10bit便不能体现出其优势。
所以在我们正常使用的码率范围内，10bit也正是发挥其优势最大的地方，这也是为什么我们要普及10bit压制的原因。
引用一段ssnake蛇大的话：http://flsnow.net/bbs/thread-28754-1-1.html
FANSUB到底是生产环境还是测试环境呢？我也不知道。反正在K-ON!上我是真的被问烦了，或许我一开始就应该按生产环境的标准做，即只用完全成熟的技术（比如srt字幕、2.33版VSFilter支持的ass spec），实现不好的功能统统去掉。但如果这样，测试环境又在哪里呢？在K-ON!发布时的妇联评论里，有一期我对x264项目Leader，Dark Shikari的专访。他就特别提到动漫FANSUB对新技术的执着追求，以及动漫FANSUB与Dev群体的密切联系。如果新技术没有测试的环境，那么它永远都是不成熟的“新技术”。如果连FANSUB这样没什么商业气息的领域，都要为生产环境的要求所束缚，那么，我们又如何去期待技术的进步呢？ |
最后2句就是K-ON！的ED歌曲最后一句，意思是：
因为我们还会进步，所以偶尔也会跑调。