『漫游』酷论坛>『影音数码技术学习交流』>[请教]x264的threads相关 ..
[请教]x264的threads相关问题
upyzl@2010-11-04 11:28
目前我就知道threads越大，质量会有非常微小的损失
那，如果是用--sliced-threads，会不会换回质量损失？
（不知道lower-efficiency是不是只是指压制速度慢）
手动指定较小的threads是不是也有降低延迟的效果？
因为压的东西帧数不多，基本5000以内，且用的是i5 650这个2C4H的CPU，同时经常需要把视频发布到网上，故问一下:)
zys4416@2010-11-04 18:48
同问……
我也是服务器压片的，8核心-threads 0会上到12线程
手动设置-threads参数可避免质量下降？
服务器嘛，几个批处理并行慢慢压都是可以的……
mickoo@2010-11-04 20:22
什么服务器这么牛的？
roozhou@2010-11-04 21:33
用--sliced-threads会有更大的质量损失
chopper@2010-11-04 21:48
threads
Default: auto (frame based threads: 1.5 * logical processors, rounded down; slice based threads: 1 * logical processors)
Enables parallel encoding by using more than 1 thread to increase speed on multi-core systems. The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16). The speed gain should be slightly less than linear until you start using more than 1 thread per 40px of vertical video, at which point the gain from additional threads sharply decreases.
x264 currently has an internal limit on the number of threads set at 128, realistically you should never set it this high.
Recommendation: Default
See also: thread-input, sliced-threads
[edit] sliced-threads
Default: off
Enables slice-based threading. This threading method produces worse results than the default method both compression and efficiency-wise, but adds no encoding latency.
The maximum number of sliced threads is MIN( (height+15)/16 / 4, 128 )
Recommendation: Default (off), unless you are doing some sort of realtime streaming or low latency is important.
threads增大会带来编码速度的上升 但质量的损失可以忽略不及(除非16线程以上)
用sliced-threads可以降低延时的 但sliced-threads好像是处理实时视频流编码的 压缩和效率上都不如默认的好 传网上的话效果只能自己试试了
手动调低threads的效果就不清楚了
MeteorRain@2010-11-05 02:28
所谓的质量损失，大概也就是原本1000kbps能解决的视频现在需要1005kbps了的那种程度吧
roozhou@2010-11-05 09:46
引用
最初由 MeteorRain 发布
所谓的质量损失，大概也就是原本1000kbps能解决的视频现在需要1005kbps了的那种程度吧
很多的高参数的效果还没有0.5%呢
upyzl@2010-11-05 13:03
感谢大家的回复
觉得就按direct264的默认线程设置即可，相比6损失的速度可以接受
x265@2011-06-20 15:15
意思是说
我用6核的amd压不如用双核的压的质量？
参数都一样的情况下
以后都是多核心的时代了
2013年intel的haswell都是8核往上
upyzl@2011-06-20 22:51
引用
引用第8楼x265于2011-06-20 15:15发表的 :
意思是说
我用6核的amd压不如用双核的压的质量？
参数都一样的情况下
以后都是多核心的时代了
2013年intel的haswell都是8核往上
这是我之前的测试数据，只代表部分，不代表所有
CPU: i5 650 (2C4T)
x264: r1937 (x264.nl编译版)
参数：--crf 22 --preset fast --tune animation --no-psy
测试用的视频分辨率640x480
结果：
MeteorRain@2011-06-21 03:51
引用
引用第8楼x265于2011-06-20 15:15发表的 :
意思是说
我用6核的amd压不如用双核的压的质量？
参数都一样的情况下
以后都是多核心的时代了
2013年intel的haswell都是8核往上
1、是比双核差
2、反正质量差别你肉眼看不出
3、用多核压相对省电
4、好深的坟
米牛牛@2013-10-12 01:01
這裡是最新git下載的x264源碼裡關於多線程性能指標的文檔：
。。。
Benchmarks:
cpu: 8core Nehalem (2x E5520) 2.27GHz, hyperthreading disabled
kernel: linux 2.6.34.7, 64-bit
x264: r1732 b20059aa
input: http_media_xiph_org/video/derf/y4m/1080p/park_joy_1080p.y4m
NOTE: the "thread count" listed below does not count the lookahead thread, only encoding threads. This is why for "veryfast", the speedup for 2 and 3 threads exceeds the logical limit.
threads speedup psnr
slice frame slice frame
x264 --preset veryfast --tune psnr --crf 30
1: 1.00x 1.00x +0.000 +0.000
2: 1.41x 2.29x -0.005 -0.002
3: 1.70x 3.65x -0.035 +0.000
4: 1.96x 3.97x -0.029 -0.001
5: 2.10x 3.98x -0.047 -0.002
6: 2.29x 3.97x -0.060 +0.001
7: 2.36x 3.98x -0.057 -0.001
8: 2.43x 3.98x -0.067 -0.001
9: 3.96x +0.000
10: 3.99x +0.000
11: 4.00x +0.001
12: 4.00x +0.001
x264 --preset medium --tune psnr --crf 30
1: 1.00x 1.00x +0.000 +0.000
2: 1.54x 1.59x -0.002 -0.003
3: 2.01x 2.81x -0.005 +0.000
4: 2.51x 3.11x -0.009 +0.000
5: 2.89x 4.20x -0.012 -0.000
6: 3.27x 4.50x -0.016 -0.000
7: 3.58x 5.45x -0.019 -0.002
8: 3.79x 5.76x -0.015 -0.002
9: 6.49x -0.000
10: 6.64x -0.000
11: 6.94x +0.000
12: 6.96x +0.000
x264 --preset slower --tune psnr --crf 30
1: 1.00x 1.00x +0.000 +0.000
2: 1.54x 1.83x +0.000 +0.002
3: 1.98x 2.21x -0.006 +0.002
4: 2.50x 2.61x -0.011 +0.002
5: 2.93x 3.94x -0.018 +0.003
6: 3.45x 4.19x -0.024 +0.001
7: 3.84x 4.52x -0.028 -0.001
8: 4.13x 5.04x -0.026 -0.001
9: 6.15x +0.001
10: 6.24x +0.001
11: 6.55x -0.001
12: 6.89x -0.001
。。。
| TOP