Premiere CS4 编辑5D2 素材 解决不卡的方法
19589
90
|
[1 楼] windboyz
[资深泡菜]
09-3-16 00:33
前言：
Premiere Pro CS4编辑5D2素材的时候卡，是一个困扰全球性的问题，绝对不是机器性能问题，用我的Macbook Pro的FCP编简直就要飞:} 同一机器用Pr编，无论PC Mac都一样卡！大多数都在找其它的方法，如cineform转码，我可以用BMD的Intensity采集HDMI成M-JPEG，但这些都不理想，BMD的驱动刚更新，支持Pr401了，但是没法调用playback setting 不能忽略丢帧停止，也没法用，估计还要等新版驱动了。 看看外国朋友的方案： 原文不逐字翻译了，笔者的电脑配置绝对高，而且使用时候性能远没发挥出来，所以推测Pr的QT 的问题，于是重新打包了素材的MOV文件，变成MP4，不经过转码，结果编辑流畅了，原理是绕过QuickTime的解码器使用Pr内置的MainConcept的解码器。 具体的操作笔者还没说。明天先试试直接把后缀改成.mp4，要不就是用什么打包工具。 I've found some interesting results with Premiere CS4 I thought I would share. First, my current hardware: Core i7 920 @ 3.6 Ghz 3 GBs of DDR3-1600 8-8-8-24 RAM 10,000 RPM WD VelociRaptor system disk 2 TB RAID 10 media disk Nvidia 260 GTX 216 core Windows XP 32bit When working with untouched 5D MKII files, Premiere CS4 can't playback the files without stuttering. This happens to a lot of people and several solutions have been used (proxies, lagarith transcoding, etc). Several things bothered me about this: 1. During playback, system resources were not being taxed. CPU usage barely jumped 30%, HD transfer speeds were way below max, RAM usage average, etc. 2. Premiere CS4 is supposed to support AVCHD editing and in fact has several profiles for 1080p 30fps AVCHD editing. AVCHD is H.264, just like the 5D MKII, except it's wrapped in an MPEG2 transport stream. (I know that AVCHD is limited to 20 Mbps, but I considered this a minor issue) I began to suspect the QT interpreter that Premiere CS4 uses. In order to avoid it, I re-wrapped the raw H.264 from the .mov file of a 5D MKII in an MP4 container. No transcoding. It plays back and works perfectly. An MP4 file, with the raw H.264 from a 5D MKII, at 40 Mpbs has no problems being edited in Premiere CS4. (At least on a Core i7) This is probably because it uses the MainConcept H.264 decoder in Premiere and not the QT interpreter. There is one significant problem I've run into with this re-wrap. Premiere interfaces with QT to interpret and use the .mov files. When QT was updated, full 0-255 levels were available in Premiere, as QT presented them so. When the video is re-wrapped to MP4, Premiere once again thinks the color space is YUV (16-235) and throws away RGB levels 0-15 and 236-255. I'm strill trying to figure out the best way to deal with this. I only wish Premiere supported basic color management. |
|
[91 楼] ARRO
[泡菜]
10-1-5 22:41
哪个热心DX上传一段原始素材..俺试试
|
|
[90 楼] 台台另台另另台
[泡菜]
10-1-5 09:37
太专业了，各位老师。能不能抽时间帮我一下：我用500d拍小孩子，用AE编辑那个20fps的1080P。即使是编辑完了也很大，所以请教一下转换成什么格式（保持1920x1080）才又小又最接近原档的画质呢？是用AE直接生成出去，还是先输出MOV再用procoder转好呢？谢谢啦谢谢啦！
|
|
[89 楼] ninedays
[泡菜]
09-6-12 16:40
原文由 太阳咖啡 发表 我做了测试, 结果确实如你所说.在yc waveform 图上用lossless codec 转换后的图和原图有差别. 我想多做点研究, 看看问题出在哪? 谢谢你的帮助. |
|
[88 楼] 太阳咖啡
[泡菜]
09-6-12 14:00
谢谢两位的比较。
那好吧，8bit就8bit，我现在上载了8bit422yuv格式的avi文件，有兴趣可以下载来再比较一次，结果可能还是让你们失望。至少到目前为止我依然坚持我的观点，除非谁的比较结果和我的不相同并且发现了我的错误。我仍然认为所谓“the decompressor is bit-for-bit identical ”根本不可能，两个色彩空间的取值范围根本就不相同！ 5D2g格式的文件比较不够典型，因为镜头的关系，你拍的文件的高频频率绝没有扫频仪的高，而损失恰恰在高频。 |
|
[87 楼] ninedays
[泡菜]
09-6-12 10:35
http://compression.ru/video/codec_comparison/lossless_codecs_en.html
有兴趣可以看看这个. 最后一段提到了不同色彩空间转换时的损失: The name of this video codec category declares full quality losses absence - the decompressed video stream should be completely identical to original. Output quality is same for all codecs. Absolute absence of losses is a very strong requirement, therefore it is often hard to achieve compression ratios above 3:1. Some of the tested codecs have an opportunity of work in "lossy" mode; it allows to reach considerably higher compression degree with rather small losses of quality. However, only "fully lossless" mode is considered in the current comparison. The only parameter of comparison is the compression level. Many codecs give an opportunity to adjust the parameter speed/compression ratio; it allows to tune the codec for the specific task (real-time capture or the rendering requiring loss minimization). Only maximum compression ratio result is considered in current work. Some codecs are capable to accept input data in several color spaces (RGB, YUY2, YV12, etc.), however, compression is not always "lossless". Some codecs "silently" perform the conversion of color spaces, thus, raising a degree of compression. Quality losses coming out of such conversions are not visible, but surely exist. In the given testing work codecs is compared separately for various color spaces, thus in each color space full absence of losses is guaranteed! |
|
[86 楼] ninedays
[泡菜]
09-6-12 10:14
canopus hq和cineform 都是有损编码, 但他们支持的格式众多, 也是公认的最接近原始素材的适合后期的编码, 这也是edius和premeire 在不支持有些native编辑的格式时推荐的转码. 我没有看到adobe推荐过用mpeg i 做中间编码的流程. 当然以太阳的思路, 他采取的这种方式完全可以认为是以"offline"编辑, 然后再用源文件输出, 所以可以完全避开中间编码的损失.
所以我认为,太阳是提供了一种很好的可行的流程. 至于编码格式,我认为canopus hq和cineform 都比mpeg i 要好得多. 太阳提供的素材是10位422编码的文件, 但huffyuv 和lagrith lossless codec 都不支持10位的编码, 所以在转换时有个10bit -8bit的转换过程, 造成了高频信息的丢失. http://www.hv20.com/archive/index.php?t-2872.html 所以我还是认为太阳所说的无损编码转换依然会有损失是不准确的. 这不是编码的问题, 而是在你的流程中没有选择合适的编码所致. 回到5d2上来, 我做的比较, lossless codec does losslessly. |
|
[85 楼] 5dmark11
[泡菜]
09-6-11 23:12
huffyuv输出损失比较小
下图为huffyuv YC波形  |
|
[84 楼] 5dmark11
[泡菜]
09-6-11 22:54
下图为输出canopus-hq YC波形
有一定损失，不知哪种输出损失最小。由于对这种色深的素材不熟悉，只有PR CS4支持输出，TMPGEnc 4.0 XPress等软件根据无法转换，所以没法更深入研究。 [5dmark11 编辑于 2009-06-11 22:57]  |
|
[83 楼] 5dmark11
[泡菜]
09-6-11 22:52
PR PRO 2无法显示这个素材的波形
PR CS4 才能显示 下图为原素材YC波形  |
|
[82 楼] ninedays
[泡菜]
09-6-11 14:35
2.
 |
|
[81 楼] ninedays
[泡菜]
09-6-11 14:34
1
 |
|
[80 楼] ninedays
[泡菜]
09-6-11 14:32
很少做这样的对比, 不知道做得对不对?
素材是5d2拍摄的原始视频文件. 1. 原始视频文件, 图上标题有avs扩展名的 2. lagrith lossless codec重新编码的avi文件 竟然只支持jpg格式,连无损的png格式图片都不支持, 无忌太落后了. |
|
[79 楼] ninedays
[泡菜]
09-6-11 13:34
原文由 太阳咖啡 发表 我也想验证下, 但我打不开你提供的文件, 也不想再装quicktime 了. 我用pc机, 苹果的打包格式在pc机器上肯麻烦. 如有可能请提供原始的5d2视频文件. 你提供的文件看来是10位422文件,我猜测损失是在转成8位的resampling时产生的. 因为你也提到是"Reduced Resolution"了, 而且从原始的yuv转成了RGB, 这样肯定有损失的. |
|
[78 楼] 太阳咖啡
[泡菜]
09-6-10 18:39
原文由 ninedays 发表 好吧，如果哪位有兴趣并且有时间，可以试着用任何的lossless codec来无损的压缩或者无损转码什么的，如果最后的结果比我的这个文件小，并且在示波器里面比较是完全无损的，我就承认我错了，这个文件就是信号发生器上发的扫频信号，专门用来测量带宽和通道损失的。 因为不知道如何在这里上载附件，所以我申请了一个免费邮箱存放原始文件：[email protected] 密码是123456 原始文件在附件中。请不要用OutLook收信，会把原始文件删除的，谢谢！ 我本人在pr或者vegas中使用huffyuv和lagrith lossless codec进行编码，编成avi文件，无论使用哪种方式，在pr的示波器（注意红色方框内的勾要选中）上看都是有损的（注意各个不同颜色方框内的波形对比），文件比较也能发现损失。legarith lossless codec的Reduced Resolution方式损失最大，也许我的实验是错误的，但我不知道错在哪里，有谁发现了问题可以给我指出来。谢谢。 [太阳咖啡 编辑于 2009-06-10 18:41]  |
|
[77 楼] ninedays
[泡菜]
09-6-9 22:28
原文由 太阳咖啡 发表 |
|
[76 楼] 太阳咖啡
[泡菜]
09-6-9 15:13
原文由 windboyz 发表 小波从来都是流畅的，因为他的分辨率是可调的，升到4.1.0以后只是很多操作方便了一些，更智能了。 原文由 ninedays 发表 422转444，肯定会产生高频的色度信号衰减，这我们已经用示波器证明了，过程很繁琐，就不在这里详细说了，相信大部分人都不感兴趣。 其实这个损失很好理解，从422转到444的数据量来分析，标准的444的非压缩数据量（假设pal，8bit）是29.66MB/s，422的标准数据量是29.66*2/3=19.78MB/s，二者相差了将近10MB/s，444这多出来的数据量从哪里来的？几乎所有的软件都是通过插值得到的（计算的暴快的肯定会用“复制”，结果会更差），不管用什么算法插值，“插”进来的这些值都是虚假的，这是第一道损失，当你输出的时候，如果用444，无话可说，如果用422，那又要把数据量通过插值的办法再压回19.78MB/s，尽管你什么滤镜也没加，走过这么一圈以后新的19.78MB/s已经不是原来的19.78MB/s了，高频的色度信号已经有了损失，特高频部分的损失达到了33%！！意外吧，但这是事实，这就是二次损失。几乎所有生成无损转码的codec都隐瞒了这一点，由于损失仅仅是特高频的色度信号，所以这个损失用肉眼绝对看不出来的，也就相当于本来是一根饱和的红色的头发丝（注意，我说的是一根，不是一头秀发，只有一根根等距分离才是高频），两次转码以后，红色的头发丝不那么饱和了，仅此而已，肉眼根本无法判定。 有兴趣追根寻源的朋友可以看这篇文章http://bbs.chinadv.com/read-htm-630739.html |
|
[75 楼] windboyz
[资深泡菜]
09-6-9 13:52
我也始终支持 native edit,不过Pr升级完了达到均匀的4fps，我已经知足了。。。
另外，即使使用无损编码也有可能有损，因为要解压，解压的流程因不同的解码器不同质量是有差异的，例如H.264的解码是最复杂的，一般的解码器都会走“捷径”。当然，无压缩以后，后期的品质是有保证的，无压缩就没有解码器质量问题了。 |
|
[74 楼] ninedays
[泡菜]
09-6-9 10:52
原文由 太阳咖啡 发表 哦， 原来是这个 i frame only mpeg 。 上面写得很清楚， 这只是预览的时候生产的中间格式，便于编辑和加入滤镜后看效果。这就是这个格式的目的。 我们当然肯定会用原始文件输出。 这个帖子开始的时候是说5d2的文件导入pr不能流畅编辑， 所以当时解决方法有： 1 。 将原始文件转成高质量有损编码， 比如canopus hq ， 导入pr剪辑； 2. 转成无损的编码， 导入pr剪辑。 3， 你提供的，先剪辑一个low scale的中间素材再在标准项目上导入这个low scale的剪辑信息， 用原始的文件输出。 我认为你说的3， 类似pr里面offline edit 的概念。 1 。是adobe pr cs2 以前的官方推荐高清hdv剪辑流程。 2. 因为是无损的编码， 我也不能验证你说的“即使是无损的也是有损失”的说法， 所以这个流程就取决于个人喜好了。 3. 你一直在强调3的损失比1的损失少一点， 这一点看过这个流程的都明白。 对于1 ， adobe也承认肯定效果不如2，3 ， 它是在剪辑流程度， 占用硬盘空间大小， cpu的耗费率上这是一个优化的结果。 但现在我们知道pc上的pr不能流畅剪辑5d2的素材是软件兼容的问题。所以我们的解决方法有： 1. 升级pr 和qt ， 改善一般。 2. remux（非重新编码）成标准的mp4文件， ， 完全解决。 对我来说能native edit 就native edit 。 谢谢你的解答。 |
|
[73 楼] windboyz
[资深泡菜]
09-6-9 00:35
原文由 太阳咖啡 发表 最近Pr CS 刚升级到 4.1.0，支持RedCode，太阳可以试一下，看看小波流畅不？ http://club.chdn.tv/viewthread.php?tid=5632&extra=page%3D1 [windboyz 编辑于 2009-06-09 00:37] |
|
[72 楼] 太阳咖啡
[泡菜]
09-6-8 15:40
原文由 windboyz 发表 谢谢，的确是我没说清楚，我指的确实是全套的叠加模式，没有它，专业的调色无从谈起。 |
|
[71 楼] 太阳咖啡
[泡菜]
09-6-8 15:38
原文由 ninedays 发表 关于mpeg i，要想得到它其实很方便，首先在你的Sequence Setting中定义好（图1），当然，有时候也可以选其它的模式，如某些压缩方式的AVI，素材调入以后，通过回车键让它自己算一道，然后进入pr工程文件的目录，按照图2的方式即可找到，当然，通过export也行，但里面的设置很麻烦，mpeg i的选项很多，不熟悉的还不如像这样用默认的。 关于色彩空间的选项，我知道高清应该选709，但我的那个canopus hq codec不知为什么只有标清的601，没有709，我也很郁闷，反正我是把它关掉的。 关于有损和无损，有很多人谈损色变，那是对损失不了解，其实我们最终观看的介质无论是电影院里看数字电影还是在家看蓝光盘，都是有损的，并且损失还不小，人眼对最终输出的影片损失是极不敏感的，我们专业制作的基本原则也是尽量避免中间文件的二次损失，所以我说过，我们有自己一整套的检测损失办法，我们甚至可以仅凭提供的素材就可以精确的区分哪些是444、哪些是422和420，不是靠数据量，而是靠方法。你知道吗，422或420的素材，转成444，几乎所有的软件转换，哪怕转成无压缩，其转换过程都是有损失的，这和很多广告上面说的不一样，看你如何理解。这就是说，在你目前的方案中，即使你中间文件用了所谓高质量的canopus hq，但你的最终结果一定比我用pr的方案损失大，因为我的方案中mpeg i不参与最后的运算（条件是方法正确，再次强调），最后的运算仍然是调用最原始的mov文件。至于我们方案的中间文件的格式，我觉得无所谓，只要能看清楚、流畅并且数据量小（少占用资源），这才是最关键的。 关于Huffyuv,Lagarith的无损编码，我们以前的确不太用，因为它对于没有定格的高清晰度（不是说高清格式）广播级素材几乎没有什么用，我可以给你证明对于这类素材它几乎一个字节都无法压缩，所以我们用的很少，但每个人的工作流程不同，所选择的工具也不一样，所以Huffyuv,Lagarith对很多流程来讲肯定是有价值的。 关于场，我测试p模式的素材的时候，在pr的输入（cs 4已经可以设输入的场优先了）和输出的时候设置的都是无场，这个如果搞错了误差可就大了，说道高清的场优先，你的看法我不太赞同，我们遇到过上场优先，也遇到过下场优先，其实我们在用每段带场的素材进行制作的时候，都会检测场序，ae里面有非常简单的 测定场序的方法。  |
|
[70 楼] windboyz
[资深泡菜]
09-6-8 14:35
原文由 太阳咖啡 发表 应该说从CS4 提供了完整的层模式，之前的版本使用滤镜方式，blend很难用，还要指定轨道，不自由。Pr CS4的层模式，可以说是Pr用户最期待的了  |
|
[69 楼] 太阳咖啡
[泡菜]
09-6-8 12:57
原文由 取名真麻煩 发表 很简单，只要加一个你认为运算很快的滤镜，比如Brightness & Contrast（亮度&对比度），参数选默认，然后直接敲回车即可。 其实我们还有一个更简单也更保险的做法，可以开一个你比较习惯的工程文件，如1280*720，甚至开一个格式更低的DV 720*576的工程，把素材调进去以后选择如下图的这个选项，然后剪辑，甚至可以加过渡的特效，保证你能够实时剪辑，剪完以后的小样还可以直接刻普通DVD给客户（或朋友）审片，确认以后再New Seqence，建立你最终输出的工程（如1080p），把720里面的剪辑好的素材全选，拷贝到新工程当中，运算或者输出即可，很方便，并且保证实时剪辑。  |
|
[68 楼] 太阳咖啡
[泡菜]
09-6-8 12:32
原文由 今天就行动 发表 是吗？不好意思，也许我记错了，我很少用pr 4.0以前的版本，因为pr的能力问题，可是我在pr cs2里面无论如何也没找到象下图那样的叠加方式，能告诉我在哪里吗？至于pr早期的3.0，我想我还是熟悉的，它的那个叠加无法和现在的相比，有几个最重要的工具没有。  |
|
[67 楼] ninedays
[泡菜]
09-6-8 10:26
原文由 太阳咖啡 发表 谢谢你提供了你的建议和经验. 我没有直接用过canopus hq编码输出. 但我知道在hdv的长gop的mpeg-ts文件无法做到流畅剪辑时这是edius里标准的流程;在pr2.0以前也是先转成第三方的cineform编码. 这些编码是业界一致认为高效和最接近无损的有损编码格式. 对我来说只存在有损和无损编码. 如果我要转肯定是转成无损的, 也就是Huffyuv,Lagarith编码. 他们的1/3-/6甚至更高压缩率, 我在家用的单块sata硬盘的系统上可以跑得很流畅. 我还是不明白你说的mpeg i帧格式是什么? 我尽管知道这是帧内压缩, 但是看pr的帮助文档,也没有找到这种说明, 还有你说可以export 这种mpeg i帧的格式输出, 我也不清楚是在哪里选择做到的. 还请说明. 高清默认都是709的色彩空间, 不经转换直接用601的色彩空间显示是会造成轻微的偏色. 高清如果是隔行的话场都是上场优先. 我因为不懂你的mpeg i输出, 你的实验我无法重复验证. |
|
[66 楼] 取名真麻煩
[泡菜]
09-6-8 02:15
原文由 5dmark11 发表 首先謝謝你，我明白了，就是用較低的解析度作為中介層去edit，我開1080p的project cs不會轉換成mpgi，開720的就可以，怎樣可以去強制他去轉換呢？ |
|
[65 楼] 今天就行动
[禁言中]
09-6-7 17:52
原文由 太阳咖啡 发表 不会吧.....到cs4才出现层叠加？我记得n年前用过的pro-1.5就有层叠加了吧？至于edius，早在3.0版的时代就有层叠加了。 难道我记错了？pre一直没有层叠加？ |
|
[64 楼] 太阳咖啡
[泡菜]
09-6-7 17:27
谢谢5dmark11 的测试，也许，我对Canopus HQ的了解不够，平时用它的确很少，所以，我转的那段，也许设置不正确
如果用pr，个人建议尽快转cs4，此次cs4的改进有很多是革命性的，比如，加入了层叠加，调色方面也有改进，最重要的是改进了和ae之间的管道，可以调用ae的渲染引擎（速度较慢，但质量优）。还有，支持多核以及在64bit下支持大内存。 |
|
[63 楼] 5dmark11
[泡菜]
09-6-7 13:40
使用lelvels（单独控制）
惊其的发现，如果使用TMPGEnc 4.0 XPress输出canopus hq标准输出，输出文件大小为51.3M，比edius5 自带的HQ标准输出51.0M，相差极小，输出时间为11.8秒，转换时间缩短了35%。 TMPGEnc 4.0 XPress输出canopus hq标准与原素材对比，白输入级别：5,差异1.96% 确实可以称得上是损失极小的输出  |