谁能接力Flash video 流媒体传输

在多年辉煌过后，Flash迎来了2020年——Chrome官方支持其操作的最后一年。

Flash是直播技术领域发展的基石。通过使用RTMP协议，Flash为现在的技术发展奠定了基础。在转为游戏流媒体平台Twitch之前的通用流媒体平台Justin TV是由Flash驱动的。随着视频直播需求增长，Flash被证明有一定局限性（依赖插件、专利技术、性能问题等），会阻碍实时流媒体的发展。

值得一提的是，Flash还是VOD和预录内容的默认解决方案。实际上，YouTube一度依赖Flash。尽管VOD也有Flash的替代产品，但本文将主要讨论实时流媒体（的替代品）。

由于许多基于浏览器的应用程序都依赖Flash，因此Flash即将消失是很多人最担心的问题。幸好有一个全方位的（许多方面的性能更棒）解决方案——WebRTC。

WebRTC

作为一种HTML5规范，WebRTC通过简单的API直接在浏览器和设备之间创建了端到端的实时媒体通信。WebRTC是一个开源项目，得到了行业大佬Apple、Google、Microsoft、Mozilla和Opera的支持。这种支持可确保WebRTC标准在可预见的将来持续更新、增强性能。

通过使用基于UDP的安全有效的传输工具SRTP，WebRTC能够以当前可能的最低延迟传输视频。即使网络信号不佳，它也仍然可以输送高质量的视频。

为了切实进行实时流式传输，WebRTC实现了以下API的操作：

MediaStream（即 getUserMedia）：获得对数据流（例如来自用户的相机、屏幕和麦克风的数据流等）的访问许可；

RTCPeerConnection：音频或视频流，可用于加密和带宽管理；

RTCDataChannel：通用数据的端对端通信。

下面我们会深入探讨WebRTC的工作原理。如果您对技术说明不感兴趣，可以直接跳到本节的结尾继续阅读。

为直接访问和编码一个连接或内置的网络摄像头和麦克风，WebRTC通常使用MediaStream API，调用GetUserMedia。这会创建MediaStream对象，其中包含视频流参数和规范说明（分辨率、宽高比、比特率等）。上述操作复制了Flash提供的麦克风和摄像头访问权限。

之后再通过RTCPeerConnection来发送MediaStream对象。本质上RTCPeerConnection包含用于维护有效连接的所有过程。也就是：

1. 丢包隐藏；
2. 回声消除；
3. 带宽适应（允许ABR支持）；
4. 动态抖动缓冲；
5. 自动增益控制；
6. 降噪；
7. 图像“清洁”。

请注意，WebRTC API不会直接指定用于标识可在何处找到每个客户端（IP地址，端口和连接参数）的信令过程。

RTCDataChannel API支持低延迟和高吞吐量的端对端数据交换。该API有很多潜在的用例，包括：

1. 游戏；
2. 远程桌面应用程序；
3. 实时文字聊天；
4. 文件传输；
5. 分散网络。

大家可以在已归档的HTML5 Rocks页面上找到所有相关工作原理的详细信息。

从技术上讲，基于HTTP的协议（例如HLS、CMAF或MPEG-DASH）也可作为替代品。但是其局限的性能和高延迟使它们无法成为替代Flash video进行实时传输的可行方案。但是HTTP协议已成为VOD的标准。这些协议为用例提供了难以置信的良好支持，为Netflix、Disney Plus等主要流媒体提供商运作提供了强大的动力。

可扩展性

我们有一个常见误区，那就是：WebRTC由于其建立端对端连接的方式而无法进行扩展。用传统思维来看，此说法在技术上是正确的。但是，根据一些使用到 WebRTC 技术的企业的经验来看，是可以通过一些有效的架构设计，来保证可扩展性的，例如，我们看到声网与新东方的案例，新东方将其旗下80多个分校和子机构、上百万线下师生搬到基于声网SDK实现的线上教室，保证了数百万师生同时在线上课、互动。而声网也是使用到了 WebRTC 的部分能力，通过其自建的端对端实时网络来进行高并发、可扩展的传输，他们也将端对端的网络传输能力以 API 的形式开放了出来，提供对应的“实时码流加速 SDK”。

最后：这意味着什么呢

Flash即将退出舞台。WebRTC是大势所趋。因为WebRTC允许访问网络摄像头和麦克风以建立实时延迟的实时视频连接，所以我们可以在没有插件的浏览器中工作。这使WebRTC成为Flash视频真正唯一的替代方案。RTC 技术将变得更加不可或缺。