本来想着之前琢磨出来的Compressor参数设置应该可以用上十天半个月，但是真就只用了半个月发现还是会有一些问题，所以前前后后尝试了很多很多次发现了更好的方案，在此作一个简单记录

上一篇记录：

当时注意到两件事：一是B站的音视频压缩方式蛮神秘而且挺能压的（芙莉莲的那个转载）；二是如果字幕特效比较丰富（Big Giant Circles），然后关键帧交给Compressor自动设置，虽然导出来在电脑上看没什么问题，但是B站一旦二压就糊掉了，所以把关键帧间隔缩的短一些会有效改善这种情况

于是我就想，如果以后要做一些包含丰富的字幕特效的视频，干脆直接把关键帧设成全部好了，可是很快，在做“安达与岛村 原声音乐”的时候，又发现了新的问题，全部设置成关键帧反而糊成一片

后来慢慢尝试，发现是码率给的比较低（6000 kbps），于是会很糊，如果码率给高一些会显著改善这种情况，但是问题在于，电磁力没到3级前每次投稿只能投不超过8G的文件，这种情况下还需要兼顾码率需求，感觉参数设置的自由度一下子变得很死

直到这里我都没觉得自定义的Compressor参数设置有什么问题，以及我又做了两个测试才慢慢发现不对劲的地方：一是没用Compressor去做编码导出，而是直接采用Final Cut Pro自带的一些导出配置，发现导出时间奇快无比，顺便调出活动监视器看了下如果用Compressor自定义预置，视频导出的时候GPU占用0，全靠CPU在那儿干活；但是用Final Cut Pro自带的一些导出配置GPU占用分分钟拉满，感觉这个M1有点琢磨不透......；二是我导出了一个Apple ProRes 422编码的文件，然后尝试使用B站投稿页面提供的“小丸压制工具bilibili定制版”去压，发现压出来画面效果也挺好的，并且体积也非常小

这样一想，那绝对是我自定义设置参数哪里有问题了，所以必须得找出原因在哪，不然遇事不决加码率带来的文件体积膨胀真的受不了，以及关于转码导出的视频体积和质量这方面，有几个不得不吐槽的地方：

1、其实可以把Apple ProRes编解码器称作固态硬盘不要钱编码器，比较高一些的编码规格导出视频的体积已经是用机械硬盘来存都感觉占地方的地步，配合苹果那昂贵的固态硬盘扩容定价只能说是绝了

2、详细比较几种不同规格的Apple ProRes编解码器导出的视频画质，主观感受就三类：

（1）Apple ProRes 422 Proxy，画质最烂还占地方，可能还比不过H.264或者H.265；

（2）Apple ProRes 422 LT、Apple ProRes 422、Apple ProRes 422 HQ，这三种占的空间越来越大，但是就我用一张简单背景图片生成导出视频进行测发现放大之后画面细节部分其实没什么区别的样子；

（3）Apple ProRes 4444、Apple ProRes 4444 XQ，存储空间不要钱级别，放大对比后发现确实是有细节部分画质的提升，但是很细微，画质效果接近或者等同于“未压缩 8 位 4:2:2”和“未压缩 10 位 4:2:2”（这俩未压缩编解码器导出文件的体积占用堪称硬盘是大风刮来的级别，比如投稿的安达与岛村视频，要是用未压缩10位422导出文件体积1TB...）

但是测试以上几种编解码器，和原始图片文件相比，还是都有所压缩了，以及我只是用静态的图片来测试，不知道对于那些专业设备拍摄的素材，采用不同的编解码器导出的文件质量会有什么区别

更多关于Apple ProRes的信息，也可以参考官网说明：https://support.apple.com/zh-cn/102207

3、用B站定制版小丸压制也好，或者说就是H.264/H.265吧，在色彩还原程度上好像不及Apple ProRes，Apple ProRes 422 LT及以上规格编码对于色彩的还原还是比较准确的；

4、“小丸压制工具bilibili定制版”碰到什么文件它真的都给你压，因为我导出了一个接近100G的Apple ProRes 422编码的视频文件交给它去压，结果压了几个小时它真给你压出来了同时画面效果尚可，很可惜的是似乎最多只用到8个线程，CPU占用也不吃满，核显独显它都不用，真就慢工出细活，跟M1的那什么VTDecoderXPCService很像，就用CPU在那儿慢慢磨。

如果不是要投稿Hi-Res无损音质视频文件的话，哪用的了那么多折腾，直接用Final Cut Pro的几个预设导出配置，或者用小丸什么的，都是很好的，何必为难自己呢

回到正题，后来各种尝试Compressor里的参数设置，发现可能还是“关键帧间隔”与“平均位速率”之间有某种相关性，而且注意到官方的手册里有提及“【重要事项】一旦设定数据速率，就会覆盖其他编解码器的质量属性，因为编解码器会根据其数据速率限制尽可能对文件进行压缩。”这样看来，设置全部关键帧时，最好把码率给高一些；但是遇到一些受限的应用场合时，只能自己决定几个相关的质量参数，然后把剩下的参数留给编解码器做自由分配了。而且有一个需要注意的问题是，控制视频导出质量相关的参数选的越多，导出时间越长，然而视频的可感知质量（尤其还是用于网络平台发布，另外还是主要是音乐相关的视频）是否会达到预期呢

那么综合上述种种测试及结果表现来看，首先肯定是不存在一个通用的Compressor参数设置的，只能根据需求不同去限制质量相关参数中的几个关键数值，另外上来就从0开始自定义Compressor预置而且没有丰富的经验的话绝对不是一个好办法，让人轻松的是Compressor本身就有一些内建的预置，可以根据需求去借鉴里面的参数设置再微调，以及遇到比较长的视频文件（比如1小时往上），可以先做一个短一些的测试项目去测试自定义预置转码效果的好坏

以上是一种比较常规的一次性导出视频的方式，即采用Compressor内置的或自己自定义的预置一次性导出整个包含视频轨道和音频轨道的文件，后来在我尝试去控制视频码率和可感质量的平衡并取得了比较好的成效后，就想着如果可以进一步分开控制视频和音频的码率与质量，那么就可以更加精确的控制最终文件的体积，加上Compressor确实内置了flac这种免费好用且有多种压缩级别的音频编码格式，那么就值得一试了

视频部分没有什么需要改动的地方，或者说在设置参数的的时候，只要保留视频部分就好了，当然Compressor确实提供了诸如视频直通、音频直通这样的选项，然而不知道是我操作出问题了还是软件哪儿有bug，假设选了直通，然后用flac重新压缩后的音频文件，还是按照一次性导出的思路来做，会发现转码出来的文件，它的音频规格变动了，或者说有时候变动了有时候没有变动，并不可控。这种情况反正都一次性导出了，干脆不要管音频部分的体积了，也不要用flac编码好了，直接用PCM编码，能详细设置每项参数，还省事一些

所以单独做视频和音频部分再进行合并，音频部分就简单很多，选择常用音频格式，使用flac，然后选择自己需要的通道布局、采样速率、采样大小这些，压缩等级如果是为了极致的体积缩减考虑，可以选择“高于8级（较小文件）”这一档，不过实际上5级左右的压缩等级就已经逼近压缩极限了

在合并视频轨道与音频轨道的时候，就不需要用Final Cut Pro或者Compressor来高射炮打蚊子了，直接使用QuickTime Player打开导出的视频部分文件，然后把音频文件拖动进去保存合成即可（虽然很简单，但是找到这个简单的办法也花了我不少时间...）

需要注意的是，采用一次性导出方式生成的文件，无论音频轨道时间与视频轨道时间是否一致，具体点来说就是可能视频最后几秒没有音频内容，但是有结尾片段画面这些，在投稿至B站之后，所有画面都会被保留；而使用QuickTime Player来合成两部分文件的时候，最后结尾片段画面如果没有与之对应的音轨的话，音轨结束后的视频部分好像会被B站裁切掉。（另外一个注意点是最好在全部主要画面内容结束后预留1秒左右的空间，因为B站投稿似乎默认会裁掉最后一点点视频内容）解决办法也没有那么困难，在Final Cut Pro里补一段音频然后将其静音或者直接使用空白音频，让音轨总时间长度与视频部分时间长度一致就行了，这样利用QuickTime Player合成再投稿就不会被裁切尾部内容了

下面这则投稿就是采用了分别导出视频轨道、音频轨道，然后再补齐部分音频从而与视频部分时间长度一致后合成导出再投稿的，有效缩减了视频体积：

如果采用最原始的自定义预置方案一次性导出音视频，尽管码率已有12500kbps之高，但是由于质量相关参数设置不合理，虽然最终导出文件体积接近8G（在macOS下大概为8.0~8.5G之间）然而画面部分依然时有模糊并不理想

在结合Compressor内置方案做自定义微调后改进的一次性导出文件，体积缩减至3.44G，体积显著减小，且画质提升明显

进一步优化，分别处理视频部分与音频部分再进行合成，最终用于投稿的文件体积为2.91G，相比投稿上限要求的8G，可以说是为内容制作留够了操作空间，如果未来会投稿24 bits 96 kHz这样的高规格Hi-Res无损音质视频，也会游刃有余了吧。另外最终优化的方案投稿至B站后，音视频部分的码率甚至都略微上升了一些，从码率角度来说B站并没有对投稿文件进行二压，而是很好的保留了最终导出的文件内容本身，可喜可贺

以上，希望这篇折腾了很多东西后的经验记录文章能给需要帮助的人带来一些收获