主要分两步骤来进行：
一、HEVC低参预处理
-vf "eq=1.0:0.0:1:1.1,scale=1920:1080:flags=spline+full_chroma_int+accurate_rnd+full_chroma_inp,setsar=1/1,setdar=16/9"
-af "aresample=48000:resampler=soxr"
-f mkv
-c:v libx265 -b:v 20000k -preset:v superfast -tune:v none -sc_threshold 30 -g 720
-c:a pcm_s16le -ac 2
-sn -map_metadata -1 -map_chapters -1
解析：
1.preset不能使用“ultrafast”，“ultrafast”下不支持关键帧的自动量化。“-sc_threshold 30 -g 720”这个参数用以量化场景切换自动插入关键帧，真实画面“-sc_threshold”参数20-40，人造画面（如动画片）“-sc_threshold”参数80，这是我测试后经验总结得出的，不保证适用一切。
2.“eq=1.0:0.0:1:1.1”，调节ffmpeg伽马到1.1，相当于标准伽马曲线量化的2.2左右，目的是暗部增亮。因为MPEG系列压缩方法都存在暗部处理有概率抽风的通病，所以提一点暗部亮度。这里要吐糟一下ffmpeg的大聪明们，就是要和国际标准对着干，eq里的伽马默认值是1.0，这是哪个大聪明想出来的……为了方便调节，国际公认标准伽马曲线量化到2.4，越小暗部越亮，越大亮部越暗，然后ffmpeg的大聪明们搞得这个1.0是基准，越大暗部越亮，越小亮部越暗，反过来就不说，量纲也不同，真™反人类……
3.因为我通常需要将UHD压缩到FHD，所以设置：“scale=1920:1080:flags=spline+full_chroma_int+accurate_rnd+full_chroma_inp,setsar=1/1,setdar=16/9”，这是ffmpeg默认里最佳的缩放方式，需要缩放的时候无脑使用就行。
4.为什么要将伽马调节、分辨率调节、音频转化以及自动关键帧单独拿出来进行一遍转码，目的一是高级编码特性使用的越少，自动关键帧插入的越准。二是经我大量实测，将这些处理合并到正式转码中后，正式转码如果使用slower的preset，速度只有2FPS不到，但是将这些处理独立出来，那么正式转码速度可以到3.8FPS，快了近一倍，2小时的影片一步处理需要24小时以上的时间，而这样分开处理则只需要14（第二步正式编码时间）+1（第一步低参预处理编码时间）=15小时……不要问我为什么，我也不知道，世界就是这么神奇……
二、HEVC正式编码
-vf "shanasubtitle=1"
-af "volume=0dB"
-f mkv
-c:v libx265 -b:v 4000k -preset:v slow -tune:v none -force_key_frames source -g 720
-c:a libfdk_aac -fdkprofile he -vbr 5
-sn -map_metadata -1 -map_chapters -1
解析：
1.preset如果用slower，速度实在让人无法接受，而针对slow码率被限可能的暗部抽风问题，在前一步预处理阶段稍微提亮了一点暗部进行缓解（安慰剂……）
2.预处理将音频转换为立体声PCM就是为了方便现在将音量标准化……音频编码无脑用shana卡bug的libfdk_aac，“-c:a libfdk_aac -fdkprofile he -vbr 5”实现最小码率最佳质量，什么ogg、opus在其面前都是渣渣，不然为啥shana非要下载这个第三方库，ffmpeg里默认aac编码库它不香吗？
3.码率控制使用VBR是因为我需要严格让视频文件小于4GB，我的手机只支持FAT32格式，大于4GB不给储存……不要说用CRF慢慢试，试一次几个小时，我疯了……
4. “-force_key_frames source -g 720”，意思是编码视频继承源视频关键帧，没有这个那么预处理白做……
5.最后，shanaencoder的字幕压进视频是真心让人省心，是我用过的编码器里效果最好同时最傻瓜的，这是让我坚持使用shanaencoder的重要原因……
一、HEVC低参预处理
-vf "eq=1.0:0.0:1:1.1,scale=1920:1080:flags=spline+full_chroma_int+accurate_rnd+full_chroma_inp,setsar=1/1,setdar=16/9"
-af "aresample=48000:resampler=soxr"
-f mkv
-c:v libx265 -b:v 20000k -preset:v superfast -tune:v none -sc_threshold 30 -g 720
-c:a pcm_s16le -ac 2
-sn -map_metadata -1 -map_chapters -1
解析：
1.preset不能使用“ultrafast”，“ultrafast”下不支持关键帧的自动量化。“-sc_threshold 30 -g 720”这个参数用以量化场景切换自动插入关键帧，真实画面“-sc_threshold”参数20-40，人造画面（如动画片）“-sc_threshold”参数80，这是我测试后经验总结得出的，不保证适用一切。
2.“eq=1.0:0.0:1:1.1”，调节ffmpeg伽马到1.1，相当于标准伽马曲线量化的2.2左右，目的是暗部增亮。因为MPEG系列压缩方法都存在暗部处理有概率抽风的通病，所以提一点暗部亮度。这里要吐糟一下ffmpeg的大聪明们，就是要和国际标准对着干，eq里的伽马默认值是1.0，这是哪个大聪明想出来的……为了方便调节，国际公认标准伽马曲线量化到2.4，越小暗部越亮，越大亮部越暗，然后ffmpeg的大聪明们搞得这个1.0是基准，越大暗部越亮，越小亮部越暗，反过来就不说，量纲也不同，真™反人类……
3.因为我通常需要将UHD压缩到FHD，所以设置：“scale=1920:1080:flags=spline+full_chroma_int+accurate_rnd+full_chroma_inp,setsar=1/1,setdar=16/9”，这是ffmpeg默认里最佳的缩放方式，需要缩放的时候无脑使用就行。
4.为什么要将伽马调节、分辨率调节、音频转化以及自动关键帧单独拿出来进行一遍转码，目的一是高级编码特性使用的越少，自动关键帧插入的越准。二是经我大量实测，将这些处理合并到正式转码中后，正式转码如果使用slower的preset，速度只有2FPS不到，但是将这些处理独立出来，那么正式转码速度可以到3.8FPS，快了近一倍，2小时的影片一步处理需要24小时以上的时间，而这样分开处理则只需要14（第二步正式编码时间）+1（第一步低参预处理编码时间）=15小时……不要问我为什么，我也不知道，世界就是这么神奇……
二、HEVC正式编码
-vf "shanasubtitle=1"
-af "volume=0dB"
-f mkv
-c:v libx265 -b:v 4000k -preset:v slow -tune:v none -force_key_frames source -g 720
-c:a libfdk_aac -fdkprofile he -vbr 5
-sn -map_metadata -1 -map_chapters -1
解析：
1.preset如果用slower，速度实在让人无法接受，而针对slow码率被限可能的暗部抽风问题，在前一步预处理阶段稍微提亮了一点暗部进行缓解（安慰剂……）
2.预处理将音频转换为立体声PCM就是为了方便现在将音量标准化……音频编码无脑用shana卡bug的libfdk_aac，“-c:a libfdk_aac -fdkprofile he -vbr 5”实现最小码率最佳质量，什么ogg、opus在其面前都是渣渣，不然为啥shana非要下载这个第三方库，ffmpeg里默认aac编码库它不香吗？
3.码率控制使用VBR是因为我需要严格让视频文件小于4GB，我的手机只支持FAT32格式，大于4GB不给储存……不要说用CRF慢慢试，试一次几个小时，我疯了……
4. “-force_key_frames source -g 720”，意思是编码视频继承源视频关键帧，没有这个那么预处理白做……
5.最后，shanaencoder的字幕压进视频是真心让人省心，是我用过的编码器里效果最好同时最傻瓜的，这是让我坚持使用shanaencoder的重要原因……
