premiere对于可变帧率视频的适应性2021-10-14

premiere可以编辑可变帧率视频吗,当然是可以的,而且pr可以识别到,当你导入一个可变帧率视频的时候右击属性可以看到帧率那里写着可变帧率视频,不过这样做并不能代表pr能把这个事情做的很好,就有如你在导入素材的时候左下角有个序列的复选框但pr对序列的支持并不好一样。

事情的起因是我录制了一批教程,录制的软件是bandicam,默认打开软件的时候我只设置了录制格式这些,并没有关注到可变帧率这个选项,全部录完之后发现视频文件是真的小,这也是bandicam最开始吸引我的原因,录制的画面清晰同时文件还很小。

可是事情就是这样变大的,当时导入PR进行编辑的时候就发现pr对内存的占用直线飙升,我家里电脑的内存是32G,对于一个200M的视频编辑来说应该是小菜一碟才对,为什么内存占用这么高?当时由于急着做完没有想太多,只觉得电脑已经廉颇老矣需要升级到64G内存了,可越到后面就发现不对劲了,ME竟然无法输出!渲染失败的提示是无法创建缓冲区,这很显然就是内存不够的原因,我关掉PR,坐在电脑面前看着ME渲染,发现ME在渲染的时候内存占用直线飙升,不单单是我的32G物理内存,就连虚拟内存也被占了个精光,当全部的56G内存都被占满时ME此时还没有渲染结束,但随之而来的就是渲染失败的一个羊叫声(为什么是羊叫?),随后我渲染了更多其他分集的视频教程,发现如果在内存占满之前渲染能够结束的话渲染是可以成功的,如果在渲染结束之前内存就已经全部占满则会渲染失败!

对于这个问题我进行了很多的尝试,试着重新解释素材,试着对内容进行精简,试着把渲染程序从显卡改成CPU,但都无济于事,前面所提到的现象是依旧存在的。当时有一集教程死活渲染不出来,因为太长了(15分钟),我后面想的办法是把这个视频切成2段输出,诶,别说,还真管用,好了!

但这不是个长久之计,我并不认可这个解决办法,由于我之前录了大概20集,也不想重新再录一遍,就只能硬着头皮考虑怎么把这些视频弄完,后面录的时候再从根源上解决问题。

对于这个问题,我来做一个总述:非常卡电脑,使用PR打开编辑时内存会缓慢增加,且不会减少,会持续占满你的内存直至报错,如果你在剪辑该视频时缩放时间线会发现内存在以肉眼可见的速度增长,对视频做的任何效果都会导致内存占用增加,无论如何都是只吃不吐,内存占用绝不下降,如果强行坚持运行软件会导致电脑极度崩溃,现象是桌面卡顿,任务栏卡顿,操作无响应,关闭其他软件,内存报错等等!如果是渲染的话(包括自带渲染和ME渲染)速度会很慢,一段5分钟的录屏需要至少10分钟的时间来渲染,一个录屏没有添加任何效果仅剪辑就要这么久是完全不合理的。渲染时电脑硬件占用情况是CPU出70%的力,GPU出30%的力,显卡显存占用率极低,内存占用随时间缓慢增加直至物理内存和虚拟内存全部占满然后渲染就会失败,如果在占满之前可以渲染结束那么本次渲染是可以成功的,如果你添加了一堆渲染序列那么失败之后后续的任务会直接失败(也就是你可以不停的听到羊叫),ME在渲染时所占用的内存不会退出,只要你不关闭软件那么软件对内存的占用便会一直存在。同理,如果你渲染了3个很短的可变帧率视频的序列,那么这3次渲染所占用的内存是会叠加的,如果你只渲染1个ME会吃掉10G内存,渲染3个就会吃掉30G,如果到了第三个内存在99%的时候不足了一样会渲染失败;在PR进行可变帧率视频剪辑时内存会缓慢增加,内存占满时继续编辑电脑便会出现各种因为内存占满而出现的现象,此时必须关闭软件重新开机才会退出内存,所以如果你有很多可变帧率的视频需要剪辑的话,你需要剪几分钟就退出一下。但是这里需要注意的是,如果你在PR打开了一个可变帧率视频的剪辑序列,但此时你没有任何动作让软件挂机,那么内存占用是不会有增加的!

好,接下来说下我尝试的解决办法,一开始我是把稍微长的视频切成两段,渲染完成之后再合并起来,这样输出是可以的,但很麻烦直接弃用寻找他法,后面在一筹莫展的时候我发现了华点“2个视频拼接起来的时候渲染速度是很快的!”,也就是说,这个视频经过ME编码之后再次渲染是很快的,接下来我开始把之前录制的视频源文件丢到ME里面直接转码,转了2个比较短的视频进行测试发现确实转码之后的视频在PR和ME里面都一切正常,甚至在ME输出的时候仅用了13秒!!!那这问题就有眉目了,我开始试着把这些视频挨个重新编码,但问题又出现了,那些比较大的视频转码还是会存在对内存占用爆满导致渲染失败的情况····此时问题陷入了僵局,即使是那些能成功转码的视频我也得守着软件,渲染成功一个就关闭软件重新打开继续下一个渲染,为了赶进度我通宵守着电脑渲染,但即使如此,那些太长的视频该怎么解决始终没想到。

通宵守着转码很无聊,一个8分钟的视频转码要16分钟左右,我开始趁着闲暇时间去泡茶,顺带把茶盘茶具这些东西好好清洗一下,人生苦短何必为难自己,半夜赶工泡点红茶喝一下,但又觉得人生太苦不喝苦一点都对不起现在的自己,于是放下了红茶打开了普洱,泡茶的时候青柑普洱的皮我没有丢掉,这样泡出来的茶贼鸡儿苦,喝了第一杯之后觉得真TND苦啊,一声叹息放下了茶杯,想了想,不行,我的苦日子应该要比这个茶更苦,于是又倒了一杯,这一杯喝下去我感觉天灵盖都被这个青柑醒了一下,有了一些嫌弃的感觉,这是真的太苦了,完全受不了,为什么要买这样的茶,后来想了一下,把茶壶里面的青柑丢掉吧,再苦下去人都没了。

此时我突然又想到一个华点,在使用ME渲染的时候不论是否使用显卡加速最终渲染时CPU都占7成甚至10成,显卡不仅GPU没动连显存都没动,这是不是意味着显卡压根就没参与到这里面来,于是我又尝试着把渲染设置里的帧采样改为光流法(为了补帧),但实际结果还是和之前一样,因为内存爆满而渲染失败。

这时的焦点就比较明晰了,明明能使用显卡加速为什么ME渲染的时候显卡却在摸鱼,为什么ME无法调用GPU加速,为什么ME无法调用显存参与,为什么内存会递增爆满,为什么内存占用不会退只会涨。。。。此时我终于醒悟了一件事情,有没有可能是PR对这个可变帧率不支持(或者说支持没那么好)而导致的这些问题呢,我想到了在之前的使用中达芬奇在渲染时渲染效率远远高于ME和PR,光想没用,咱还得干!一想到这里我就垂死病中惊坐起,导了3个可变帧率视频到达芬奇里面试着交付转码,第一次,输出格式我设置的MOV无损,一段8分钟的可变帧率2K视频录制出来是100多M,达芬奇渲染出来快9个G,这TND哪里行,照这么渲染我那么多视频不得转出1个T来!第二次我试了MOV非无损,渲染出来600M作用,这依然不是我想要的,还是太大了,第三次我试着使用H265编码(始终是25帧输出),渲染出来的文件不足400M在三百多的样子,这样下来我还是勉强能接受的,用播放器打开一看画质是很不错的,基本上和原版看不出来有什么差别(录屏的视频画面本来就比较简单),于是便开始了我的大批量渲染之路。

使用达芬奇大批量渲染时需要注意的问题是渲染输出的路径和文件名的问题,尤其是文件名,达芬奇的输出预设是包含文件名的,且你在导出新项目的时候这个文件名他不会更新,你改了保存路径你不改名字他还是之前那个名字,所以我约莫20个视频就得挨个手动改,我的命名规则是在原视频的文件名后面加个A,然后达芬奇在渲染的时候软件是不能操作的,我只得把文件挨个添加到队列之后统一渲染,达芬奇会估算一个渲染时间告诉你还剩多久时间,我当时体验来看这个估算的时间还是很准的,同时我发现了一个现象,可变帧率的每个视频他显示的帧率都不一样,有20帧的,有10帧的,帧越少软件输出的就越慢,这让我想起来为什么ME渲染时间和视频时长不一致的原因了。与此同时我打开任务管理器发现达芬奇对电脑的占用并不高,很低!!低到CPU,显卡,内存的占用都没超过30%,此时我打开了PR,把渲染完成的视频替换到原序列中,然后在此进行输出,此时的整个流程就非常的顺畅丝滑,PR也不会持续吃内存了,ME也不会持续吃内存了,ME的输出也变快了,之前要10分钟的现在45秒就搞定了,此时我同时打开了PS,ME,PR,达芬奇,还使用达芬奇和ME进行同时输出,电脑竟然完全正常,内存占用也非常低,这么多软件加起来也就只在18G左右浮动,就算会超20G过一会也会下来(主要是ME渲染结束时会返还内存),在ME渲染转码后的序列时我看到了ME对GPU的占用开始百分百了,十几个序列丢到ME里面去渲染轻松的一批,我的5800X和3070TI在32G内存的基础上可以愉快的工作了,自此这个问题确认得到解决。

事后我开始追究这个可变帧率的问题,我发现在bandicam的帧率那里点开有个帧率设置,他默认就是可变帧率第二个才是恒定帧率,但恒定帧率那里他又写了个首推(可选是推荐,恒定是首推,但如果性能不足软件会自动跳回可变那个选项),我在想这软件的汉化人员是不是脑子坏掉了,这让人怎么明白呢,于是我开始做了一系列测试,此时我直说测试结果:同样的格式下录制30秒,如果恒定帧率录制出来的文件体积是6.8MB的话那可变帧率就是3.87MB,可变帧率经测试最低是4帧;画面中只有2个小秒表在动,其他地方全静止,鼠标静止;如果是在动的复杂画面,可变与恒定的文件体积差距和最开始静止测试的比例是大概一致的;重点要提出的是,使用H264 NVIDIA录制的视频比HEVC NVIDIA格式录制出来的视频要更加的小,如果是以最初的静止测试作为参照的话,恒定帧率的 HEVC NVIDIA文件体积是6.8,那么恒定帧率的H264 NIVIDIA的文件体积是4.8M左右;经过多次对比观察,发现H264 NVIDIA在画面的某些区域(大块)的细节稍微模糊,与HEVC NVIDIA相比后者在这些地方更加清晰一些;经过ME转码实测,以上所有格式里面可变帧率的视频转码是最快的,30秒的视频只用了4秒,而剩下的所有的渲染时间都是12秒(有1个是13秒可能是误差)。

所以结论就是,如果你的电脑内存在64G或128G甚至256G的时候,使用HEVC NVIDIA的编码加上可变帧率视频渲染速度是最快的,我在渲染时发现最开始渲染的时候ME跑的贼快,只是后面越来越慢直至渲染失败,想来就是内存不够的锅。如果电脑的内存和我一样在32G的,在录制的时候可以选择HEVC NIDIA的恒定帧率。如果你的内存在32G以下,或者从节约角度出发考虑要省一点硬盘空间的话可以考虑H264 NVIDIA编码,在bandicam的格式选项里有一个H264 CPU的选项,经过实测我的5800X在录制时CPU占用会从2%升到9%,如果你的电脑支持你闲置这部分能力的话可以选择,否则当你在做高强度CPU操作时录屏渲染会掉帧甚至停止。

premiere不是不能编辑可变帧率,只是对这块领域Adobe采用了比较粗暴的做法,直接通过内存占用来解决问题,这当然不是个好现象,尤其是占用了还无法吐出来;在可以选择的情况下尽可能录制恒定帧率的视频,因为这样可以在后面省很多事情,恒定帧率的视频也大不了多少,总比你折腾一趟来的好的多;如果你确实已经录制完毕了而且录制时间还比较长,有可能会吃满你的内存或者你已经试过了内存已经被爆了,那么此时你只能选择使用达芬奇进行转码,转码时帧率选择25即可;

最后需要说明的是,转码之后的文件在PR中直接替换不会有任何问题,也不会出现音画不同步的问题,一个简单的替换操作再输出到ME再用ME进行渲染,整个操作下来连渲染时间一起算也不超过1分钟,行云流水一气呵成!所以猜想PR在缩放时间线的时候应该是在疯狂的补帧临时存在内存里的,希望这个问题不要持续太久,对这个可变帧率的视频以后能有更好的处理方式。


到这里文章就全部结束了,希望我的经历能给你带来更好的启示,如果能帮到你那就更好了,如果有任何的疑问也欢迎留言,最后我的摄见未来摄影后期技术交流群欢迎各位小伙伴的加入啊,大家一起快乐的上班摸鱼岂不美哉!93877916

你可能感兴趣的:(premiere对于可变帧率视频的适应性2021-10-14)