思路大致上是这样的：
利用encx264支持在一个批处理中多开的特性，用AVS\VS将视频平均切割成两段后多开x264以提高单个任务的效率。最后用mmg的append来拼接两段视频。

写成批处理大致上是这样的：
先下载皮神的压制脚本
@echo off
：avs
echosrc8=LWLibavVideoSource^("%dr%\%fullname%"^) >>"%Temp%\%name%_part1.avs"
echo try {src.trim^(0,src.frameCount^(^)/2-1^)}>> "%Temp%\%name%_part1.avs"
echo catch^(e^){src.trim^(0,src.frameCount^(^)/2-0.5^)} >>"%Temp%\%name%_part1.avs"
echosrc8=LWLibavVideoSource^("%dr%\%fullname%"^) >>"%Temp%\%name%_part2.avs"
echosrc=src8.textsubmod^("%dr%\%sub%"^) >>"%Temp%\%name%_part2.avs"
echo try{src.trim^(src.frameCount^(^)/2,0^)} >>"%Temp%\%name%_part2.avs"
echo catch^(e^){src.trim^(src.frameCount^(^)/2+0.5,0^)} >>"%Temp%\%name%_part2.avs"
:Video
%x264% !taskclear
%x264% !task add720p "%Temp%\%name%_part1.avs" "%name%_part1.264" --bitrate%dbr%
%x264% !task add720p "%Temp%\%name%_part2.avs" "%name%_part2.264" --bitrate%dbr%
%x264% !task run2
:Audio
Rem 这里写压制音频的命令
:mkv
%mkv% --output^"%dr%\Done\%name%.mkv^" "%name%_part1.264" --no-subtitles+"%name%_part2.264" --track-order 0:0,0:1 --append-to 1:0:0:0 -S"%Temp%\%name%.m4a"
Rem 这个%name%.m4a指的是压制好的声音文件

说明：
1，不适合追求极致压缩比的人，因为分为两段的时候大概会增加约100k左右的体积(对于1080P的视频)。增加的体积大小和keyint以及视频压制后每帧的体积有关
2，如果开始压制的时候cpu占用率可以达到100%，那么即使使用这个方法也不会带来任何效益。如果内存不足的话反而会降低效率
3，只适合一次处理单个视频的情况。如果需要转码多个视频，直接多开会比较好
4，理论上可以一定程度上解决avs并行化程度不足的问题，但我没测试过

顶起来，虽然看不懂

什么机器压制不会占满CPU
megui的限制，那用ffmpeg不就好了，保证满载

1,cpu的占用率由Block的尺寸决定，所以分辨率很大程度上影响占用率。
2,这贴自始至终没有提到MEGUI
3,ffmpeg里集成的是x264的一个库。相对于x264，用这个库来压制不会带来效益

还是一个一个运行效率高，cpu达到满载再加任务会增加切换调用时的消耗

在说明中已经写了"单任务CPU满载的机器不适用这个思路"
原则上CPU满载就说明并行化程度足够满足需求了

之前魔改过x265，可以直接输出meta data和gop，然后后期再合并gop数据回mp4，只要切割点选好，是无损的方案。你有兴趣魔改x264的话可以参考我的GitHub上的代码。

我只求有人答复，x265不好吗？最低都能省30%的码率，而且宏块不是固定的16x16，10bit比x264的10bit兼容性还好。目前就只有国外小组在做，法律上的原因？
或是站长们的机器还不足以双路E5？
还是站长追求利润的最大化，每一台机器都能看的RMVB。

@MeteorRain_1
GOP追加这种属于断点续压吧，如果两个进程同时进行的话第二个x264没办法参考第一段末尾的数据，这样的话是没办法做到无损的吧