近期热门
粉丝5
关注 0
获赞 32
视频渲染及压缩方案比较

[作品交流与资讯] 视频渲染及压缩方案比较

[复制链接]
1146 1 0 1 5年前 举报
机子配置如下:
处理器:L5640*2 12c24t
内存:48g ddr3 1333
显卡:gtx960
硬盘:西数蓝盘 1t
分为两大部分:视频渲染(Adobe Premier Pro CC 2018)和视频压缩(MediaCoder)
素材是喜闻乐见的4k吃烤鸭视频(码率 60mbps)
0.jpg
1
下面我们开始第一部分。
先打开Adobe Premier Pro CC 2018 新建一个项目
然后导入素材
1.jpg
选择我们的吃烤鸭视频

2.jpg

3.jpg
可以看到这个视频原长只有42秒,我们将整段视频复制一份接在原视频后面
4.jpg
这样我们的输出视频就有1分23秒了。
我们也不做多余的剪辑,直接导出媒体。
为了保持语言视频的一致性与兼容性,导出视频均为h264标准,格式是mp4,输出分辨率设定为1920x1080。
在这一阶段,我们的选手是:
1. h264方案使用cpu渲染
2. 使用nvenc硬件加速电路配合sse2指令集使用gpu加速渲染(这个老古董cpu只有sse2了没有avx指令集)
本次测试不考虑控制输出视频码率与视频质量完全一致,只确保使用最常见最简单的输出设置
下面有请一号选手表演:
选定h264,并将分辨率变为1920x1080,其他选项不做更改
5.jpg
开始导出
大约用时1分钟
6.jpg
可以看到渲染时CPU是在满负荷运转的。
但是!
7.jpg
GPU啥事都没干,全程看戏。
下面有请二号选手:
选择nvenc(sse2)方案
将输出混流器更改为MP4并指定正确的mp4box混流器可执行程序的位置
8.jpg
将分辨率指定为1920x1080
9.jpg
然后指定neroaac解码器的可执行程序的地址即可
10.jpg
开始导出
用时大约一分钟
11.jpg
此时查看任务管理器
12.jpg
这回GPU满载了
13.jpg
在GPU干得热火朝天的同时CPU的负载也不轻,因为尽管高负荷工作交给了GPU但是整个视频的码率控制仍然是由CPU负责的。
接下来我们来看一下两位选手渲染出来的成品:
14.jpg
CPU渲染的视频大小是103MB
15.jpg
而GPU渲染出来的视频是171MiB,比CPU渲染大了一半多。
那么第一轮的结果如下:
这一轮在最简设置情况下两位选手各有千秋,cpu更小巧但是时间相对较长,gpu相对速度快但空间占用处于下风。
2

下一阶段是使用MediaCoder进行视频压缩。
也是分为cpu运算和gpu运算两部分。
下面先使用x264编码器和ffmpeg解码器对两个视频进行cpu渲染
16.jpg
结果如图
17.jpg
两个视频的压缩时长均为44秒,倍率也都只有可怜的1.95x左右,也就是60fps不到的帧速率。这个结果不怎么令我满意。
下面尝试使用nvenc搭配ffmpeg进行压缩
18.jpg
除了改动编码器为nvenc外其余设置保持默认
19.jpg
速率明显变快了,而且帧速率能达到喜人的200fps,提升显著。
MediaCoder可以使用多核心CPU进行多段同时渲染,下面我们开启分段渲染对上述两个方案再进行一次测试。
先是cpu。
分段编码设置如下
20.jpg
注意分段数量在我的机子上不能大于2,否则分段会没有效果
编码速率时快时慢,虽然最终数据和不打开分段编码时相差无几但是实际用时要稍稍快于普通解码模式,综合来看收益并不是很大。
下面测试开启分段解码技术的nvenc编码。
21.jpg
纸面速率没有明显提升但是明显提速了,峰值速率能达到10倍速。
第二部分测试总结如下:
3

我寄予厚望的分段压缩技术并没有很大的提升,这是让我有点失望的地方。
总体来看我还是选择h264渲染+nvenc压缩的方式即CPU渲染+GPU压缩。
虽然GPU渲染+GPU压缩在时间上会有优势但是GPU渲染一直以来都没有CPU渲染质量好,而且在之前的实践中发现GPU渲染+GPU压缩出来成品会有大量马赛克噪点,还是CPU渲染比较稳妥。


0
点赞
0
打赏
1
添加到收藏夹

1

点击复制链接

使用微信扫码分享
一次扣10个券
全部评论1
您需要登录后才可以回帖 登录

太屌了,虽然我根本看不懂。
5年前
回复

使用道具 举报

您当前使用的浏览器IE内核版本过低会导致网站显示错误

请使用高速内核浏览器或其他浏览器