头像
翡璃月
帖子: 79
注册时间: 2010-11-11 23:36
来自: 台灣宜蘭
联系: 网站

Re: x265 測試

似乎是更動了WPP的模式
才變成這樣
但他們只有2路CPU
所以沒發現在4路CPU上會有溢位這種問題
MCW的陳敏說了 写了:看樣子隻能在RelWithDebInfo糢式下檢查,這種現象大多齣現在asm code有bug的時候,但是我記得妳說--cpuid 1也有錯。
我明天前往MCW India office,到那裏我編譯個版本給您測試吧
图片
头像
翡璃月
帖子: 79
注册时间: 2010-11-11 23:36
来自: 台灣宜蘭
联系: 网站

Re: x265 測試

與 MultiCoreWave 的陳敏測試 crash 的相關問題
图片
头像
翡璃月
帖子: 79
注册时间: 2010-11-11 23:36
来自: 台灣宜蘭
联系: 网站

Re: x265 測試

呵呵,沒事,稍后我看看能不能讓公司找個環境調試吧。現在看起來問題集中在多處理器繫統
在 2014-01-09 23:15:07,"Wei Lun Jhang" <hiritsuki@gmail.com> 写道:
抱歉晚了點 因為剛重灌好
防火牆還沒改 遠端進不去
隔天早上又遇上開會


chen <############> 於 2014年1月9日 下午11:13 寫道:
我這邊也接到幾個報告,看樣子還是要找個機器調試看看
在 2014-01-09 23:01:25,"Wei Lun Jhang" <hiritsuki@gmail.com> 写道:
不行 一樣crash了


chen <############> 於 2014年1月8日 下午3:35 寫道:
這兩天檢查暸代碼,隻髮現插值部分有少許問題,另外就是讀越界,不知道有沒有脩正您那邊的crash
图片
头像
tnti
帖子: 46
注册时间: 2011-12-06 22:52

Re: x265 測試

你要把出BUG的位置定位之后才好修复
现在应该没事了...
我觉得一般底片都太清晰,生活不是如此的,我不喜欢那种清晰度,我总试着模糊些。
概念都是正确的废话
头像
翡璃月
帖子: 79
注册时间: 2010-11-11 23:36
来自: 台灣宜蘭
联系: 网站

Re: x265 測試

已經修正了喔
確定是wavefront的問題
只是我這邊就不發出來了
畢竟E5 4路的人不多
图片
头像
tnti
帖子: 46
注册时间: 2011-12-06 22:52

Re: x265 測試

Wavefront Parallel Processing 波前并行处理
(英文什么的我才不知道 好孩子不要COPY这个翻译... {:cat_2} 我记得某人写的X265帮助文档的翻译里没写这个的)
我觉得一般底片都太清晰,生活不是如此的,我不喜欢那种清晰度,我总试着模糊些。
概念都是正确的废话
头像
upyzl
帖子: 446
注册时间: 2010-12-25 18:44
来自: 湘/京
联系: 网站

Re: x265 測試

蛋疼简单跑了下不同编译器对当前x265的影响
作为测试不够严谨,仅作参考(纯粹是做项目累了玩玩的)

测试源WA2 Vol1 00005.m2ts
基于x265-0.8+95 64bit 8bpp
参数:crf 19

gcc4.8.2(-march=corei7-avx)及vc12(/arch:AVX)
x265_0.8+95_vc12-VS-gcc4.8.2.PNG
0.6的时候似乎vc编译的要明显快于gcc,不过现在已经看不到区别了

icl 14.0.2(default: /arch:SSE2)
x265_0.8+95_icl14.0.2.PNG
icl 14.0.2(/O3 /QxSSSE3)
x265_0.8+95_icl14.0.2_O3_QxSSSE3.PNG
icl如果在编译时用上SSE4.1或以上指令集优化的会导致类似下图的像是UV信息丢失的明显色块问题(码率只有2166kb/s,跟前边这几个2208 2209有明显差别了)
t.png
不知道是icl优化过头了还是目前的x265开发没有考虑到这些造成的……(即使没看到那种色块,icl编译的x265编码的视频在码率上也不像vc和gcc的那么一致
头像
翡璃月
帖子: 79
注册时间: 2010-11-11 23:36
来自: 台灣宜蘭
联系: 网站

Re: x265 測試

icl本身的問題吧..
目前還是以vc為主比較好些
图片
头像
upyzl
帖子: 446
注册时间: 2010-12-25 18:44
来自: 湘/京
联系: 网站

Re: x265 測試

继续分享参考数值...跑了不同preset
因为至今仍未引入psy等专门针对主观画质优化的特性,就用ssim测好了

CPU: i7-2670QM

input:
[syntax lang="avisynth"]dgsourceim(00005.dgi, engine=1)[/syntax]

0.8+147 64bit 8bpp
参数:--bitrate 2000 -t ssim --ssim --psnr 及不同的-p
(PSNR是顺便开的,其实这里没啥用)

代码: 全选

Preset	   kb/s	   SSIM	     1/(1-SSIM)	SSIM(dB)	fps	 time(s)	 PSNR
ultrafast	1974.67	0.9877241	81.46042245	19.109 	8.23	265.31	  48.419 
superfast	1984.19	0.9890614	91.41937725	19.610 	5.64	387.05	  49.112 
veryfast	 1975.76	0.9882289	84.95382759	19.292 	5.58	391.56	  48.650 
faster	   1970.92	0.9890528	91.34755919	19.607 	5.79	377.28	  49.200 
fast	     1974.23	0.9895858	96.02273818	19.824 	4.77	457.87	  49.556 
medium	   1974.25	0.9896604	96.71554025	19.855 	3.06	713.68	  49.603 
slow	     1967.12	0.9898459	98.48238643	19.934 	1.64	1328.12	 49.819 
slower	   1963.03	0.9903474	103.5990303	20.154 	0.45	4886.97	 50.086 
veryslow	 1963.58	0.9903875	104.0312094	20.172 	0.29	7538.94	 50.085 
placebo	  1961.21	0.9904317	104.5117733	20.192 	0.16	13578.47	50.143 
相对直观的折线图
1.png
所有数据(cmd截图):
x265_0.8+147_preset_simpleResult.7z
(148.75 KiB) 下载 242 次
感觉这数据没什么参考价值,等x265更稳定(测试方面主要是增加了2pass更好)吧
翡璃月 写了:icl本身的問題吧..
目前還是以vc為主比較好些
最近才知道MCW里的x265开发者大都使用vc,难怪...

[04.03]不重要的更新,就不额外回了:
x265 vs x264 在较低码率水平下
http://pan.baidu.com/s/1c0b3lrM#dir/pat ... 2014.04.03
主要是之前看到有人提到x265在这种情况下还不如x264,也许是过了一段时间了,较低码率下看来x265是明显优于x264了(不过暂需要无视速度)
头像
upyzl
帖子: 446
注册时间: 2010-12-25 18:44
来自: 湘/京
联系: 网站

Re: x265 測試

简单试了一下 同源 近似码率(低码&crf) 近似压制时间 的对比

编码器:
x264 r2431 tmod 420p8 & 420p10 64bit
x265 1.0+5 自编译p8 & p10 64bit 下载; 如想自行测试但CPU不支持AVX且不会/不想自行编译x265可至chromashift x265.ru x265.eu等地下载;另外如果用icl编译版出现明显blocking最好用vc编译版重压看看)

片源及输入方式上贴说明了

参数:
x264-8
--crf 29 --preset placebo --merange 32 --qcomp 0.5 --rc-lookahead 96 --aq-mode 2 --aq-strength 1.2 --deblock 6:6 --psy-rd 0:0 --keyint 300 --min-keyint 1

x264-10
--crf 28.7 --preset placebo --merange 32 --qcomp 0.5 --rc-lookahead 96 --aq-mode 2 --aq-strength 1.2 --deblock 6:6 --psy-rd 0:0 --keyint 300 --min-keyint 1 --subme 10 --ref 12

x265-8
--crf 25.7 -p veryslow --rd 4 -I 300 -i 1

x265-10
--crf 34 -p slower --rd 4 -I 300 -i 1

编码后实际码率及时间:

代码: 全选

x264-8     954.56kbps    39m33s (0.92fps)
x264-10    943.16kbps    31m37s (1.15fps)
x265-8     941.71kbps    37m11s (0.98fps)
x265-10    954.31kbps    39m27s (0.92fps)
源、压制后视频及其log均可在这里下载

个人观感结论:x265-8 > x265-10 ≈ x264-10 > x264-8 (主要关注点在blocking程度、blurring程度、线条保真情况——这种码率下在这样的片源类型下更容易关注这些方面了;不过区别并没有想象中的那么大)
图就没什么好截的了,直接看视频更好

注1:精力有限,只测了一组,所以至多只能说明在当前阶段下类似类型的视频在低码的情况
注2:测试应该说依然不是足够科学;虽然x264方面参数有较大的针对性优化,不过x264的preset从medium开始到placebo是以越来越不可接受的速度损失换取越来越小的压缩率提升;不过反正对不少ripper来说还是更看重压缩率的,那么还是以偏慢的为基准好了
注3:本来速度测试数据是需要多次重复测试得出的,不过由于本次测试每跑一次时间都超过30分钟了,即使跑多次理论上也不会有较大差异

回到 “视频编码器 / Video encoder discussion”