webRTC直播为什么比RTMP快？

Parzivval

已于 2023-04-09 20:32:00 修改

阅读量1.3k

点赞数

文章标签： webrtc 网络

于 2023-03-28 18:17:44 首次发布

本文链接：https://blog.csdn.net/lannister_awalys_pay/article/details/129821754

版权

文章对比了Nginx-RTMP和webRTC在视频传输中的延迟表现。Nginx-RTMP由于基于TCP的可靠传输，存在1.7秒延迟且在后台运行时延迟累积严重。而webRTC利用UDP协议，结合ICE技术通过STUN和TURN实现P2P连接，延迟约300ms，即使在后台也无明显增加。webRTC的低延迟得益于直接获取MediaStream对象和JS解码API，不受浏览器后台状态影响。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Nginx-RTMP存在的问题

首先是延迟较高，大约是1.7秒，在扭转摄像头后观察画面，有非常明显的滞后感。
当页面处于后台时，浏览器分配的解码算力有所下降，延迟会有累加情况。

相比于刚才17:09时的1.7秒延迟，此时延迟已经累积到1分钟以上：

请添加图片描述

SRS-webRTC的效果

延迟在300ms左右，几乎感受不到延迟。扭动摄像头，画面几乎是同时移动的。
不存在累加延迟的问题，即使处于后台，延迟也没有增加，依然是300ms左右

RTMP和webRTC导致速度差别的原因

RTMP是基于TCP的可靠传输，webRTC采用UDP协议传输，建立P2P连接
1. webRTC针对丢包问题通常采用补偿策略：帧间预测
RTMP建立连接时不包括视频信息，所以还需要对视频数据进行解析；webRTC建立SDP连接时包含视频信息，所以不需要再额外进行解析；
RTMP流使用了浏览器内置解码器，在浏览器处于后台时，性能会下降，导致累积延时特比大，webRTC使用的是JS的两个API，不会因为处于后台而性能降低。
webRTC使用ICE技术通过STUN和TURN寻找最佳通讯路径，建立P2P连接减少受阻塞影响；同时检测网络环境动态选择最优链路。

RTMP和webRTC协议被浏览器接收到播放的过程

RTMP传输flv流在浏览器播放的过程：
1. 获取RTMP数据转换成flv
2. flv.js解析：二进制流-> JS对象(音视频流依然是二进制） -> 获取头部标签等信息 -> 音频、视频部分
3. 解码：利用浏览器内部音视频解码器，二进制流存储在buffer中，将压缩的数据解读成RGBA、YUV格式，转存到浏览器video API中
4. 播放：渲染画面，播放
webRTC传输flv流在浏览器播放的过程：
1. SDP Offer/Answer：交换信令，建立连接。双方的SDP中包含希望得到视频的信息和传输视频的信息，以此建立信道
2. 获取MediaStream对象：不需要解析，直接通过WebRTC API获取，包含了音视频二进制流。
3. 利用Web Audio API和HTML5 Video API两个JS API去解码和渲染，没有使用浏览器内置解码器。

ICE如何寻找最佳路径

ICE (Interactive Connectivity Establishment)通过STUN（Session Traversal Utilities for NAT）和TURN（Traversal Using Relay NAT）来实现点对点之间的连接。
ICE首先使用STUN协议（Session Traversal Utilities for NAT）来获取本地网络地址，例如NAT类型和公网IP地址等信息，然后将这些信息发送给对方。
接下来，ICE会在两端同时运行一个ICE代理，通过STUN协议尝试连接对方。如果直接连接不成功，ICE代理就会通过TURN协议（Traversal Using Relays around NAT）连接到TURN服务器。TURN服务器相当于一个中转站，可以让两端之间进行数据传输，避免网络阻塞和NAT等问题的影响。
当ICE代理连接到TURN服务器时，它会尝试连接对方。如果仍然无法连接，则会使用ICE协议中的候选地址，例如使用UDP和TCP等传输协议，尝试连接对方，直到找到一个可用的路径为止。
当找到最佳路径时，WebRTC就可以通过该路径进行数据传输。
如果遇到网络波动，ICE会通过发送心跳包或者其他方式来监测网络的变化，发现网络环境变化时，ICE会尝试重新选择最优的通信路径，以保持连接的稳定性和质量。