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

[wfqqsx]

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

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

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

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

[wsy2220]

放个 github 还以为是开源的呢.....

[fcicq]

1 楼 +1. 不开源也往上放, 胆子不小. 老老实实的找其他地方托管!

[raysonx]

拿 GitHub 当网盘使。
我记得这种可以举报的，回去看看。

[maxsec]

a   bu   se

[c4pt0r]

bs 这种行为

[common07]

也是 666, 拿 github 当幌子

[imcxy]

楼上一堆想太多的。

[hljjhb]

支持，反对楼上意见

[hljjhb]

tos 中似乎并没有强制要求开源发布作品

[seki]

和 x265@ultrafast 比……虽然速度很重要，但是硬盘空间也很重要不是么

[wfqqsx]

@seki 指的是压缩效率后的文件大小？还是内存占用大小？

[yangff]

= = 你们哪只眼睛看到 Github 上只能放开源项目的……

[fcicq]

@hljjhb 把大型二进制文件放 git 里面本来就不对. 而 release 功能虽然可以上传文件, 但上传的文件应当是 repo 代码的衍生品. 有合理理由上传 blob 的情况并不多, 比如 linux-firmware 等和硬件驱动相关的项目, 但 linux-firmware 的主场在 kernel.org, 是 kernel 的附属部分.

不开源的产品应当自己负担 hosting 相关费用, 如果 repo 只是放个说明或者链接可以当 pages 看待.

[sgissb1]

如果非要说有自己写的 codec ，那就请拿出诚意来。

编码器在测试的时候， x265 和金山的 265 ，参数是否有所区别。

问题 1 ： vbr?cbr?（显然视频编码很少用了 cbr ）
问题 2 ：比较时候的 gop 参数？
问题 3 ：比较时候的 fps 都多少
问题 4 ：编译参数是什么样的，有没有对特定平台做过优化？浮点和定点数支持如何？

问题 5 ：宏块支持范围
问题 6 ：预处理做了哪些？
问题 7 ： i b p 如何排列（和问题 2 部分重合）
问题 8 ：时间戳精度如何？（如果在 codec 之后做了时间戳计算或打时间戳）

问题 9 ：码率控制如何？（ x265 代码我没看过，但很多编码器支持码率控制）
问题 10 ：压缩比的比较？（请尽可能在相同压缩参数下比较一下，如有不同请说明哪些不同）

问题 11 ：最大支持分辨率？（请比较 x265 和金山 x265 ）
问题 12 ：压缩时内存占用比较？（请尽可能在相同压缩参数下比较一下，如有不同请说明哪些不同）

问题 13 ：两个 codec 解码性能比较如何？
问题 14 ：什么样的硬件平台上比较？有没有用到 cpu 某些特定的指令集之类，两个编码器之间的指令区别！

问题 15 ：如果金山 x265 与 x265 之间的区别类似， openh264 和 x264 的区别；那请说明，不要来这么大的标题和内容。不是不相信国人做不出 codec ，而是太哗众取宠了，尽管 v 站做编解码算法的人未必很多，我也不是一个专业的人士。但请理性和科学的对待技术和知识，如果就连金山这么大的公司，也和某些大厂商一样玩虚的，那就没多少意思了。谢谢！

[hljjhb]

@fcicq

来源请求？ tos 里并没有找到明确说明。

而且按你的说法，使用 github 私有库但公开发布 release ，似乎不可以么？

[fcicq]

@hljjhb 但是用私有库外人就下载不到了啊. 再加上 github 组织现在超贵的, 按所属组织所有的, 任意私有 repo 有访问权的总人数算钱, 只能访问一个 repo 的就算.

[fcicq]

@hljjhb https://help.github.com/articles/distributing-large-binaries/

当然, "in addition to distributing source code" 只是个提示, 就有人不愿意往 repo 里放代码就只能靠道德约束.

[yangff]

https://help.github.com/articles/open-source-licensing/#what-happens-if-i-dont-choose-a-license
扣脚

[Jasmine2016]

@sgissb1 卧槽，大神！能想到这么多问题

[sgissb1]

@Jasmine2016 just new bee. 多让你的猪队友和领导坑你几次音视频卡顿，延时等问题。分分钟，你就要想办法去了解编解码器了。

我的理解是没到算法级，都不算大神。毕竟我只是一个门外汉而已，知道部分皮毛

[hljjhb]

@fcicq 可这句话说的是“一些项目除了分发代码之外还需要分发一些大文件，那么…”

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

我认为规则没有禁止的，就可行，当然最终解释权在 github 手中。

[msg7086]

@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]

@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]

@fcicq 所以说不是禁止啊，完全是合规的。
而且整个 Repo 还不到 10M ，可能还不及哪个同学的 GPages 大呢，完全不是 Large 的范畴。
我是不觉得这是个多么重要的问题。
（更何况我不觉得金山这公司会为了省几块钱去故意钻 GitHub 的空子。

[binux]

@sgissb1 程序都给你了，还要什么诚意，自己测去啊？

[seki]

@wfqqsx 编码后文件的大小。 ultrafast 的 profile 就和字面意思一样，是追求编码速度的，因此较少兼顾体积上的优化

[qw0258]

@sgissb1 专业用户，我太喜欢你的态度了。

[wfqqsx]

@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]

@sgissb1 我觉得是该这样问，金山要拿出更多的配置参数，不然在有视频处理技术人的眼里觉的这是在耍猴。

[mko0okmko0]

@wfqqsx 所以你是金山人员?
其他建议:
不知道你们比对画质的指标是? PSNR?SSIM?其他混合变种?新研究自创?
我在别的地方有讨论过画质指标对编码结果的画质 /体积影响.
以通用指标来比较性能与品质能够给大家一个快速的理解与感受.
但通用指标很多人都知道太过数学,不够贴近人眼感知.
建议你们内部可以研究更好的比较指标来优化你们的编码结果.
然后像 Netflix 一样独立发表这个指标系统
你们可以搜寻 Netflix 的一篇文章 "The Netflix Tech Blog Toward A Practical Perceptual Video Quality Metric"
其实更好画质比对系统可以直接提升旧有的编码器工作的成品表现.虽然在传统指标上的数字会降低,但用户觉得好才是真正好.
共勉之

[sgissb1]

@wfqqsx 内行人看门道，外行人看热闹。我不是内行人，不过能够在发帖之后马上补上测试对比的 excel ，给个赞。
openh264 其实也是一大堆中国人写的。

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

至少， cbr 和 vbr 这点信息很关键

[chinue]

作为商业公司要对这个开源，的确不太可能。挂测试程序，以及看回帖的内容诚意还是蛮足了

[wfqqsx]

@mko0okmko0
为了避免主客观质量评价的行业争论，我们直接使用的是 JCTVC ，通用测试条件中的 BDRate-YUV 函数计算 anchor 和 test 之间的码率节省。 BDRate-{YUV 函数的输入是 anchor 和 test 各四组共八个 {Bitrate ， PSNR-YUV} 对，输出的百分比结果可以认为是相同质量下的码率节省。

业界和学术界通用的对比指标我们会一直沿用，同时后续也会添加好的主观评价。谢谢分享~

[wfqqsx]

@chinue 对于程序员来说，也是希望能够通过开源的方式来促进整个 H.265 生态的发展。但是作为一个商业公司，咱们还是要看公司布局的考虑哈。

[wfqqsx]

补充说明一下哈 ，命令行写错了， x265 单线程配置为 --frame-threads 1 --no-wpp; 满线程为去掉上述选项，使用默认配置； ks265 单线程为--threads 1, 满线程为--threads 0 。 有测试程序，欢迎验证~

[Niphor]

金山家连软件弄个介绍页都不高兴了么
我觉得 github 只放个 readme,binary 放 release 都比 直接放 binary 好...

[darkphoton]

还没有具体跑程序测试，只是看了一下 excel 文件，感觉这么大的提升不是仅仅在参数上做点文章能够做到的。金山肯定还是花了真功夫在做编码器的。
不过好奇为什么关闭了 x265 的 AQ ，这个在多数情况下还是能改善质量的。