当然你也可以把你已经处理好的视频用 ffmpeg 和源视频的音频流混流一下就行了

最合理的方法应该是 ffmpeg+滤镜或者掩膜

gausBlur = cv2.GaussianBlur(img[0:x1,0:y1], (101,101),0,0)

@8023 因为有些时候发帖不想开梯子

@IdJoel 比如 keil c51 就是啥提醒都没有

先 resize 再显示呀

你这种写法在 python 下都会建议你把写法函数改成 classmethod 或者 staticmethod 了

其实目前看熊猫吃短信的准确性还是可以接受的，支持作者一下

@ray1888 你自己看看 multiprocessing 模块的源代码不就知道了，multiprocessing.Manager()产生的就是 rpc 代理调用对象，当然如果你直接用 multiprocessing.Pipe()或者.Queue()那样的确是用进程管道实现的
说到底 rpc 只是为了降低程序和操作系统的耦合度，如果用 socket 通讯这部分代码只用写一次，如果用本地 pipe，共享内存之类的方式，虽然效率能有所提高，但是适配的复杂度也大大提高了，很多情况下并没有必要

其实准确说应该是 ipc，rpc 是建立在 ipc 基础上的

因为 python 的多进程队列本身也是用 rpc 实现的呀

@justou 很多情况下存在数据来源不可控的问题，原来的代码是使用纯 python 代码写的，自然也就没有用 array 和 numpy 的容器，而有些运算是需要做一些修改源数组的，这时候如果再写一部分衔接代码在两种数据结构之间拷贝就不太划来了

@justou 有些时候希望把一些运算量大的部分用 c++写，但是数据源依然是来自 python 代码，而这个时候，如果需要处理大量数据，那么这些数据就一定是放在 list 或者 dict 中的，有些时候还要求返回的依然是一个 list，所以如果可以在 c++中像 std::vector 以及 std::map 中操作 list 和 map 那么互操作性就大大增加了
这点 Boost.Python 做的就挺好，但是整个 boost 类库有点过于庞大了，要是能拆分出来就完美了

其实做一份 sqlite3 的可能更实用一些

@justou 其实吧，要是能在 c++中无缝操作 python 的 list 和 dict 就完美了，可惜 python 并没有提供官方的 c++接口

@nicevar 其实说到“信号量超级多”这个问题，就算没有 GIL 他也一样会堵塞呀，因为 UI 线程还是只有一个，如果你要是在两个普通的 QThread 之间发送数据的话，那还是老老实实用 python 标准库的 queue 方便，反正都绕不过 GIL

用 dism++清理试试

@lx1510 手机没有 bios 直接报错崩溃了