moviepy性能解读，视频拼接性能怎样？ 能作为服务器端多线程处理吗？如何提高moviepy处理速度

首先要指出的是。MoviePy 基于ffmpeg ，视频的最后生成，用的就是ffmpeg。所以，讨论MoviePy的性能问题，归根到底是讨论ffmpeg的性能。

关于moviepy的程序执行过程，理论上所有耗时操作只发生在将clip写出到文件的时候。基于此因素，在实际操作中，尽量只在合成最后才进行视频的导出操作，即 write_videofile

关于，ffmpeg的性能呢，一般需要看CPU是否给力，根据我们使用的经验来看，合成的速度是取决于CPU 的，很多时候CPU飙到很高，内存(Memory)占用率并不是很高。但是ffmpeg有一个很不好的特点，在长时间运行后，容易导致OOM，这或许是和长时间运行产生大量缓存垃圾有关，我们曾经尝试连续8小时运行ffmpeg做视频处理，每次运行完毕之后清除cache，杀掉已经存在的ffmpeg，最后还是不幸挂掉 。所以，如果要比较严谨地进行服务端的视频处理，需要做好事务回滚。

案例 ：我们通过维护一个RabbitMQ队列，存放视频处理任务，运行一批相互独立的任务消费者，共享素材挂载，合成视频。遇到两个大的考验。第一，ffmpeg的OOM问题。第二，RabbitMQ消费者心跳超时的问题。OOM问题上面已经说过，RabbitMQ心跳超时，首先需要知道的是，rabbitMQ的默认心跳时间是60s，如果超过60秒时间消费者没有和RabbitMQ服务器传送心跳，服务器会认为这个消费进程死掉了，会将这个任务重新放回队列，分发给其他消费者。要知道，视频合成时间一般很长，我们尝试着改过RabbitMQ的默认心跳时间，发现60s的心跳时间是一个比较合理的值，改长的话，进程最后会真的找不到服务器，但是服务器认为这个消费进程还活着，服务端的消费者进程状态无法及时刷新造成实际状态与服务器状态存在时间差，这段时间差 = 心跳时间 - （服务器刷新状态时间点 - 消费进程死掉时间点） 这是一件很危险的事，所以，最好不要轻易改动默认的心跳时间。而解决心跳超时的办法就是在耗时操作时调用Rabbit提供的方法，手动发送心跳。

首先，如果速度要求比较高，处理比较复杂的话，服务端不是很现实，ffmpeg会导致很容易OOM，成本会很大。第二，多线程处理，少量可以，一般超过10个线程机器会疯

1.更优化的视频导出时机 2.CPU升级 3.ffmpeg开启GPU加速（还没有试过，有空试了出教程）

回到问题目录