这是一个创建于 3106 天前的主题，其中的信息可能已经有所发展或是发生改变。
近日，国内知名云服务公司金山云在 Github 上上传了报告以及开放测试程序。测试结果如表所示，金山云的 KSC265 编码器相比于 X265@ultrafast 可以实现超过 50%的加速和超过 30%的码率节省。这就是说， KSC265 可以在接近 X264@veryfast 的编码速度时还能在相同质量下节省一半码率。
测试报告完全使用了 H.265 标准制定时所使用的测试集和测试方法
欢迎各位大拿们下载 测试程序进行评估！ 下载地址： https://github.com/ksvc/ks265codec
 |
1
wsy2220 2016-06-15 20:19:27 +08:00  3
放个 github 还以为是开源的呢.....
|
 |
2
fcicq 2016-06-15 20:23:09 +08:00
1 楼 +1. 不开源也往上放, 胆子不小. 老老实实的找其他地方托管!
|
 |
3
raysonx 2016-06-15 20:27:32 +08:00 via Android
拿 GitHub 当网盘使。
我记得这种可以举报的，回去看看。 |
 |
4
maxsec 2016-06-15 20:30:48 +08:00 via iPad
a bu se
|
 |
5
c4pt0r 2016-06-15 20:52:15 +08:00
bs 这种行为
|
 |
6
common07 2016-06-15 20:59:32 +08:00
也是 666, 拿 github 当幌子
|
 |
7
imcxy 2016-06-15 21:13:05 +08:00
楼上一堆想太多的。
|
 |
8
hljjhb 2016-06-15 21:26:38 +08:00
支持，反对楼上意见
|
|
9
hljjhb 2016-06-15 21:29:00 +08:00
tos 中似乎并没有强制要求开源发布作品
|
 |
10
seki 2016-06-15 21:32:45 +08:00
和 x265@ultrafast 比……虽然速度很重要，但是硬盘空间也很重要不是么
|
 |
12
yangff 2016-06-15 21:55:44 +08:00 1
= = 你们哪只眼睛看到 Github 上只能放开源项目的……
|
|
13
fcicq 2016-06-15 22:10:52 +08:00
@hljjhb 把大型二进制文件放 git 里面本来就不对. 而 release 功能虽然可以上传文件, 但上传的文件应当是 repo 代码的衍生品. 有合理理由上传 blob 的情况并不多, 比如 linux-firmware 等和硬件驱动相关的项目, 但 linux-firmware 的主场在 kernel.org, 是 kernel 的附属部分.
不开源的产品应当自己负担 hosting 相关费用, 如果 repo 只是放个说明或者链接可以当 pages 看待. |
 |
14
sgissb1 2016-06-15 22:13:39 +08:00 4
如果非要说有自己写的 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 站做编解码算法的人未必很多，我也不是一个专业的人士。但请理性和科学的对待技术和知识，如果就连金山这么大的公司，也和某些大厂商一样玩虚的，那就没多少意思了。谢谢！ |
|
15
hljjhb 2016-06-15 22:50:45 +08:00
|
|
16
fcicq 2016-06-15 22:56:03 +08:00
@hljjhb 但是用私有库外人就下载不到了啊. 再加上 github 组织现在超贵的, 按所属组织所有的, 任意私有 repo 有访问权的总人数算钱, 只能访问一个 repo 的就算.
|
|
17
fcicq 2016-06-15 23:00:05 +08:00
@hljjhb https://help.github.com/articles/distributing-large-binaries/
当然, "in addition to distributing source code" 只是个提示, 就有人不愿意往 repo 里放代码就只能靠道德约束. |
|
18
yangff 2016-06-15 23:13:11 +08:00
|
 |
19
Jasmine2016 2016-06-15 23:36:45 +08:00 via iPhone
@sgissb1 卧槽，大神！能想到这么多问题
|
|
20
sgissb1 2016-06-15 23:54:00 +08:00
@Jasmine2016 just new bee. 多让你的猪队友和领导坑你几次音视频卡顿，延时等问题。分分钟，你就要想办法去了解编解码器了。
我的理解是没到算法级，都不算大神。毕竟我只是一个门外汉而已，知道部分皮毛 |
|
21
hljjhb 2016-06-16 00:21:55 +08:00
@fcicq 可这句话说的是“一些项目除了分发代码之外还需要分发一些大文件，那么…”
按我的理解，分发代码并不是分发文件的前置条件。而且这不是正式的条款= = 我认为规则没有禁止的，就可行，当然最终解释权在 github 手中。 |
 |
22
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. |
|
23
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 这样的方案分离出去. |
|
24
msg7086 2016-06-16 01:12:33 +08:00
@fcicq 所以说不是禁止啊，完全是合规的。
而且整个 Repo 还不到 10M ，可能还不及哪个同学的 GPages 大呢，完全不是 Large 的范畴。 我是不觉得这是个多么重要的问题。 （更何况我不觉得金山这公司会为了省几块钱去故意钻 GitHub 的空子。 |
|
26
seki 2016-06-16 10:28:00 +08:00
@wfqqsx 编码后文件的大小。 ultrafast 的 profile 就和字面意思一样，是追求编码速度的，因此较少兼顾体积上的优化
|
 |
28
wfqqsx OP @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 的框架基本没有关系。不过我们是商业公司，现在不到开源的时候，开放测试程序公开测试是一定程度的诚意，以上所有问题，对于专业人士来说，一测便知。只说测试结果，不开放测试程序才是真的没诚意。 最后，欢迎大家一同探讨分享。谢谢！ |
 |
29
Orzpls 2016-06-16 12:59:03 +08:00 via Android
@sgissb1 我觉得是该这样问，金山要拿出更多的配置参数，不然在有视频处理技术人的眼里觉的这是在耍猴。
|
 |
30
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" 其实更好画质比对系统可以直接提升旧有的编码器工作的成品表现.虽然在传统指标上的数字会降低,但用户觉得好才是真正好. 共勉之 |
|
31
sgissb1 2016-06-16 16:36:59 +08:00
@wfqqsx 内行人看门道，外行人看热闹。我不是内行人，不过能够在发帖之后马上补上测试对比的 excel ，给个赞。
openh264 其实也是一大堆中国人写的。 不过，有些问题，我感觉不是我没问到点子上，就是没有答到点子上，也就没有必要争论太多了。一句话，没看到源码的东西没有代码，不好讨论太多了。 至少， cbr 和 vbr 这点信息很关键 |
 |
32
chinue 2016-06-16 18:10:05 +08:00
作为商业公司要对这个开源，的确不太可能。挂测试程序，以及看回帖的内容诚意还是蛮足了
|
|
33
wfqqsx OP @mko0okmko0
为了避免主客观质量评价的行业争论，我们直接使用的是 JCTVC ，通用测试条件中的 BDRate-YUV 函数计算 anchor 和 test 之间的码率节省。 BDRate-{YUV 函数的输入是 anchor 和 test 各四组共八个 {Bitrate ， PSNR-YUV} 对，输出的百分比结果可以认为是相同质量下的码率节省。 业界和学术界通用的对比指标我们会一直沿用，同时后续也会添加好的主观评价。谢谢分享~ |
|
34
wfqqsx OP @chinue 对于程序员来说，也是希望能够通过开源的方式来促进整个 H.265 生态的发展。但是作为一个商业公司，咱们还是要看公司布局的考虑哈。
|
|
35
wfqqsx OP 补充说明一下哈 ，命令行写错了， x265 单线程配置为 --frame-threads 1 --no-wpp; 满线程为去掉上述选项，使用默认配置； ks265 单线程为--threads 1, 满线程为--threads 0 。 有测试程序，欢迎验证~
|
 |
36
Niphor 2016-06-19 19:58:10 +08:00
金山家连软件弄个介绍页都不高兴了么
我觉得 github 只放个 readme,binary 放 release 都比 直接放 binary 好... |
 |
37
darkphoton 2016-07-24 22:42:20 +08:00
还没有具体跑程序测试，只是看了一下 excel 文件，感觉这么大的提升不是仅仅在参数上做点文章能够做到的。金山肯定还是花了真功夫在做编码器的。
不过好奇为什么关闭了 x265 的 AQ ，这个在多数情况下还是能改善质量的。 |
Select Language