webrtc 的理解

常规视频的传输包括以下几个步骤：
采集，编码，推流，转码，分发，拉流，解码和渲染

在一个实时的音视频系统架构里，上面的每个环节都会有一定程度的优化空间。

以下内容摘自：rtmp直播和webrtc直播对比优劣何在?

webrtc 是近两年看好的方向，大多采用 RTMP 框架的流媒体系统在处理直播中的问题时会用到 webrtc。webrtc 最初是由 Google 开发的，它们作为基于浏览器的实时通信的开源解决方案发布。它使用 UDP 来进行媒体推流，而不需要创建离散的媒体段，这为所有客户端提供了始终如一的低延时（低于 500ms）。随着苹果的 webrtc 支持加入了 Safari 11，它现在已经被所有主流浏览器（包括 Google Chrome，Firefox，和 Microsoft Edge）所支持。webrtc 协议的设计使其可以很灵活的进行各种实现，使企业能够尝试针对一对一，一对多，甚至一对数百万的解决方案。此外，它支持通过TLS进行交付，以确保传输过程中内容的安全。

除了低延时流传输外，webrtc 还提供了一个实时双向数据通道，可用于发送和接收数据流。这种双向数据技术给在线流现在如何能成为一种交互式的体验提供了很多有趣的可能性。

为什么强烈建议你基于 webrtc？对直播系统，难的不是服务器，而是客户端。客户端难的地方则主要体现在两个方面，一是网络传输有关，像侦听事件，同步主线程和读线程，穿透；二是流数据有关，像编码、解码、回声消除。而这些正是webrtc帮你解决了。

优点

• W3C 标准，主流浏览器支持程度高
• Google 在背后支撑，并在各平台有参考实现
• 底层基于 SRTP 和 UDP，弱网情况优化空间大
• 可以实现点对点通信，通信双方延时低（目前主要应用于连麦和视频会议）

缺点

• 传统 CDN 没有类似的服务提供（一对多模式主要是 rtmp 的 cdn 内容分发机制）
• 编译 webrtc 的源码就是一个比较大的挑战，搭建其复杂的编译环境往往会遇到很多意想不到的问题。
• webrtc 缺乏服务器方案的设计和部署。传输质量难以保证，优化手段也有限，只能做一些端到端的优化，难以应对复杂的互联网环境。

---

什么是媒体推流和离散的媒体段？

---

基于 UDP 的两种方案对比，第一种是可靠 UDP 方向，比如 Quic ，另一种是 RTC 方案，比如 WebRTC 。

RTC（Real time communication）实时通信，是实时音视频的一个简称，我们常说的 RTC 技术一般指的是 WebRTC 技术

从五个维度对两种方案做了对比：

• 传输方式：Quic 是可靠传输；而 RTC 是半可靠传输，特定情境下可对音视频有损传输，可有效降低延迟。
• 复杂度：Quic 的复杂度非常低，相当于将 TCP 接口换位 Quic 接口即可，RTC 方案的复杂很高，涉及一整套的协议设计和 QOS 保障机制。
• 音视频友好性：Quic 不关心传输内容，对音视频数据透明传输。RTC 对音视频更友好，可针对音视频做定制化优化。
• 方案完备性：从方案完备性方面来讲，Quic 是针对传输层优化，而 WebRTC 可提供端对端优化方案。
• 理论延迟：经我们实验室测试以及线上数据分析，WebRTC 方案的延迟可以达到 1 秒以内。

综上，Quic 方案的最大优点是复杂度低，不过这个方案要想达到更低的延迟，也需要引入更多的复杂度。从方案的先进性上看，选择 WebRTC 技术作为低延迟方案。同时，我们也相信，RTC 技术和直播技术的融合，是未来音视频传输技术的一个趋势

参考：为何一直推荐 webrtc？

QoS（Quality of Service）即服务质量。在有限的带宽资源下，QoS 为各种业务分配带宽，为业务提供端到端的服务质量保证。例如，语音、视频和重要的数据应用在网络设备中可以通过配置 QoS 优先得到服务

WebRTC 是浏览器内建的所有数据传输方式中，唯一一个不依赖 Server-Client 模式的。故只有使用 WebRTC 作为 P2P 的传输协议，才能兼容消费带宽占比最大的浏览器端用户

相关文章：https://github.com/bovinphang/WebRTC