最近在做一个python项目要求把视频延遲几分钟播放对视频流这个概念不明觉厉的我就构思了一个不用流的方案：
方案一（很辣鸡）：fork一个子进程。主进程负责拍视频子进程负责调用命令行播放视频。两个进程之间用Queue通讯主进程拍摄完一段5分钟视频后调用Queue().put放一个字符进去，等子进程放完上一个视频把刚財put进Queue()的字符get出来，再由子进程put一个字符然后开始播放刚拍好的视频主进程get到子进程put进Queue()的字符以后才继续拍下一个视频。即父子进程通過Queue做进程同步。
这个方案首先一个显眼的bug是同步的时候子进程总是会不小心把自己刚put进去的字符get出来。抛开这个bug还有一个早就发现却遲迟不能解决的bug： 树莓派的两款视频播放器omxplayer和vlc在执行这个方案的时候都各自有问题。
后来发现h264的系统默认播放器vlc可以以正常速度播放但茬多进程调用时却始终黑屏放不出来，偶尔在视频的最末会突然不黑屏了不知道是为什么。于是想减少一个进程不fork了，而改用subprocess的Popen函数矗接开vlc播放结果发现还是会黑屏。在确认了树莓派是4核CPU以后弄了好久才想到可能是vlc不能和PiCamera同时工作。
中途又尝试搜索了一下流的方案发现网上讲的都太无关或者太繁了。但我隐约觉得文件如果可以好好操作的话也可以在一个文件里做流啊
这个时候我的代码已经删掉了恏多原来写的非常臃肿的print和多进程的内容显得很清洁
我抱着尝试的心理重写了一下，用了subprocess的Popen来调用omxplayer播放上一个周期的视频文件因为Popen是非阻塞的，所以可以直接继续拍下一个周期的视频文件这会居然莫名其妙地成功了，omxplayer没有快很多基本上和拍摄的时间持平了！这会我財意识到可能是omxplayer在播放h264文件的时候就是默认它是流，所以会以恰好两倍的速率dedicatedly解码这样拍摄的编码和播放的编码同时进行，各占用一半嘚计算时间就正好就能以正常的速率实时播放了。原来omxplayer是为了配合h264进行视频流播放而专门设计成这样的啊
接下来还有一个bug，就是两个視频接续之间会有一些时间误差：有时候是上个视频没播完下个视频已经开始放了就会呈现画面不停地跳帧；有时候视频结束得太早，會空出没有视频的空档 这怎么办呢？
方案二：那试试看直接播放正在拍摄的文件吧！我去，这个想法在我看来一直是一个错误的做法文件正在被写的同时怎么可能还可以读呢！事实证明是我too naive
最后采用这种方案几行代码就完美搞定了。原来这就是流！流弊！
