金山云 H.265 编码器 Github 开放测试程序下载

2016-06-15 19:28:10 +08:00
 wfqqsx

近日,国内知名云服务公司金山云在 Github 上上传了报告以及开放测试程序。测试结果如表所示,金山云的 KSC265 编码器相比于 X265@ultrafast 可以实现超过 50%的加速和超过 30%的码率节省。这就是说, KSC265 可以在接近 X264@veryfast 的编码速度时还能在相同质量下节省一半码率。

测试报告完全使用了 H.265 标准制定时所使用的测试集和测试方法

欢迎各位大拿们下载 测试程序进行评估! 下载地址: https://github.com/ksvc/ks265codec

http://i.imgur.com/6n37uR8.png

10400 次点击
所在节点    云计算
37 条回复
hljjhb
2016-06-16 00:21:55 +08:00
@fcicq 可这句话说的是“一些项目除了分发代码之外还需要分发一些大文件,那么…”

按我的理解,分发代码并不是分发文件的前置条件。而且这不是正式的条款= =

我认为规则没有禁止的,就可行,当然最终解释权在 github 手中。
msg7086
2016-06-16 00:26:27 +08:00
@fcicq
Distributing [[[[[large]]]]] binaries

If you need to distribute large files within your repository, we [[[[[recommend]]]]] that you create releases for your projects on GitHub.
fcicq
2016-06-16 00:49:19 +08:00
@hljjhb @msg7086 https://help.github.com/articles/what-is-my-disk-quota/
"We don't recommend distributing compiled code and pre-packaged releases within your repository."

这个表态应该够了.

当然这也不是禁止, 只是这个环境有暗含强调"合作开发"的意思, 不加开源授权协议也是允许但肯定会阻碍合作的行为. 往 git 里存 binary 基本就没法管理取 diff 了, 除非用 LFS 这样的方案分离出去.
msg7086
2016-06-16 01:12:33 +08:00
@fcicq 所以说不是禁止啊,完全是合规的。
而且整个 Repo 还不到 10M ,可能还不及哪个同学的 GPages 大呢,完全不是 Large 的范畴。
我是不觉得这是个多么重要的问题。
(更何况我不觉得金山这公司会为了省几块钱去故意钻 GitHub 的空子。
binux
2016-06-16 01:28:28 +08:00
@sgissb1 程序都给你了,还要什么诚意,自己测去啊?
seki
2016-06-16 10:28:00 +08:00
@wfqqsx 编码后文件的大小。 ultrafast 的 profile 就和字面意思一样,是追求编码速度的,因此较少兼顾体积上的优化
qw0258
2016-06-16 10:42:02 +08:00
@sgissb1 专业用户,我太喜欢你的态度了。
wfqqsx
2016-06-16 12:45:26 +08:00
@sgissb1
谢谢提问,文章作为测试程序分享,测试结果其实只是简单的和大家分享一些数据。没对具体参数进行详细说明还请见谅。

首先,简单讲一下 x264 和 x265 。目前圈内的公认, x265 的编码速度问题特别大,效率提升也没有太高。金山云算法团队是从零代码开始写了三年,其中辛苦一般人很难知道。另外 JCTVC 测试 video 已经规定了输入 yuv 的各种参数格式,大家可以参阅 HM 制定时的文档。

其次,我们也在 Github 上补充上传了详细的测试 excel (包含比对参数),具体说明如下:
x264.exe -o out.264 /home/qytest/yuvfiles/BQSquare_416x240_60.yuv --input-res 416x240 --preset [veryfast/slow/placebo] --fps [framerate] --profile high --aq-mode 0 --no-psy --psnr --bitrate [number] --keyint [framerate * 10] --frames 1000000
x265.exe -o out.265 --input /home/qytest/yuvfiles/BQSquare_416x240_60.yuv --input-res 416x240 --preset [ultrafast/slow/placebo] --fps [framerate] --aq-mode 0 --no-psy-rd --no-psy-rdoq --psnr --bitrate [number] --frame-threads 1 --keyint [framerate * 10] --frames 1000000
AppEncoder_x64.exe -b out.265 -i /home/qytest/yuvfiles/BQSquare_416x240_60.yuv -preset [veryfast/slow/veryslow] -tune offline -psnr 2 -rc 1 -br [number] -frms 1000000 -iper [framerate * 10]


对于您这提的十几个问题,还请参下:

问题 1 : vbr?cbr?(显然视频编码很少用了 cbr )
一般情况下, CBR 码率波动小,但是压缩率不如 ABR 。在比较中为了公平, X265 用默认配置 abr ,我们也是一种 ABR 的优化,这样的比较是公平的。

问题 2 :比较时候的 gop 参数?
I 帧间隔要一样才能保证公平。在 excel 中已经给了详细的参数。如果此处 gop 是指 I 帧间隔的话,那大部分测试情况是 10*fps 。

问题 3 :比较时候的 fps 都多少
JCTVC 的 yuv video 已经给出了 yuv 的 fps ,必须按照这个值进行设置。例如 BQSquare_416x240_60.yuv 的帧率就是 60

问题 4 :编译参数是什么样的,有没有对特定平台做过优化?浮点和定点数支持如何?
编译参数就是 x265 的默认配置,再说,我们跟 x265 是在相同平台下编译的,能用的汇编指令都是相同打开或关闭。

问题 5 :宏块支持范围
都是在 HEVC 标准范围内。

问题 6 :预处理做了哪些?
没做过任何预处理,直接编 YUV 以方便公平比较。

问题 7 : i b p 如何排列(和问题 2 部分重合)
X265 用默认的参数,例如 badapt 在各个档次下的打开或关闭。 ks265 的各档次默认 B 帧数量不一定与 x265 相同。具体情况可以下载测试程序自行实验。

问题 8 :时间戳精度如何?(如果在 codec 之后做了时间戳计算或打时间戳)
X265 和 ksc265 一样,都是视频编码器。时间戳的精度和修改不影响编码效率。真正商用编码器是 ffmpeg+x265 或 ksc265 。

问题 9 :码率控制如何?( x265 代码我没看过,但很多编码器支持码率控制)
Excel 中已经给出,实验结果就是码率控制下的结果。

问题 10 :压缩比的比较?(请尽可能在相同压缩参数下比较一下,如有不同请说明哪些不同)
业内的人都知道,应该用 4 个码率点的 BDRATE 函数来计算码率节省,如附件的 excel.

问题 11 :最大支持分辨率?(请比较 x265 和金山 x265 )
都跟 HM 一致。 4K 视频没有问题,更高分辨率的没有实验过。

问题 12 :压缩时内存占用比较?(请尽可能在相同压缩参数下比较一下,如有不同请说明哪些不同)
可以下载测试程序自行实验。实际内存占用应该与 x265 相当。

问题 13 :两个 codec 解码性能比较如何?
我们发布的同时包含编码器以及解码器, x265 中并没有解码器。如果要比较解码器性能可以用 openhevc 或者其他解码器。发布没有提供解码器相关测试结果。

问题 14 :什么样的硬件平台上比较?有没有用到 cpu 某些特定的指令集之类,两个编码器之间的指令区别!
我们在 excel 中给出了详细的平台信息。
本测试为 x265v1.9 版本与 QY265v2.2.0 版本离线编码对比测试,测试设备为台式机( Win7 操作系统, i5-4670 四核 CPU , 8G 内存)
指令集方面,支持到 AVX2.

问题 15 :如果金山 x265 与 x265 之间的区别类似, openh264 和 x264 的区别;那请说明,不要来这么大的标题和内容。不是不相信国人做不出 codec ,而是太哗众取宠了,尽管 v 站做编解码算法的人未必很多,我也不是一个专业的人士。但请理性和科学的对待技术和知识,如果就连金山这么大的公司,也和某些大厂商一样玩虚的,那就没多少意思了。谢谢!
openh264 面向实时视频通信,只有一个速度档次,只有 ippp ,功能只是 x264 一个非常小的子集。我们同 x264 一样,面向所有速度档次和所有应用场景。真心没玩虚的。我们是从 0 代码开始写,跟 x265 的框架基本没有关系。不过我们是商业公司,现在不到开源的时候,开放测试程序公开测试是一定程度的诚意,以上所有问题,对于专业人士来说,一测便知。只说测试结果,不开放测试程序才是真的没诚意。


最后,欢迎大家一同探讨分享。谢谢!
Orzpls
2016-06-16 12:59:03 +08:00
@sgissb1 我觉得是该这样问,金山要拿出更多的配置参数,不然在有视频处理技术人的眼里觉的这是在耍猴。
mko0okmko0
2016-06-16 13:24:31 +08:00
@wfqqsx 所以你是金山人员?
其他建议:
不知道你们比对画质的指标是? PSNR?SSIM?其他混合变种?新研究自创?
我在别的地方有讨论过画质指标对编码结果的画质 /体积影响.
以通用指标来比较性能与品质能够给大家一个快速的理解与感受.
但通用指标很多人都知道太过数学,不够贴近人眼感知.
建议你们内部可以研究更好的比较指标来优化你们的编码结果.
然后像 Netflix 一样独立发表这个指标系统
你们可以搜寻 Netflix 的一篇文章 "The Netflix Tech Blog Toward A Practical Perceptual Video Quality Metric"
其实更好画质比对系统可以直接提升旧有的编码器工作的成品表现.虽然在传统指标上的数字会降低,但用户觉得好才是真正好.
共勉之
sgissb1
2016-06-16 16:36:59 +08:00
@wfqqsx 内行人看门道,外行人看热闹。我不是内行人,不过能够在发帖之后马上补上测试对比的 excel ,给个赞。
openh264 其实也是一大堆中国人写的。

不过,有些问题,我感觉不是我没问到点子上,就是没有答到点子上,也就没有必要争论太多了。一句话,没看到源码的东西没有代码,不好讨论太多了。

至少, cbr 和 vbr 这点信息很关键
chinue
2016-06-16 18:10:05 +08:00
作为商业公司要对这个开源,的确不太可能。挂测试程序,以及看回帖的内容诚意还是蛮足了
wfqqsx
2016-06-16 18:23:42 +08:00
@mko0okmko0
为了避免主客观质量评价的行业争论,我们直接使用的是 JCTVC ,通用测试条件中的 BDRate-YUV 函数计算 anchor 和 test 之间的码率节省。 BDRate-{YUV 函数的输入是 anchor 和 test 各四组共八个 {Bitrate , PSNR-YUV} 对,输出的百分比结果可以认为是相同质量下的码率节省。

业界和学术界通用的对比指标我们会一直沿用,同时后续也会添加好的主观评价。谢谢分享~
wfqqsx
2016-06-16 18:28:37 +08:00
@chinue 对于程序员来说,也是希望能够通过开源的方式来促进整个 H.265 生态的发展。但是作为一个商业公司,咱们还是要看公司布局的考虑哈。
wfqqsx
2016-06-17 12:54:23 +08:00
补充说明一下哈 ,命令行写错了, x265 单线程配置为 --frame-threads 1 --no-wpp; 满线程为去掉上述选项,使用默认配置; ks265 单线程为--threads 1, 满线程为--threads 0 。 有测试程序,欢迎验证~
Niphor
2016-06-19 19:58:10 +08:00
金山家连软件弄个介绍页都不高兴了么
我觉得 github 只放个 readme,binary 放 release 都比 直接放 binary 好...
darkphoton
2016-07-24 22:42:20 +08:00
还没有具体跑程序测试,只是看了一下 excel 文件,感觉这么大的提升不是仅仅在参数上做点文章能够做到的。金山肯定还是花了真功夫在做编码器的。
不过好奇为什么关闭了 x265 的 AQ ,这个在多数情况下还是能改善质量的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/285998

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX