WebRTC视频质量卡顿问题分析
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.低延时卡顿之间主要⽭盾
低延时和视频卡顿之间即实时低延时和视频服务质量之间的⽭盾webrtc浏览器
1. 码流与带宽之间的⽭盾。
要想达到好的质量，码流⼀般会⽐较⼤（当然，不能超过最⼤码流)，⽽带宽是有限的，于是码流和带宽之间就会产⽣⽭盾；
2. 实时性和服务质量之间的⽭盾。
通常为了保证好的实时性我们会选择UDP，⽽UDP不保证⽹络传输的可靠性，丢包、乱序是经常发⽣的。⼀旦出现丢包、乱序，⽹络传输质量就⽆法得到保证，最终会影响到⾳视频的质量。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。