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不保證網絡傳輸的可靠性，丟包、亂序是經常發生的。一旦出現丟包、亂序，網絡傳輸質量就無法得到保證，最終會影響到音視頻的質量。