level 5
hayu187
楼主
用一台双路e5服务器测试x265发现cpu利用率在1300%左右（一共32个线程，满负荷运行的话应该是3200%），即使调高参数--frame-threads 也只能偶尔到峰值2000%。
在阅读了x265的说明文档后貌似找到了答案：
x264默认的CTU size是64x64的，我压制的视频是1080p，裁边后实际高度是804，这样WPP steams 只有,804/64取整的13，这个13正好和cpu的利用率吻合。但实际上我进一步发现，在进程数为32时默认的frame-threads为6，也就是说有6帧是在同时编码的，6x13远远大于32，但是cpu利用率还是不满。
继续读说明文档，然来还存在block的问题。每一个WPP steams的编码过程不是独立的，相互之间还存在参考的问题，所以可能存在等待的问题。而实际上我的一个实验也证明，在设置--frame-threads 为1的时候cpu利用率只有900%而非1300%。
那么我得出的结论就是编码1080p的视频，使用一个16线程的机器就够了，fullsize的1080p 1080/64取整为17
通过加大--frame-threads数来提高cpu使用率是不科学的，壹是本来就有block的问题，F数提升对cpu使用率提升效果不明显，且是越到后面越不明显。贰是过大的F数可能导致内存溢出问题。
要使32线程完全利用起来，看来要么等以后4k普及，要么同时压两部片，还要注意内存。
2014年07月25日 12点07分
1
在阅读了x265的说明文档后貌似找到了答案：
x264默认的CTU size是64x64的，我压制的视频是1080p，裁边后实际高度是804，这样WPP steams 只有,804/64取整的13，这个13正好和cpu的利用率吻合。但实际上我进一步发现，在进程数为32时默认的frame-threads为6，也就是说有6帧是在同时编码的，6x13远远大于32，但是cpu利用率还是不满。
继续读说明文档，然来还存在block的问题。每一个WPP steams的编码过程不是独立的，相互之间还存在参考的问题，所以可能存在等待的问题。而实际上我的一个实验也证明，在设置--frame-threads 为1的时候cpu利用率只有900%而非1300%。
那么我得出的结论就是编码1080p的视频，使用一个16线程的机器就够了，fullsize的1080p 1080/64取整为17
通过加大--frame-threads数来提高cpu使用率是不科学的，壹是本来就有block的问题，F数提升对cpu使用率提升效果不明显，且是越到后面越不明显。贰是过大的F数可能导致内存溢出问题。
要使32线程完全利用起来，看来要么等以后4k普及，要么同时压两部片，还要注意内存。
