TA的每日心情 | 开心 2017-2-4 00:11 |
---|
签到天数: 4 天 [LV.2]偶尔看看I
至尊会员
   
- 积分
- 164644
|
本帖最后由 dtlnor 于 2023-4-9 17:30 编辑
你这样操作有太多槽点了
1. pr输出已经是二压了一遍的结果了,如果你只是做剪切,正常不会想要剪切这个步骤就去损伤画质。
2. pr内部处理的时候(如果你做了任何editing)会首先把视频转换到YUV444,你如果开启反交错,那就是正常反交错后拉伸到444(但你不喜欢pr的反交错),你不开启反交错,那就是以逐行方式对待反交错视频并拉伸到YUV444 (听起来就很灾难)。前者你在预览的时候看不到拉丝,后者你预览的时候能看到拉丝。
3. pr输出的时候是以yuv444的实际数据转换为目标格式的,也就是说无论如何你再输出前一刻的视频数据都会是“YUV444逐行视频”,你输出mov的时候通常是yuv422依旧保留了拉伸后的像素。更何况反交错处理不保证原始的像素不被改变,更进一步地说,正如1,你的数据反正也是被二压的。
4. 我不清楚pr有没有双倍帧率的反交错,最佳反交错操作是双倍帧率的(因为交错状态下一帧有两场,上半场跟下半场不是同一个时间点,反交错后补把半场补为完整的一帧就会变成两倍帧率,比如60i变成60p,假设我有一个24fps的交错视频(也就是48i),最佳的输出是反交错后48p视频)。但我这个版本的pr只看到保持帧率的反交错(也就是丢掉了时间尺度的信息,两个不同时间点的半场被融合到同一时间了)。当然你最后又交错输出的话就无所谓了(但你的像素也被“优化”过一遍了)
5. 多数的 tv 动漫当你看到拉丝的情况下都不是标准的交错(interlace)视频,大多数是telecine(胶卷过带)处理后的视频。或者是假的交错视频(标记为交错视频实际内容却是逐行视频)。前者你要做的是ivtc(反胶卷过带),如果你用pr先处理过再输出的话结果无疑是全错的,后者你可以以逐行模式读取然后随便你做后处理。
所以你目前实际上的行为多数是:
1. 由pr进行反交错,并拉伸到yuv444
2. 剪辑、剪裁
3. 降采样到yuv422并以交错模式输出到mov
4. 交给mediaencoder再次反交错并降采样到720p的yuv420格式的视频
你前三个步骤的操作完全可以用mediaencoder做。当你遇到奇奇怪怪的源的时候肯定不会推荐用pr作为处理的第一棒
|
|