[VCB-Studio][教程19]AVS的多线程优化-MPP的使用.docx

VCB-Studio教程19AVS的多线程优化-MPP的使用

作为一个十几年前设计的程序，avs的多线程和内存管理可谓是一团糟。avs原生没有任何的多线程优化：

source=LWLVS(“”)#输入片源(#后面的表示注释，不影响avs的运行)

denoise=source.RemoveGrain(20)#对片源降噪

repaired=denoise.Repair(source,1)#将降噪后的视频，对比片源修复一些细节

这个简单的avs脚本用了3个滤镜。假设你的CPU有4个核心（假设没有超线程），3个滤镜中只有RemoveGrain在滤镜设计的时候有多线程优化：

source=LWLVS(“”)只会在核心1里面跑；

denoise=source.RemoveGrain(20)会在4个核心跑；

repaired=denoise.Repair(source,1)也只会在核心1里面跑，跟LWLVS共用一个核心。

这三个滤镜，后面的依赖前面的。最后脚本的效率由跑的最慢的滤镜决定。可想而知，瓶颈容易出现在source和repaired两个上面。这两个滤镜被挤在一个线程里面，效率堪忧。如果三个滤镜都只能单线程跑，整个脚本等于只能用到cpu的一个线程。这是avs的一个弱点：缺乏原生多线程优化机制。

另外，滤镜之间的工作，需要帧的缓存：

source=LWLVS(“”)读入片源第0帧，记录在内存里，记为A

denoise=source.RemoveGrain(20)拿过A帧，算出第0帧降噪后的内容，记为B

repaired=denoise.Repair(source,1)拿过A和B，算出修复后的内容。

可见，要让这个脚本正常运转，A和B两个缓存必不可少。事实上，除了这种滤镜间需要缓存，滤镜本身计算也要缓存。对于时域滤镜，经常需要读取当前帧前后的内容，就需要缓存更多的帧。

问题是，如果在第二步结束，准备计算第三步，缓存A就被扔了呢？avs就不得不这么做：

先把B存好了；然后重新执行步骤1，得出A。

这时候，LWLVS这个滤镜就被重复执行了。重复计算的帧对于效率的浪费是很严重的。

avs的缓存是自动管理的。默认情况下，avs会开销1GB的内存（你可以用setMemoryMax()修改，但是原生32bit的avs最多只能4GB(如果在32bit系统下，只能用到2GB/3GB)。历史遗留问题导致我们现在没办法安全用64bit的avs）。4GB对于高级脚本来说捉襟见肘，导致的后果就是缓存不够，大量帧被迫要被重复计算。(并且avs本身需要占用一些内存，实际可用滤镜内存一般不建议超过3GB)

于是我们寻求一个解决方案，能让我们利用更多的缓存，以及手动给一些中间步骤足够多的缓存，让下游滤镜在调用的时候不必重复计算。本教程讲述如何用MP_Pipeline实现三个目的：

avs滤镜间的多线程优化

更多内存控制和开销

手动管理部分重要的缓存

1.MPP原理解释——流水线运行多个avs

对于多线程和内存，一个可行的想法是多开：

第一个avs运行LWLVS，输出source

第二个avs可以接过source，运行RemoveGrain，输出denoise，并传递source

第三个avs可以接过source和denoise，运行Repair

三个avs模块，每个都在独立的进程里面运行，都可以有高达4GB的可用缓存。这样就优化了一些多线程的占用，也增加了内存的可用度。下面只需要规定缓存了：上游的模块丢给下游足够的预存。在每个avs结束的时候，规定输出的clip缓存数量。

MPP干的就是这些事情。

2.MPP语法演示

把上面的avs用MPP写出来:

MP_Pipeline(“””

###inheritstart###

RamUsage=1.0

###inheritend###

SetMemoryMax(min(3000,500*RamUsage))

Source=LWLibavVideoSource(“xxx.mp4”,threads=1)

###exportclip:source

###prefetch:48,32

######

SetMemoryMax(min(3000,3000*RamUsage))

denoise=source.RemoveGrain(20)

###exportclip:denoise

###passclip:source

###prefetch:16,8

######

SetMemoryMax(min(3000,3000*RamUsage))

denoise.Repair(source,1)

“””)

用