理解画面卡顿，花屏，音视频同步等

很多刚接触ffmpeg的人，遇到推流时画面卡顿，就会头疼，为什么卡，是不是我音视频没同步啊，代码哪里出问题等等。所以我们一定要理解卡顿是什么原因造成的，要理解什么情况下才需要做音视频同步，什么时候需要控制推流速度，理解花屏是什么原因引起的，更远一点，什么时候用队列，什么时候用多线程。

一、首先要明白一个很重要的一点，音视频同步是播放端在处理的逻辑。
你做的是什么，你是做推流，还是在做播放器。
你做推流端只需要保证pts,dts正确，播放器就能音视频同步。音视频同步可以看ffplay.c的实现方式。

二、播放一会就开始卡，卡是因为推流过快（也人叫吐流过快），播放端解码器内部有一个缓冲区，会缓冲推过来的帧，如果推流过快，这个缓冲区就回堆满，内部应该是会在满了以后就清空了一部分帧，所以比如有一个帧是要在第10秒的时候播放的，这个帧被清掉了，现在填入的是pts=第20秒才开始播放的帧，那么播放到第10秒的时候，它找不到这个pts=10的帧了，一个视频画面播放多久，取决于下一帧的pts和改帧的pts差值，就是一帧播放的时间，如果pts=10不见了，假如当前帧pts=8,本来如果pts=10健在，他会播放2个时间单位，但是现在这一帧变成了pts=20，所以他会理解需要延迟16个时间单位，才会刷新画面，去播pts=20，这就是画面卡顿的原理。这是我的理解。(注:这里的卡顿不考虑丢失参考帧导致画屏现象)

推流本地mp4和做转流器有什么区别
静态资源和网络流最大的区别在于静态资源av_read_frame是连续的，而网络流av_read_frame是间隔的，或者说它是读是连续的，但是取是间隔的。因为网络流是实时的，播放到哪，这一帧才有，你才能取。这一帧播放完，才有下一帧，
所以你read每一帧，就是间隔的。本地视频不同，每一帧都摆在那了，所以你可以读取。

读取速度+解码速度+编码速度，这三个速度决定你的推流速度

推流本地mp4，就是读取速度过快，所以推流过快，画面就会卡。

网络流假设推流速度是每帧40ms为标准。网络流(这里的网络流均指实时直播流)的读取速度取决于视频源的帧率，(音频流是采样率和frame_size)

实际解码+编码速度很快，一般视频最多10ms左右，音频最多5ms左右，注意这个值是波动的。

假设现在取到了第一帧视频帧(耗时为0)，解码加编码总共耗时为10ms，
即第一帧就是在10ms推出去的，
然后取第二帧，第二帧是第40ms获取到的，编解码耗时同上，
则第2帧是在第50ms推出去的
然后取第三帧，第三帧是第80ms获取到的，编解码耗时同上，
则第3帧是在第90ms推出去的
然后取第四帧，第三帧是第120ms获取到的，编解码耗时同上，
则第4帧是在第130ms推出去的
发现规律：每一帧的推送间隔时间都是40ms，也就是我们的标准推流速度。

所以网络推流是正常的。(注意，因为编解码的耗时是不确定的，这里只是从宏观角度证明理想情况下网络推流速度是自控的，所以画面不会卡)

如果我推送本地mp4,单线程，想控制推流速度，视频帧率是40ms，可以在每次write_frame时，固定delay40ms达到目的？

假设现在取到了第一帧视频帧(耗时为0)，解码加编码总共耗时为10ms，首次不delay。
即第一帧就是在10ms推出去的。
然后取第二帧，第二帧是第10ms获取到的(静态视频，单线程，意味着第一帧处理完，马上第2帧就开始了)，编解码耗时10ms，delay 40ms，
则第2帧是在第60ms推出去的
然后取第三帧，第三帧是第60ms获取到的，编解码耗时，delay同上，
则第3帧是在第110ms推出去的

发现实际推流速度是每次间隔50ms，因为实际间隔时间要把编解码耗时计算在内，再次重申，每次间隔50ms这都是理想情况，因为实际耗时是不确定的，是一个波动的值。

所以想比较精准的按照帧率推流，不能使用delay固定值

三、花屏
推流过快也可能出现花屏，花屏根源是丢帧，所以要分析什么导致了丢帧。目前我遇到的的花屏主要来源还是推流过快，所以，控制推流速度非常重要。