一個經過優化的RTMP-CDN網絡端到端的延遲大概在2-3秒，延遲大一些要在5秒甚至10秒以上。從推流到播放，會引入延遲的環節有編碼延遲、網絡丟包和網絡抖動、視頻的分段傳輸、多媒體節點的relay、播放器的緩存等等。實際上除了網絡丟包和網絡抖動不太可控之外，其他的各個環節都有一定的優化方案，比如使用x264的-preset ultrafast和zerolatency，可以降低編碼的延遲，分段傳輸部分可以把GOP減少到1秒之內，在播放器端可以適當減小buffer，並設置一定的追幀策略，防止過大的buffer引起的時延。（積累延遲：原因是RTMP基於TCP不會丟包，所以當網絡狀態差時，服務器會將包緩存起來，導致累計的延遲）
雖然RTMP直播系統從推流端到網絡傳輸到播放器都可以做到深度定制來達到比較低的延遲，但是成本是比較高的。如果做到超低延遲（1000毫秒內）更是難上加難，而且這么低的延遲也會帶來一些負面的效果，當網絡出現少許抖動的時候就會出現卡頓等等。
我們可以在現有的RTMP-CDN系統上做一些優化調整，在邊緣節點把RTMP流轉化為WebRTC可以播放的流來達到低延遲和CDN系統的復用，同時還可以利用WebRTC抗丟包來優化最后一公里的觀看體驗。WebRTC在各個平台上都有相應的SDK，尤其是在瀏覽器內嵌，可以極大的減少整個系統的開發、升級、維護成本，達到打開瀏覽器就可以觀看的效果。
GOP-Cache
GOP是視頻流中兩個I幀的時間距離。GOP有什么影響？
Flash（解碼器）只有拿到GOP才能開始解碼播放。也就是說，服務器一般先給一個I幀給Flash。可是假設GOP是10秒，也就是每隔10秒才有關鍵幀，如果用戶在第5秒時開始播放，會怎么樣？等待下一個I幀，也就是說，再等5秒才開始給客戶端數據。這樣延遲就很低了，總是實時的流。可是問題是等待的這5秒，會黑屏，現象就是播放器卡在那里，什么也沒有。所以服務器需要總是cache一個gop，這樣客戶端上來就以前一個I幀開始播放，就可以快速啟動了。但是這樣的問題是延遲就大了。所以編碼器調低GOP，比如0.5秒一個GOP，這樣延遲也很低，也不用等待。壞處是編碼器壓縮率會降低，圖像質量沒那么好。
積累延遲
服務器可以配置直播隊列的長度，服務器會將數據放在直播隊列中，如果超過這個長度就清空到最后一個I幀。當然這個不能配置太小，譬如GOP是1秒，queue_length是1秒，這樣會導致有1秒數據就清空，會導致跳躍。延遲基本上就等於客戶端的緩沖區長度，因為延遲大多由於網絡帶寬低，服務器緩存后一起發給客戶端，現象就是客戶端的緩沖區變大了，譬如NetStream.BufferLength=5秒，那么說明緩沖區中至少有5秒數據。