1. 区别在于使用x86_32/x86_64的avisynth,不是x264
2. 格式里有用pipeline,有用branch,不知道您用的是哪种用法
3. 如果你的avs里有五个滤镜,你的CPU是8核心,每个滤镜单独跑时,都是5fps,而且正好吃满一个核心,这时如果放在一个脚本里五个滤镜就会抢CPU的一个核心,速度可能变成1fps。如果pipeline的方式,
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
source()
### ###
filterA()
### ###
filterB()
### ###
filterC()
### ###
filterD()
### ###
filterE()
### ###
""")[/syntax]
就可以让五个filter几乎按流水线方式吃满5个核心,速度可以维持5fps,只是CPU占用从12.5%变成了62.5%。
4. 如果原始avs里有一个滤镜filterA,只吃单核心,速度是5fps,在8核心CPU上跑,放在一般的avs内吃满12.5%的CPU。如果采用branch(mt)的方式:
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
source()
### ###
filterA()
### branch: 4
### ###
""")[/syntax]
就可以让其在四个核心内同时处理。如果这个滤镜重复计算很少(譬如完全intra型滤镜),则可能达到5x4=20fps,只是CPU占用从12.5%变成了50%。
5. 如果原始avs里有两个滤镜,都只能吃单核心,如果单独跑时filterA速度是10fps,filterB速度是5fps,放在单个avs内,filterA和filterB去抢占单个核心,速度有可能变成3.33fps。这时如果用pipeline+branch(mt)的方式:
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
source()
### ###
filterA()
### ###
filterB()
### branch: 2
### ###
""")[/syntax]
这时filterA用一个核心,filterB分成两部分来跑,从而占满2个核心。如果其本身重复计算不多的话(譬如全intra型滤镜),filterB的速度几乎就是原始速度乘以branch数。结果就是整体速度可以维持10fps,只是CPU占用从12.5%提升到了37.5%。
6. 还是上面这个例子,我如果想继续提速,让filterA和filterB都用mt方式,例如:
[syntax lang="avisynth" lines="f"]MP_Pipeline("""
source()
### ###
filterA()
### branch: 2
### ###
filterB()
### branch: 4
### ###
""")[/syntax]
如果filterA和filterB都是重复计算量很少的intra型滤镜,这时filterA用了两个核心,从10fps提升到20fps,filterB用了四个核心,从5fps提升到20fps,整体速度也是维持在20fps,只不过avs的CPU占用从12.5%提升到了75%。
7. 以上例子前提是内存足够,且均未考虑source filter/tcp/系统CPU分配的开销,实际提速不会有这么高。
8. pipeline的原则是,在整个流水线过程中尽量保持每个部分的速度相当。例如filterA和filterB速度相当时,用pipeline分割之后两个不再抢占同一个核心,而是分别使用不同核心,则速度就会翻倍。如果filterA的速度非常快,譬如100fps,而filterB的速度非常慢,譬如1fps,这种情况就不适合用pipeline,因为即使不抢占核心了,filterB的速度还是瓶颈,filterA使用的核心根本没占满,完全在等filterB处理进度。
9. QTGMC这种有大量inter型处理的滤镜,如果内存足够,并且作为瓶颈原来只能吃满单个核心的话,用mt的方式单独跑avs还是可以有速度提升,只不过这个提升是以大量的CPU的重复计算为代价的。假设QTGMC里inter的计算有50%,intra的计算有50%,则用branch: 4的时候,50%的inter计算被重复做了4次,这部分不会有提速,另外50%的intra计算是不重复的,这部分是会提速的。总体看来,虽然有提速,但是CPU开销比较浪费。
10. 以上所有例子只考虑单独跑avs的情况。如果是在用x264压avs,则还需要考虑x264的CPU占用。如果本来一个intra的avs占12.5%,而x264占12.5%,x264在等avs,所以没有用上空闲的剩余CPU。用branch: 4,则avs占到了50%,而x264的处理也需要x4才能跟得上avs的提速,则几乎正好占满100%的CPU,总速度差不多为原来的4倍(CPU 25%->100%,fps x 4),也就是说CPU占用以及速度都和同时开4个x264跑4个avs差不多。而如果是QTGMC的话,avs的CPU占用提升到4倍,但是因为有冗余处理,实际速度只提升到原来的50%x4=2倍(仅intra部分提速,剩下的50%inter需要重复做所以不会提速),则x264只需要增加到25%的占用,总速度也只有2倍(CPU 25%->75%,fps x 2),也就是说CPU占用相当于同时开3个x264跑3个avs,但是速度只相当于同时开2个x264跑2个avs。而pipeline方式因为不会重复计算,这种开销增大但速度没有同等程度增加的现象相对来说较不明显。所以仅intra计算时,pipeline与branch(mt)配合使用是没问题的;而inter计算较多的情况下,只用pipeline而不用branch(mt)对整体速度的提升的性价比更高。
11. 如果本来avs+x264的CPU总开销就比较高,譬如70%-100%,在没有重复计算的情况下,avs提速,avs和x264抢占CPU,整体速度可能不会有明显提升,甚至也许因为抢占CPU,系统的CPU分配过程会导致一定的下降;而如果有重复计算的话,avs和x264抢占CPU,而且avs在CPU开销增加的同时没有同等程度的速度增加,则整体速度有可能反而大幅下降。所以mp_pipeline提速还需要本来avs+x264的总CPU占用比较低为前提。
12. 仅个人观点,实际是否如此以SAP菊苣的解释为准。