压片想只用crf跑一遍以节约时间,曾经在某个地方看到有高手说过跑crf应关闭mbtree,大意是因为mbtree是2pass压法为了防止视频结尾部分码率不足所以才开的,所以crf不应该开。但是实在是记不清了,也不确定自己是不是记错了。所以向各位大大请教一下,只跑crf的话应该是开还是不开mbtree。
先谢谢大家了。
这是指--ratetol inf,和mbtree无关。2pass压法为了防止视频结尾部分码率不足所以才开的
那是不是就是也应该开mbtree呢。还是说开不开mbtree和crf或者2pass没有关系。mawen1250 写了:这是指--ratetol inf,和mbtree无关。2pass压法为了防止视频结尾部分码率不足所以才开的
多谢大大指教。mawen1250 写了:mbtree的原理可以参考这里:http://baike.baidu.com/view/3098244.html
因为被参照越多的MB(宏块)的QP越低(分配到码率越高),所以能较明显地提升压缩率,对于crf较高的情况下会有较明显的提升平均质量的效果。而你所谓的2pass实际上在分配码率时也是通过类似crf的方式来判断的,只不过多了个目标码率作为限制。
而crf较低的情况下就说不清楚了,由于mbtree对QP分配的bias作用,一些地方原本码率就较高/较低,然后进一步加强了这种分配的差别导致码率更高/更低,于是在这些原本码率较高的地方更高以后也看不出多少质量提升,而原本码率较低的地方更低以后则产生了较明显的劣化。
或者是在某些很需要码率/很容易因为压缩而导致劣化的地方(如fade场景、暗场、视觉上动态较低而对编码器而言动态较高的部分)在mbtree作用后导致码率分配过低而在视觉上产生较明显的劣化。
总结就是mbtree更注重平均压缩率、质量的提升,而no-mbtree则更容易保证整体质量的平衡(偏差较小)。
所以我一般是crf小于等于17的时候关mbtree,这时候的码率和总体质量一般来说会比crf=16开mbtree更高。
rc-lookahead开高后影响的主要是内存占用,速度影响倒不明显,而且mbtree本来其bias作用就可能导致上述问题,lookahead开高后就进一步加强了这些问题,所以--preset placebo里也只用到了60。00:13 < Dark_Shikari> we need vfr mbtree first, for anime
00:13 < Dark_Shikari> or at least time-limited mbtree
00:13 < Dark_Shikari> in the meantime just stop using rc-lookahead 250
00:20 < Mandarinka> "[23:13] <Dark_Shikari> in the meantime just stop using rc-lookahead 250" --- wait, it actually hurts? As in, the bias effect gets too strong?
00:21 < Dark_Shikari> yes, on completely static scenes, probably so
00:21 < Dark_Shikari> my plan is to implement an internal cap to how long an object can "stick around" as seen by x264
再次感谢大大,那我感觉默认建议的40-50就够用了。mawen1250 写了:rc-lookahead开高后影响的主要是内存占用,速度影响倒不明显,而且mbtree本来其bias作用就可能导致上述问题,lookahead开高后就进一步加强了这些问题,所以--preset placebo里也只用到了60。00:13 < Dark_Shikari> we need vfr mbtree first, for anime
00:13 < Dark_Shikari> or at least time-limited mbtree
00:13 < Dark_Shikari> in the meantime just stop using rc-lookahead 250
00:20 < Mandarinka> "[23:13] <Dark_Shikari> in the meantime just stop using rc-lookahead 250" --- wait, it actually hurts? As in, the bias effect gets too strong?
00:21 < Dark_Shikari> yes, on completely static scenes, probably so
00:21 < Dark_Shikari> my plan is to implement an internal cap to how long an object can "stick around" as seen by x264
aq补偿的是平面区域的码率,而mbtree则作用于MB在时域上的qp分配,两者虽然有交集但完全是两回事,在非平面区域aq就无法补偿,而在开mbtree时分配到较高码率的平面区域在aq作用下就码率更高,显得有些浪费。
mawen1250 13:25:12
对比后表示,mbtree神马的实在太危险了,码率一样的情况下好多细节都烂掉了
于是开始v10
MythCreator 13:35:37
MBTree的本意是为了提升啥?
mawen1250 13:36:19
压缩率
MythCreator 13:36:44
不过那玩意对真人片来讲更好吧
[X]orat 13:36:50
aq是拆東牆補西牆
mbtree是東牆高得沒必要,拆掉可省磚瓦費
mawen1250 13:38:19
但是就像君届那些截图里一样,对比度低的细节部分很容易在mbtree作用下分配的码率过低而产生明显的劣化
细噪点保留也不好
[X]orat 13:38:54
其實就是它覺得東牆高得沒必要不代表就真的沒必要
mawen1250 13:39:48
而重噪点的保留可能会更好
膝盖中箭的四喵 13:42:29
君届有很重的噪点么?
我咋觉得mbtree对君届的影响不会很大,而小草的会那样主要是aq呢…
[X]orat 13:45:40
其實準確地講不是噪點,而是複雜度。mbtree原理裡認為高複雜度的部分動態高,被參考的效率低,可以安全地降低質量,實際上高複雜度但是低動態(譬如texture)會很悲劇。當然還有一個考慮是高複雜度非常耗碼率,把這種碼率留給低複雜度的部分對PSNR/SSIM提高更高,不過如果本身質量就很高(crf很低)的話,低複雜度根本不需要繼續提高質量了。
[X]orat 13:47:42
反正開了mbtree的時候就去找複雜度高但是動態低的區域,一般來說肯定能找到劣化的,就看個人在不在意了……
mawen1250 13:48:40
就我的对比而言,同码率,100%下我看不出开mbtree后哪里更好了,但是更不好的地方却很明显能看到
[X]orat 13:49:07
如果對動態很低的高複雜度也不敏感的話就可以無視,不然還是得慢慢蛋疼的,譬如對高複雜度低動態區域加動態噪點強制將之變成高動態什麼的……
mawen1250 13:49:43
FZ里我都加了比较高动态的噪点了,但是还是没法避免这个问题
[X]orat 13:49:44
因為mawen一般都crf 16左右嘛,mbtree在crf 23下對整體還是有明顯改善的……
mawen1250 13:50:16
PL压的kanon也加了动态噪点,但是由于mbtree开着,那些会烂的地方照样烂
[X]orat 13:50:20
加高動態噪點不是關鍵,關鍵是加的區域必須是高複雜度低動態的。全局加的話和沒加一樣……
mawen1250 13:51:23
于是还要把mask和MC一起上来自适应加噪点么?
[X]orat 13:51:25
而且即使加了,也只是讓原來低動態的變成高動態而已。我沒做過實驗,如果mbtree對這種情況是將上面的動態部分忽略而只保留下面的靜態的話就可以達到目的,如果只是對這個區域單獨劣化的話就完全沒有用……
[X]orat 13:52:33
其實靠控制噪點來影響x264的rc仔細想想真是邪道,雖然我一直在這麼做
還不如直接用低aq來配合mbtree……
solitude 13:54:21
也可以调qcomp减少mbtree的趋势
膝盖中箭的四喵 13:54:27
=_=
[X]orat 13:55:09
但是ZNM如果aq降低了還開mbtree,flat部分又要出banding……
這不科學……
膝盖中箭的四喵 13:56:01
开mbtree,适度提升qcomp,相对高值的aq
[X]orat 13:56:02
結論就是flat不能降低質量,complex也不能降低質量,所以乾脆關了mbtree吧(死……
mawen1250 13:56:20
我已经用了qcomp=0.75了
膝盖中箭的四喵 13:56:37
0.8我都用…
[X]orat 13:56:52
8-bit下常年0.8……
高壓除外……
村汉 13:57:57
全都降低,硬盘贵呀
膝盖中箭的四喵 13:58:11
10bit后用了0.8的madoka、freezing
膝盖中箭的四喵 13:59:56
aq则适源选mode1/2 strength0.8-1.0,其实大部分都是1.0…
[X]orat 14:01:16
aq倒是根據情況0.4/0.6/0.8/1.0/1.2都用過,VAQ和OreAQ連負值都用過(不過VAQ負的話配上了HaaliAQ……
膝盖中箭的四喵 14:02:37
OreAQ必须负值啊,不然怎么看…
[X]orat 14:03:28
關鍵是也不能全負啊,直接一個-0.5也不太好,四個部分八個值還是分別設置比較好,然後就蛋疼了……
膝盖中箭的四喵 14:03:46
那是
其实OreAQ的精髓不就是这个么
[X]orat 14:05:43
參數複雜給人的發揮餘地更大,不過往往也容易把人搞懵(而且必須用一大堆複雜參數才能設置好的話說沒本身算法穩定性不夠,所以DS一直希望vanilla裡的aq模式和參數越少越好……