1.问题引入
流媒体中视频质量（会不会卡顿）、延时问题取舍一直是永恒的话题。
我们先来回顾一下视频直播的流程一般包括：采集、编码、推流、转码、分发、拉流、解码、渲染，在一个实时流媒体架构中，每个环节都可以进行不同程度的优化空间。如上图所示一般摄像机/NVR输出为RTSP视频流，经ffmpeg等工具将其推流转码为RTMP，如果在客户端需要WebRTC视频流，则需要配置srs等流媒体服务器将RTMP转码为WebRTC视频流
推流端一般情况下由于RTMP的更广的通用性和适配度较高的特性，都会使用RTMP作为推流后的格式，输入到流媒体服务器端再根据实际需求将RTMP进行转码。所以对于一般情况优化的工作就在拉流端。可以直接使用RTMP进行拉流，这对于一些桌面程序没有任何问题，但是对于网页端由于谷歌宣布不在支持flash，导致很多浏览器不能直接播放RTMP视频流所以一般就会用到http.flv（基于TCP延时相对高一些）、WebRTC（基于UDP，浏览器无插件即可播放对应的视频流画面）等。
常见的RTMP视频，基于TCP很少会出现花屏卡顿现象，但是相对WebRTC延时相对较高，但是WebRTC也存在自己的弊端，当网络情况一般时，尤其是无线连接状况下，出现丢帧的情况很常见，这样就会导致视频的短暂的卡顿。毕竟鱼和熊掌不可兼得，WebRTC没有传统直播架构中缓存，分片等设计方式，则不能保障了直播的流畅性，偶尔性的卡顿不能避免，但是如果网络较好可以适当提高相机分辨率以减缓卡顿的弊端。WebRTC一般更偏向于有高互动性要求的直播场景,但是搭建WebRTC直播的消耗比RTMP高（UDP的传输相对于TCP对资源消耗会更高些，在多进程模式下可能还会遇到内存资源的消耗）
开源流媒体SRS作者也曾提到低延时和卡顿优化的问题，RTC延时大概只有100ms，由于低延时所以很多技术点和RTMP是不一样的，作者给出了几个简单的比较
首屏：打开就能看，直播 > 低延迟直播 > RTC
流畅度：播放过程不卡，直播 > 低延迟直播 > RTC
低延迟：能吵架，RTC > 低延迟直播 > 直播n
任何一种模式都有其优缺点，，实际使用时根据自己情况而定
2.延时一般指标
| 时延 | 人的感受 |
|---|---|
| 200ms | 非常优质如同在一个房间里聊天 |
| 300ms | 大多数很满意 |
| 400ms | 有一小部分人可以感觉到延时，但可以进行互动 |
| 500ms | 延时明显，影响互动，大部分人不会满意 |
延迟指标的分级标准。通过图中表格可以看到，如果端到端延迟在200ms以内，说明整个通话是优质的，通话效果就像大家在同一个房间里聊天一样；300ms以内，大多数人很满意，400ms以内，有小部分人可以感觉到延迟，但互动基本不受影响；500ms以上时，延迟会明显影响互动，大部分人都不满意。
所以最最关键的一级是500ms，只有延迟低于500ms，才可以说是合格的实时互动系统。
3.低延时卡顿之间主要矛盾
低延时和视频卡顿之间即实时低延时和视频服务质量之间的矛盾
- 码流与带宽之间的矛盾。
要想达到好的质量，码流一般会比较大（当然，不能超过最大码流)，而带宽是有限的，于是码流和带宽之间就会产生矛盾； - 实时性和服务质量之间的矛盾。
通常为了保证好的实时性我们会选择UDP，而UDP不保证网络传输的可靠性，丢包、乱序是经常发生的。一旦出现丢包、乱序，网络传输质量就无法得到保证，最终会影响到音视频的质量。
