Nginx-RTMP存在的问题

1. 首先是延迟较高，大约是1.7秒，在扭转摄像头后观察画面，有非常明显的滞后感。
   

2. 当页面处于后台时，浏览器分配的解码算力有所下降，延迟会有累加情况。

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

SRS-webRTC的效果

• 延迟在300ms左右，几乎感受不到延迟。扭动摄像头，画面几乎是同时移动的。
  

• 不存在累加延迟的问题，即使处于后台，延迟也没有增加，依然是300ms左右
  

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

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

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

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

ICE如何寻找最佳路径

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