关于流媒体推拉流延时的几点说明。
经常看到一些流媒体相关的程序，号称零延迟，不用怀疑，这肯定吹牛逼的。
搞音视频开发，有个核心的指标就是实时性，也就是延迟多少毫秒，这个问题问的也是最多的。
音视频文件几乎不存在实时性问题，只有音视频流才有实时性的指标。
延迟多久这个涉及到很多方面，也要看你如何计算，从推流开始计算还是从拉流开始计算。
很多小伙伴们并不能明白什么叫延时，认为随便一个播放器播放出来的画面跟原始流画面时间差就是延时，其实这是对延时最大的误解。延时不是表象，很多人在测试延时时很不专业，对延时测试的专业性认识不足。
下面整理的是zlm作者写的关于延时的文章，非常完整而且有代表性。
采集延时：在采集摄像头或显卡画面时，由于fps的限制和cpu性能、内存拷贝速度等客观限制，采集画面成YUV/RGB等数据时会有一定的延时，一般延时为毫秒级别。由于一般编码器对输入数据格式存在限制，譬如要求统一输入YUV420P，这样在做RGB->YUV420P转换时，也会有转换计算延时(这个可以通过libyuv库来降低)。总而延时，采集延时大概为毫秒级别，如果fps为25，那么一般采集延时会有40毫秒（1000毫秒/25fps）以上的延时，在内存拷贝和颜色转换时，又可能增加若干毫秒的延时。
编码延时：在把原始画面输入到编码器时，并不会立即输出编码后的数据，特别是在开启B帧时，由于需要参考后面的P帧，那么延时会更大，所以延时敏感的情况下一般不开启B帧，这种情况下编码延时应该是毫秒级别，不是很大。
上行延时：编码后的数据，要经过一定的协议打包才能写入socket，然后传输给推流服务器或拉流代理服务器，协议打包会有一定的内存拷贝和计算量，那么会增加延时，不过这个延时很小，基本忽略不计。数据在上传到服务器时，这个延时可大可小，取决于网络质量。
转换延时：服务器在收到数据后，要读socket缓存、协议解析、解复用、重新打包等操作，不过总体而言，这个延时比较小，基本没什么影响。有时，服务器为了提高性能，会采取合并写的机制，也就是收到一定量的数据后才会一并转发，这个延时一般为几百毫秒，ZLMediaKit默认300毫秒左右，不过ZLMediaKit默认关闭合并写，也就是这个延时也很小。
下行延时：流媒体在把视频数据转发给播放器时，会存在网络发送，这个延时大小取决于网络质量，ZLMediaKit在关闭低延时模式时，还会增加MSG_MORE和关闭TCP_NODELAY导致的延时，不过ZLMediaKit默认开启低延时模式。
播放延时：播放器延时主要有网路接收延时、协议解析解复用延时、解码延时、缓存延时、渲染延时组成，这些延时中缓存延时最大，因为一般的播放器为了保证在网络抖动情况下视频播放的流畅性，会以增加延时为代价，增加播放缓存，这样在网络变差时，不至于播放缓冲卡顿。而且为了音视频同步，也必须确保一定的缓存量。这种延时一般都是秒级别，一般5秒左右。有部分播放策略是接收到数据后立即解码显示比如rtsp视频流，这样可以做到延迟最小。
缓存延时：流媒体服务器为了能让播放器立即出画面，往往会缓存最近的一个I帧，这个I帧往后的所有音视频数据被称作为GOP缓存。如果不缓存GOP，那么播放器要等下一个I帧才能解码成功或不花屏，显然为了提高播放体验，这个GOP缓存是不能去掉的。而一般GOP短则1~3秒，长则10几秒，这个跟采集端编码器设置有关，服务器改变不了。但是由于一般的播放器收到缓存后，并不会丢弃过多的画面来确保低延时。况且播放器还希望有一定的缓存来确保播放的流畅性，所以这个GOP缓存将会增大播放器的延时。
综合延时：最快可以做到200-300ms的延迟，比如rtsp视频流，对实时性要求高，可以不做缓存和音视频同步，收到就立即解码播放。hls一般最快可以做到5s延迟，flv一般可以做到3s延迟。
最终总结：综合考虑实时性以及支持的音视频格式，个人建议，推流用rtsp推流（支持的音视频格式最友好，比如支持265），拉流在web上个人推荐用ws-flv格式拉流（支持的格式多，没有6个同源的限制），拉流在可执行文件上用rtsp（格式多而且实时性最好，可以最快速度解码播放），在网页上虽然webrtc实时性最好，但是不支持265，这个就难搞。
