自己写了个码率判断脚本，压缩过程用crf模式，压缩完毕后会分类新视频，原视频，核心思想只有一条，就是在新视频不通过的时候尽可能保留原视频。
最早的时候这个机制很简单，就是单纯判断新码率是否大于码率线，但后面机制就复杂了，比如老视频如果小于新视频，但新视频的码率还低于码率线，这时候也应该不通过。
新视频可能是不完整视频需要判断，新视频的分辨率不能大于原视频，等等
之后我还引入了赦免机制，如果新视频大于原视频，但原视频已经低于码率线的0.45倍了，这时候原视频被赦免为“无需压缩的视频”，新视频被删除。
这个机制的引入让之前的情况更加复杂，我需要判断新旧视频的编码效率问题，如果原视频的编码效率大于新视频，那么更倾向于保留原视频，这就涉及到动态生成码率线了，这种动态也不完美，因为它完全基于新视频与原视频之间的编码代差

单机贴吧

我压片喜欢用稳定的码率，所以我基本不用crf。
通常，好视频我用cpu/hevc的2pass，一般视频用nvenc_hevc的P7/vbr。
我是准备自己写个gui，针对调用ffmpeg/shanaencoder进行cpu/2pass的。
1、1pass用crf，压完判断视频码率；
2、如果1pass视频码率满足要求，转码就结束。
3、如果1pass视频码率不满足要求，进入正常的2pass。
东西都准备到位了，就是现在实在没时间动手写程序了。。。
另外，扩展还想通过局部测试crf，就是通过转视频中间几分钟长度，找出码率接近目标的crf值，对了，其实crf不一定整数，小数如24.1/24.7都可以的。

shanaencoder，你就是用CPU压HEVC也是没有2pass的。NVENC的话有变通的方法，那就是Slow级别，自带2pass。强制上2pass的话只有用命令行了，或者用其他GUI。crf模式指定的数值，CPU压制可以有小数点，GPU只有整数。crf指定的数值对于编码器来说只是一个量化参考，并不是每一帧都用你给出的数值去量化，而是运动块多时自动升高量化参数，运动块少时降低量化参数，关键帧自动降低量化参数，非关键帧自动升高量化参数。你设的这个值只是一个升高或者降低时，所依据的基础值。所以用crf，不同的视频，相同的量化参数和时长分辨率等，出来的大小可能天差地别。我的经验就是至少要压制中段视频10分钟，才能预估出大概的码率与大小，要准确一点，可能需要20分钟甚至30分钟，而且也不能保证预估会不会出现意外。阿凡达就是最好的栗子，有些片段会出现码率暴增的问题，我用29的crf参数，码率都能爆上六七千，而有些片段，码率可以掉下一千……预估它的最终压制大小简直要了我的老命（没办法，播放器只支持FAT32磁盘格式，必须保证电影最终大小小于4GB）……所以后面我找了最佳的方法，就是NVENC用slow级别，vbr码率模式，简直就是完美的平衡。