常见直播流协议，你学“废”了吗?

---

前言

大家好，我是练习两年半的Java练习生，今天我们来讲讲关于直播协议的那些故事吧。这些年随着直播行业的兴起，特别是在疫情之后，什么直播带货、直播授课等等相继火爆，各个公司也都相继参与到直播这个业务中，那这背后的技术有哪些呢？今天就让我们通过学习直播相关的一些协议来感受这背后的技术吧～

---

正文

首先，在我们进入到具体的协议之前，我们先来看看什么是视频流协议（直播流协议）以及在视频领域常见的几个概念：协议、编解码器、容器

什么是视频流协议？

视频流传输协议是将视频分解成块状、发送到观看者并重新组合的标准化传递方式。视频流传输协议是用于将视频文件分解成小块进行传递的规则和方法。
在我们更深入地了解视频流传输协议之前，让我们更加深入地了解视频流传输协议背后的原因。大多数数字视频都是为了存储和播放而设计的。这导致需要考虑两个主要因素，即小文件大小和通用播放。
大多数视频文件都不是为流媒体而设计的，这意味着要将视频流进行转换为可流式传输的文件。这需要将视频文件分成小块。这些块随后按顺序到达并逐个播放。如果您正在进行实时视频流，则源视频将直接来自相机。否则，它来自于用于视频点播 VOD 内容的文件。
这是视频流协议的基本工作原理的简要说明。视频流协议可以变得更加复杂。例如，许多协议都是“自适应比特率”协议。这项技术将在任何时候提供观众所支持的最佳质量。
因此，如果观众的网络速度较慢，则会传送低质量视频，如果观众的网络速度较快，则会传送高质量视频。
有些协议着重于减少延迟，即真实事件发生与在观看者屏幕上播放之间的延迟。某些视频协议仅适用于某些系统，而其他视频协议则专注于数字版权管理（DRM）。
一些最受欢迎的流媒体协议包括RTMP、HLS和WebRTC。您经常会看到这些流媒体协议相互比较，例如WebRTC vs HLS和WebRTC vs RTMP等比较。

协议、编解码器和容器格式

协议、编解码器和容器格式是流媒体的独立方面。
在流媒体领域，一个常见的混淆源与视频流传输协议和编解码器之间的区别有关。
简单来说，“编解码器”一词是指视频压缩技术。不同的流媒体编解码器通常用于不同的目的。例如，Apple ProRes通常用于视频编辑。H.264是最常见的视频编解码器，广泛用于在线视频。
与编解码器一样，在视频流传输协议的上下文中，“格式”这个词也可能令人困惑。在许多情况下，“格式”只是指视频文件的容器格式。常见的容器格式包括.mp4、.m4v和.avi。
本质上，容器格式的功能类似于一个“盒子”，通常包括一个视频文件、一个音频文件和元数据。然而，对于直播流媒体来说，容器格式并不是一个核心概念。
为了更容易理解编解码器、容器格式和流媒体协议之间的关系，我们来做一个比较的例子。
假设你是一名商人，并且要大量运输服装（服装代表视频内容）：

• 流媒体编解码器相当于将服装压缩成一个捆绑包以节省空间的机器。
• 容器格式是这些捆绑包装在内的集装箱。
• 流媒体协议类似于铁路轨道、信号和驾驶员，将它们运送到目的地。

作为一个直播广播员，您希望您的直播视频内容与编解码器、容器格式和视频流传输协议相配合。值得注意的是，大多数视频流传输协议只支持特定的编解码器。

好的，介绍完基本的概念，接下来让我们来认识一下常见的一些协议吧！

---

RTMP

什么是RTMP？

Real-Time Messaging Protocol（RTMP）是一种通信技术，可以通过互联网实现实时视频流传输。它基于传输控制协议（TCP）技术，最初由Macromedia为其Flash Player开发，后来在被Adobe收购后成为Adobe Flash Player。

最初，RTMP主要用于在托管服务器和视频播放器之间传输内容。而今天，它的作用有些不同。在现代的直播流设置中，RTMP在流媒体服务器上的主要作用是从编码器向在线视频主机传递内容。这个过程被称为“摄取”。

在直播流中，RTMP的新角色很重要，但从原来所做的工作来看也有些缩小了范围。它具备低延迟流传输的能力，这对于在实时流传输重要事件的广播者来说是一个巨大的优势。它还以其最小的缓冲区域而闻名，真正提升了用户的体验。RTMP流传输是传递低延迟，无缓冲区的流媒体内容的最佳方法之一。

RTMP技术也在自适应比特率流传输以及一些网络会议工具中起到了作用。有几种不同用途的RTMP协议变体，我们将在本文中进一步讨论。

RTMP的特性

这段文字介绍了RTMP的一些基本信息，帮助读者更好地理解这种协议及其在视频内容中的作用。
RTMP是一种实时流协议，用于将视频文件从编码器传输到在线视频托管平台。
RTMP及其变体通过TCP和UDP（用户数据报协议）进行流传输，不使用HTTP协议（HLS等标准协议使用）进行流传输。
RTMP支持音频编解码器，如AAC和MP3。x264通常用于RTMP编码，但也支持其他编解码器。
RTMP拉流支持使用低成本的编码工具。
在Dacast上，RTMP拉流自动支持iOS、Android和所有浏览器上的HLS转换。
RTMP有几个不同的变体。尽管RTMP在技术上已被淘汰，但在不同的广播工作流程和上下文中仍可与某些转码器一起使用。

RTMP的三个主要成分

RTMP是一种用于直播流的协议，包括三个主要组成部分，每个组成部分都在直播流程中具有特定的作用：RTMP服务器、RTMP客户端和RTMP协议。
RTMP服务器作为中心枢纽，处理传入的流并将其分发给连接的客户端，管理媒体数据流，处理身份验证，并确保服务器和客户端之间的流畅传输。
RTMP客户端负责从服务器接收实时视频和音频流，并将其呈现给最终观众，客户端可以是Web浏览器、移动应用程序或专用的流媒体软件。
RTMP协议定义了通过网络传输媒体内容的规则和机制，它使实时通信成为可能，支持自适应比特率流媒体，并促进了服务器和客户端之间控制消息的交换。

为什么RTMP现在使用得少了？
RTMP正逐渐退出历史舞台，原因有几个方面。首先，RTMP是Adobe拥有的专有协议，而Adobe已经宣布将于2020年底停止支持Flash Player，这意味着RTMP也将面临困境。虽然仍有许多流媒体平台和机构使用RTMP进行直播，但现代Web浏览器更广泛地支持WebRTC和HLS等开源替代方案，这些替代方案提供了类似的功能。

使用RTMP直播的整个流程

这段文本详细说明了应用RTMP进行直播流程的一般步骤。

1. 首先，使用摄像机、麦克风或专业广播设备捕获视频和音频内容，将其编码为适合传输的数字格式。
2. 然后，广播人员配置RTMP服务器，指定流密钥、访问控制和流媒体质量参数等必要设置。
3. 接着，设置广播软件（如OBS或Wirecast）以建立与RTMP服务器的连接，并处理直播内容的编码、打包和传输。
4. 随后，广播人员通过配置的广播软件发起直播流，与RTMP服务器建立连接，服务器接收并准备内容进行分发。
5. 观众可通过不同平台（如网站、社交媒体平台或专用流媒体应用程序）访问直播流，客户端接收从服务器传回的流媒体数据，使他们实时观看直播内容。
6. 在直播流中，观众可以通过聊天、评论、点赞和交互叠加等功能来主动参与内容和其他参与者之间的互动，从而增强直播观感。
7. 在直播结束后，广播人员通常可以选择将记录的流媒体数据进行存档以备后续观看。此功能使得观众可以按需查看以前的直播内容

RTMP拉流过程

第一步：握手 握手阶段涉及客户端和服务器之间的一系列快速交换。首先，客户端发送称为“头部”的消息，这实际上是一种密码签名。在头部发送后，客户端立即发送1536个字节的随机数据。
然后，服务器以同样的方式进行响应：它们先发送一个头部，然后立即发送1536个字节的随机数据。最后，客户端将服务器的随机数据的一个副本发送回给服务器，然后服务器将客户端的随机数据的一个副本发送回给客户端。这完成了握手。
第二步：连接 握手完成后，连接阶段生效。连接阶段涉及使用AMF（Action Message Format）编码进行数据交换。这在客户端和服务器之间建立了一种通信标准，包括有关视频播放、帧尺寸和带宽等常规规格。
第三步：流 一旦建立了连接和通信标准，流就开始启动。在这个阶段，可以执行如播放和暂停这样的重要用户命令。

AMF是什么？
AMF是一种二进制序列化格式，主要用于在Adobe Flash应用程序和服务器之间交换数据。它还序列化对象图，例如XML数据。虽然它最初是为Adobe Flash开发的，但AMF现在在许多服务器端环境中得到支持。
AMF在RTMP中继续发挥的作用与其在Flash中的作用基本相同。它是一个机制，允许客户端向服务器发送命令。

RTMP是否被淘汰了？

虽然Flash可能已经被淘汰，但RTMP并没有完全消失，只是被淘汰了普遍用途。在广播领域，出于多种原因，老的标准和格式在专业设施中通常仍然在使用。其中一个原因是当仍然有用的技术被公众淘汰时，它的盗版风险可能更小。尽管Adobe Flash播放器（最初使用该协议的视频播放器）已经几乎淘汰，但RTMP本身在直播流转换的其他角色中仍然非常有价值。
Adobe Flash Player已不再获得Adobe的支持，并且大部分被HTML5视频播放器所取代。正如我们所提到的，RTMP曾用于将Flash播放器连接到RTMP传输服务器。现在，HLS协议已经取代了RTMP来执行这个任务。
总的来说，RTMP传输已经过时了，但是RTMP数据拉取用于HLS仍然有用。
RTMP在直播、流媒体数据领域仍然非常重要，尽管它以前的主要应用案例正在迅速淘汰。

RTMP的几个变种

RTMP有几个变种，包括RTMP proper、RTMPS、RTMPE、RTMPT和RTMFP。在直播流领域，这些视频协议之间的服务略有不同。
让我们来看看这些流协议变种各有什么优缺点。

1. RTMP RTMP proper是RTMP协议最古老的版本。这是由Macromedia（后来是Adobe）开发的流媒体格式，为本列表上的其它标准奠定了基础。
2. RTMPS RTMPS流使用SSL证书来生成更安全的流。像YouTube这样的大型流媒体平台仍在使用RTMP的这种变种，以保护在公共互联网服务器上直播的直播者。
3. RTMPE RTMPE是Macromedia最初开发的另一种安全流媒体方法。尽管它在2022年仍有限制使用，但它不使用SSL安全证书（这仍然是保护互联网数据和内容的主要标准之一）。
4. RTMPT RTMPT是通过隧道传输流媒体视频。隧道是一种通过公共网络发送私有数据的方法。虽然在特定的上下文中这可能有用，但也已知会在传输流程或工作流程中引入更多的延迟。
5. RTMFP 即时媒体流协议（RTMFP）是建立在UDP而不是TCP上的RTMP变种。这项技术是许多视频会议工具和许多具有视频直播聊天功能的社交媒体平台和应用程序的基础。为什么这个协议在这种情况下比较受欢迎是因为它需要更少的数据，从而使带宽成本更合理。

RTSP 和 RTMP的区别？
RTSP是实时流传输协议（Real-Time Streaming Protocol）的缩写，是另一种用于在线音频、视频和数据流传输的协议。它比RTMP使用得少得多，但仍然很重要。
它们之间的主要区别是它们各自负责直播流程的哪一部分。RTMP将视频从编码器传输到视频播放器，而RTSP则控制浏览者、流媒体服务器和视频播放器之间的命令。

HLS

什么是HLS？

**HTTPS Live Streaming(HLS)**是由苹果公司开发的一种协议，用于与HTML5视频播放器进行流媒体传输。
需要澄清的是，HLS传递到HTML5视频播放器已经取代了RTMP传递到Adobe Flash播放器。
在现代大多数流媒体设置中，HLS是绝对必要的，因为HTML5视频播放器是唯一一种普遍兼容的视频播放器。由于HTML5视频播放器具有如此多的好处，大多数广播公司认为它是唯一可行的选择。
由于HLS与HTML5视频播放器配合使用，它能够将流媒体传输到几乎任何联网设备上。
除了极佳的兼容性外，HLS还具有其他几个优点。HLS非常安全，并且它可以产生高质量的流媒体。
该协议还支持自适应比特率流媒体，在专业的广播级别上非常重要。除了是自适应的外，HLS还具有动态性。这意味着在任何时刻，每个单独观众的流媒体比特率都将根据连接条件进行调整。
HLS可用于传递和采集，但由于它与大多数编码器不兼容，因此目前更注重于传递。
还需要指出HLS的一个主要缺点：当单独使用时，它会导致15-30秒的延迟，这意味着HLS传递/HLS采集组合不能像一些其他设置一样具有低延迟的流媒体传输能力。

HLS如何工作？

一个HLS流来自一个储存媒体文件的服务器，如果您使用点播流媒体，也来自一个用于直播流的服务器，任何普通的网络服务器都可以产生流。
服务器本身有四个不同的处理过程：
编码：HLS使用H.264或H.265编码。视频数据使用这两种编码方法重新格式化，以便其他设备能够识别和解释数据。
分段：视频被分成小的段，每个段的平均长度为6秒，但这可能会有所变化。这使内容更容易、更快速地传输。
索引文件：接下来，HLS创建一个索引文件。索引文件记录了从第二步中创建的所有小段的顺序。
复制段：最后，HLS将在不同质量级别(如420p、720p、1080p等)上创建重复的段，以便观众可以在不同的质量级别上访问视频。如果您提供HLS中的自适应比特率流，则这是必需的。

HLS自适应码率

Adaptive Bitrate Streaming in HLS（HLS自适应码流），是一种在HTTP Live Streaming（HLS）协议中实现的自适应码流技术。这种技术可以根据用户的网络环境的变化来自动调整流媒体的比特率和分辨率，以保证观看体验的连续性和流畅性。当网络环境不稳定或带宽不足时，自适应码流技术可以降低流媒体质量以避免停止缓冲，当网络环境稳定时，它可以提高流媒体的质量以提高观看体验。在HLS协议中，自适应码流技术使用了多个具有不同比特率和分辨率的媒体流，称为码流变体（Variant Streams），用户可以根据需要选择合适的码流变体。

HLS拉流时编码

HLS流媒体用于将视频内容传递到HTML5视频播放器。然而，HLS拉流（HLS ingest）是指从相机或其他媒体来源向编码器摄入内容。
如果您正在使用HLS进行拉流，必须使用HLS编码器。HLS编码器是用于HLS拉流编码的工具。HLS拉流和HLS流媒体是两个不同的功能，不应混淆使用。
目前，HLS尚未成为拉流的标准协议。这是因为HLS拉流存在一些延迟问题。由于HLS不是这个角色的主要协议，因此HLS编码器有些难以获取。

RTMP和HLS结合使用方案

目前，将RTMP摄入和HLS流媒体组合在一起是最优浸入式直播流媒体设置，原因有几点。这一组合为您提供了HLS兼容性和安全性以及RTMP低延迟和易访问性。
例如，Dacast在线视频平台使用RTMP摄入直播流。然后，我们的平台将直播视频内容转换为HLS流媒体协议。
最后，该流媒体内容通过顶级CDN（如Akamai和Limelight）到达您的观众。与RTMP不同，HLS兼容大多数浏览器和设备，无需Flash插件。

HLS编译器设置

您的流媒体配置设置将影响您的流媒体结果。因此，更深入地理解HLS编码器配置可以让您作为发布者获得更好的洞察力。
让我们来看看每个术语的含义以及它们与流媒体的关系。

1. 最佳HLS编解码器选项 编解码器（Codec）是“编码器-解码器”的缩写，是使编码成为可能的技术。在直播流媒体中，您将同时使用音频和视频编解码器。

目前，对于HLS流媒体而言，H.264视频编解码器是效率最高的。X.264编解码器是同一协议的另一种实现，因此也是可行的选项。您可以选择其中任何一个。在某些情况下，X.264可能使用更少的处理能力，但差异很少。
还有一个额外的细节需要记住。H.264标准实际上是一系列标准，称为“profile”。其中有很多个这些profile，但您只需要关注两个。
如果您以720p分辨率或更低的分辨率播流，视频比特率在350-800 kbps之间，请使用“Main”协议。如果您以1080p全高清的分辨率播流，视频比特率在800-4500 kbps之间，请使用“High”协议。
至于最佳音频编解码器，您应该选择AAC或AAC-LC。

比特率与视频分辨率的关系
比特率（Bitrate）指的是每单位时间内视频/音频流中的数据量。这通常以千比特每秒（kbps）或兆比特每秒（Mbps）为单位。一 Mbps等于1000 kbps。
更高的视频分辨率需要更多的数据。要给您一个大致的数字，一个低质量的240p直播流可能需要大约400 kbps。一个完整的1080p全高清直播通常需要4-8 Mbps。以下是各种分辨率的推荐视频比特率：
240p：350 kbps
360p：350到800 kbps
480p：800到1200 kbps
720p：1200到1900 kbps
1080p：1900到4500 kbps
720p的比特率要求比更高的分辨率要低。随着视频分辨率的提高，所需比特率的数量也会增加。
音频比特率比较简单。我们建议始终使用至少128 kbps和音频采样率为48 kHz（48,000 Hz）。
多比特率流媒体使观众可以获得他们的情况下最佳的视频质量。请查看我们的多比特率流媒体设置教程，以获取更多信息。

我们通常建议，您的上传速度应大约是视频和音频的总合带宽的两倍。如果您采用多比特率流媒体，则应考虑所有流媒体的总带宽。多比特率流媒体需要更强的互联网连接。
在互联网连接速度不足的情况下，尝试在流媒体上传太多数据可能会导致您的直播流失败。
为了选择正确的比特率，请将您的互联网连接的稳定上传速度除以二。这是您可以使用的带宽量。例如，10 Mbps的上传速度将为您提供5 Mbps的带宽。
在这种情况下，我们建议使用以下设置发送多比特率流：
2.5 Mbps的720p流
1Mbps的480p流
500 kbps的360p流
300 kbps的240p流
这将确保无论是有快速互联网连接的人还是有慢速互联网连接的人，都可以获得可靠的流媒体。

WebRTC

实时视频流媒体技术变得比以往任何时候都更加重要。对此技术的需求增加与商业、组织和个人的视频会议大规模转向有关。
自从COVID-19相关封锁措施实施以来，许多日常活动和特别活动都变成了虚拟活动。虽然相对低延迟的直播对于较大规模的活动已经可行，但涉及与观众进行交互或参与的较小规模的活动，则依赖于具备实时或超低延迟的点对点（peer-to-peer）流媒体技术。
Web实时通信（WebRTC）使点对点流媒体成为可能。

点对点视频的崛起

点对点通信是指任何即时数字通信方式，例如文字信息、电话和社交媒体聊天，都属于这种范畴。点对点视频会议就是两个人在远程位置上进行摄像头对话。
十年前，Skype和Facetime是面向消费者提供的最早的视频通话选项之一。从那时起到现在，我们喜爱的更多流媒体应用程序帮助我们与世界各地的朋友、家人和同事联系。Facebook、Snapchat、WhatsApp等平台为用户提供了直接在应用程序中进行视频通话的能力。
由于COVID-19传播导致个人之间的互动不再可能，点对点会议使世界保持了可运转状态。重要的会议和活动被迫转移到了在线平台。人们出于不同的原因需要面对面的联系，而视频会议使这成为可能。会议、课程甚至医生的约会都可以通过视频进行。
点对点视频会议在一定程度上与直播有所不同，因为直播通常是单向的，在屏幕另一侧的观众无法进行回应。
由于直播通常是向数百、数千或数百万观众广播，他们依赖于传递其内容的技术有一些不同之处，并且具有一定的延迟。大型直播通常使用RTMP和HTTP实时流媒体（HLS）的组合进行传输。然而，点对点视频流媒体使用WebRTC技术。

什么是WebRTC？

Web Real-Time Communication（WebRTC）是谷歌创建的一项流媒体项目。这个开源项目旨在支持谷歌在2010年收购视频会议和VoIP技术公司Global IP Solutions。WebRTC项目于次年开始启动。
在接下来的几年中，该项目被应用于几个其他网络会议项目中进行测试。2014年，WebRTC在Google Hangouts中以有限制的方式实现。开发人员在项目中经历了许多成功和失败。他们收到了许多反馈，帮助他们完善技术。
WebRTC项目的第一个稳定版本于2018年5月发布，2021年1月，WebRTC获得了W3C推荐。

Web实时通信(Web Real-Time Communication，WebRTC)是为支持网络会议和VoIP(“互联网语音传输协议”)而创建的流媒体项目。它由谷歌收购并进一步开发，使点对点流媒体与实时延迟成为可能。
WebRTC是一个开源项目，这使得开发人员能够使用该技术将流媒体纳入其软件中。
虽然WebRTC在技术上是一个项目，但它通常与协议捆绑在一起，因为它们的功能非常相似。
自从疫情爆发以来，WebRTC变得非常重要，因为实时延迟的流媒体对于许多行业保持一定程度的正常运作是至关重要的。视频会议让许多企业和学校在无法进行面对面会议时继续运营。
目前，WebRTC支持谷歌会议(Google Meet)，这是谷歌开发的网络会议工具。它也被其他具有视频会议功能的流行工具使用，如Slack、Whatsapp、Discord和Snapchat。
除了具有实时延迟的流媒体功能外，WebRTC非常安全。它采用SRTP和其他金标准安全措施进行加密。与HLS一样，WebRTC能够进行自适应比特率流媒体传输，因此您可以提供多个流的不同版本，为每个观众提供最佳质量的流。
WebRTC还以其可定制性和适应性而闻名。它还能够向大多数浏览器和设备传输流媒体。这些特点的结合使得WebRTC成为一个不错的选择。

WebRTC的工作原理

WebRTC负责点对点会议的两个主要方面。首先，它负责在您的设备上进行媒体捕获。这意味着WebRTC是告诉您的设备开始录制的技术。其次，它负责在两个设备之间传输数据。
WebRTC的基础是一系列JavaScript API。三个主要的API包括“getUserMedia”、“RTCPeerConnection”和“RTCDataChannel”。
“getUserMedia”通过与用户设备上的摄像头和麦克风建立连接来帮助用户捕捉音频和视频内容。 “RTCPeerConnection”促进了同行设备之间的音频和视频传输。此API还处理通话的安全性并管理正在使用的带宽量。 “RTCDataChannel”允许设备之间发送任意数据。
WebRTC可以集成到不同的站点和程序API中。这种结构消除了需要额外的程序或插件来使用即时会议技术的需要，这使得它对开发者非常有价值。
需要指出的重要一点是，WebRTC无法检测其他设备发出的想要发起Web会议的信号。它只是在连接建立后协助进行会议。

WebRTC工作场景

WebRTC主要用于点对点通信，特别是在网络会议中。WebRTC支持通过互联网进行视频和音频通话的程序。这可以用于从与朋友的视频聊天到与企业高管团队的会议电话等重要事项。
WebRTC正在逐渐进入在线视频流。未来通过RTMP和HLS协议传输的流可能会使用WebRTC传输。这将使在线视频平台能够提供无延迟的流。
实时延迟的流对于报道正在被其他网络覆盖的事件的广播公司具有竞争优势。这将使他们能够以技术上可能的最快速度向他们的观众传递事件。
WebRTC对于涉及观众实时参与的虚拟活动也非常有价值。超低延迟或实时延迟的流允许他们更加投入和参与，从而创造更加逼真的体验。

WebRTC的优点

WebRTC项目对于希望将点对点会议纳入其站点或程序的开发人员提供了许多价值。让我们看看这个项目能提供什么。

• 超低延迟/实时延迟

WebRTC的主要优点是它能够支持低延迟流。事实上，WebRTC能够进行实时流，这意味着几乎没有延迟。

• 开源

WebRTC的开源性质使得开发人员能够很容易地将实时网络会议纳入其站点或程序中。只需集成几行代码即可。

• 免费

WebRTC完全免费，这使得它非常易于接近。开发人员可以通过尝试这个项目来进行实验，而不需要做出任何财务承诺，这是一个双赢的局面。

• 超兼容性

这个项目与几乎每个设备或浏览器兼容。此兼容性比以往更令人满意，因为人们在各种设备上使用点对点会议。
需要指出的非常重要的一点是，该技术与移动设备完全兼容。这是非常重要的，因为许多人使用智能手机和平板电脑进行视频会议。

• 安全

起初，人们对WebRTC的安全性有一些担忧。但是现在，该项目使每次音频和视频交换都能够进行加密。这能够保护网络会议免受黑客窃听或拦截您的对话。
由于WebRTC加密正在交换的数据，因此可以安全地在公共WiFi网络上进行通话。
高质量的音频和视频 WebRTC能够进行非常高质量的网络会议。这意味着只要用户的网络速度快，就可以进行具有极佳音频和视频质量的通话。

• 自适应

WebRTC能够进行与自适应比特率流相当的技术。该技术根据网络速度进行自适应，以成功地传递音频和视频会议的语音和视频。

• 与其他技术的互通性

WebRTC的另一个优点是与其他通信技术（包括VoIP和视频）的互通性。这意味着WebRTC能够成功与使用其他基于互联网的通信技术的程序进行通信。

• 仍在发展中

虽然WebRTC是真正可靠的点对点会议技术，但它尚未达到最终形式。WebRTC可能会继续发展以改进其当前功能，并可能在不同类型的流媒体中变得更有价值。

---

WebRTC vs HLS vs RTMP

RTMP、HLS 和 WebRTC 各自在直播流媒体中扮演着独特的角色。它们的共同点是能够以实时或尽可能接近实时的方式传输数据。因此，你经常会看到关于 WebRTC vs RTMP 或 WebRTC vs HLS 的比较。
虽然你知道每种技术的功能，但你可能仍然想知道哪种技术最适合直播流媒体。答案是：取决于具体情况。
不同的情况需要独特的流媒体设置和协议。目前，在许多流媒体设置中，HLS 传递与 RTMP 采集是首选的组合。因为它满足了低延迟、极高的兼容性和实惠的要求。
HLS 传递可以与 HLS 采集一起使用，但目前编码器和相关技术对 HLS 采集的支持并不普遍。
在经济上，这并不是说协议本身的成本更高还是更低。而是不同协议或设置与之兼容的设备可用性和价格的问题。
另一方面，WebRTC 变得越来越流行。然而，它仍然面临一个主要的限制：大多数编码器并不广泛支持它。其他流媒体软件，如制作和混合工具，也是如此。
虽然 WebRTC 的这个主要限制可以在使用摄像头捕获视频的点对点流媒体设置中忽略不计，但对于专业级别的广播来说，它存在重大问题。
在更多编码器和相关技术支持 WebRTC 和 HLS 的情况下，HLS 传递/RTMP 采集组合可能会成为专业广播行业的首选流媒体设置。
关于 WebRTC vs HLS，HLS 更受专业广播需求的欢迎。在 WebRTC vs RTMP 方面，需要理解 HLS 与 RTMP 是相互协作的，因此不存在直接的 WebRTC vs RTMP。
此外，值得注意的是，这些协议只是众多可用选项中的几个。 RTSP 和其变体通常也被用于流媒体传输。它们通常会添加略微不同的功能，使其更适用于不同的用例。

SRT

什么是SRT？

安全可靠传输（SRT）是Haivision推出的一种相对较新的视频流传输协议，该公司是在线流媒体行业的领导者之一。这个开源协议以其突出的安全性、可靠性、兼容性和低延迟流媒体的能力而著名。它是一种出色的实时流媒体协议。
目前在使用SRT进行流媒体传输时存在一些限制，因为其他流媒体硬件和软件尚未开发出支持这种视频协议的功能。

谁应该使用SRT？

SRT是许多SRT联盟成员的首选协议。这是技术和电信领域的一组公司，致力于将SRT推向直播行业的前沿，因为他们认为它是视频流传输的最佳协议。
SRT联盟由Haivision成立，这是开发视频流协议的同一家公司。SRT联盟的一些重要成员包括微软、Telestream、阿里云、康卡斯特、欧洲电视台和AVID等。
如果您使用的技术得到SRT联盟成员任何一个的支持，您应该能够轻松地将SRT视频流传输协议纳入到您的流媒体设置中。

使用SRT的优点：

• 安全：SRT包括顶级的安全和隐私工具，使广播公司可以放心地保持流的安全性和稳定性。
• 兼容：SRT是设备和操作系统无关的，这意味着它可以将流媒体传递到大多数互联网设备。
• 低延迟：低延迟流媒体是专业广播公司的主要附加值。SRT通过支持纠错技术实现低延迟流媒体。

使用SRT的缺点：

• 尚未广泛支持：像WebRTC一样，SRT仍然有点不现实。在这种视频协议成为标准之前，流媒体行业需要赶上它。

RTSP

什么是RTSP？

RSTP（Real-Time Streaming Protocol）或许是一种不太为人所知的视频流协议，实时流媒体协议（RTSP）最早于1998年发布。RTSP的开发目的是控制娱乐和通信系统中的流媒体服务器。
在2016年，更新的RTSP 2.0发布。总的来说，它是一种用于在端点之间建立和控制媒体会话的视频流协议。
在某些方面，RTSP与稍后将要介绍的HTTP实时流媒体（HLS）协议类似。然而，单独使用RTSP并不能传输实时流媒体数据。相反，RTSP服务器通常与实时传输协议（RTP）和实时控制协议（RTCP）一起工作，以提供媒体流。它是一种实时解决方案，需要与其他视频流协议协同工作。

什么场景使用？

RTSP旨在支持低延迟流媒体，是流媒体用例（例如IP摄像头数据源（例如安全摄像头）、IoT设备（例如计算机控制的无人机）和移动SDK）的良好选择。但它并不适合在互联网上向许多观众进行高质量实时流媒体传输。

优缺点

使用RTSP的优点:

• 分段流：

与要求观众在下载完整的视频后再观看不同，RTSP流允许他们在下载完成前观看您的内容。

• 自定义：

通过利用其他协议，如传输控制协议（TCP）和用户数据报协议（UDP），您可以创建自己的视频流应用程序。

使用RTSP的缺点：

• 较不流行：

与其他媒体流协议相比，RTSP要少得多。大多数视频播放器和流媒体服务不支持RTSP流，这使得在浏览器中广播您的流更加困难。要广播RTSP流，您必须使用单独的RTSP实况流服务。

• HTTP不兼容：

像RTMP一样，您不能直接通过HTTP流式传输RTSP。因此，在Web浏览器中流式传输RTSP没有简单明了的方法，因为RTSP更适合于在私有网络上流式传输视频，例如在企业内部的安全系统中。但是，您可以使用嵌入到网站中的其他软件来流式传输RTSP。

MPEG-DASH

什么是MPEG-DASH？

MPEG-DASH具有自适应流媒体功能，对于专业广播公司来说非常有价值。

首先，它支持自适应比特率流式传输。这意味着观众将始终接收到其当前互联网连接速度所支持的最佳视频质量。这种速度往往会每秒钟波动，而DASH可以跟上这种变化。
MPEG-DASH解决了传递和压缩方面的一些长期存在的技术问题。另一个优点是，MPEG-DASH是“编解码器不可知的”，这意味着它可以与几乎任何流编码格式一起使用。它还支持加密媒体扩展（EME）和媒体源扩展（MSE），它们是基于标准的API，用于基于浏览器的数字版权管理（DRM）。
最后，我们提到MPEG-DASH。虽然它尚未广泛使用，但这种视频协议具有一些重要优势。

优缺点

使用MPEG-DASH的优点：

• 自适应

DASH之所以保持与时俱进，是因为它支持自适应比特率流式传输，这非常适合将高质量流媒体传输到具有不同互联网速度的用户

• 开放源代码：

MPEG-DASH是开放源代码和无提供商，这意味着用户可以自定义它以符合其特定需求
使用MPEG-DASH的缺点：

• 受限支持：

MPEG-DASH不兼容苹果设备/ iOS，这可能会对广播公司造成相当大的问题

• 很难预测未来：

虽然曾经有希望DASH成为首选协议的未来，但这种机会越来越渺茫

Http-Flv

什么是Http-Flv？

首先我们先得知道什么是flv，FLV（Flash Video）是 Adobe 公司推出的一种媒体文件格式，是一种非常常见的音视频封装格式，尤其是在流媒体场景中。
在直播领域，目前我们国内通常采用 RTMP 推流，HTTP-FLV 播放的方案。
HTTP-FLV是一种音视频流传输协议，它是基于HTTP协议实现的，主要用于实现音视频实时传输和直播，同时具有广泛的兼容性和灵活性。使用HTTP-FLV协议进行直播，可有效降低直播的流媒体服务器及带宽的成本，同时具有较好的容错性和协议稳定性。
HTTP-FLV协议主要工作流程如下：

1. 客户端向服务器发送HTTP请求，请求一个标准的FLV文件。
2. 服务器接收到请求后，将实时音视频数据打包成FLV格式的数据包发送给客户端。
3. 客户端接收到FLV数据包后，使用Flash Player或者基于H5的视频播放器等方式进行播放。

相对于传统的RTMP协议，HTTP-FLV协议需要的带宽资源更少，同时可以更好地应对防火墙等网络障碍，适应性更强，因此具有更广泛的应用价值。目前，许多视频直播服务平台和开发者都采用HTTP-FLV协议进行音视频直播服务。

具体这个协议的历史，目前我也找不到资料，如果大家有知道的，欢迎在评论区分享。

HTML5内核播放器 flv.js
这个是bilibili开源的一款HTML5播放器。
flv.js 做了三件事：

1. HTML5 原生仅支持播放 mp4/webm 格式，flv.js 实现了在 HTML5 上播放 FLV 格式视频
2. 使 Bilibili 网页端平滑过度到 HTML5 播放器，历史遗留不再是障碍
3. 对于视频直播，在 HTML5 上支持了延迟极低 HTTP FLV 播放，解开网页端直播对 Flash 的依赖

如何选择这么多协议？

简单回顾一下，今天存在许多视频流协议，其中许多可以用于实时视频流。当涉及到使用哪种协议来流媒体传输时，答案是根据您的具体需求而定。
就我们上面讨论的所有协议而言，这些协议都适用于特定的广播公司。然而，考虑到所有因素，特别是在编解码器兼容性、所有设备兼容性、HTML5视频播放器本地支持和自适应比特率流式传输能力方面，HLS更具优势。
我们的建议很简单：目前，大多数广播公司应该坚持使用HLS进行传输，使用RTMP进行摄入。 在最佳视频流协议方面，我们选择HLS。
当然，某些用户可能会发现其他协议更适合他们的需求。然而，无论您想在网站上流式传输实时视频，进行体育赛事的实时流媒体，还是实时广播专业活动和集会，HLS通常是最佳选择。
请密切关注SRT和WebRTC，因为它们未来将成为在线流媒体行业的重要发展方向。

---

总结

好啦，以上就是我们今天要介绍的全部内容，希望能帮助你。

如果大家还有什么问题，欢迎私信或者在评论区提出来，让我们一起学习进步！！！

---

参考链接

参考：
https://www.dacast.com/blog/rtmp-real-time-messaging-protocol/
https://pengrl.com/lal/#/?id=%e2%96%a6-%e4%b8%80-lalserver-%e7%ae%80%e4%bb%8b
https://zhuanlan.zhihu.com/p/191542130
https://www.dacast.com/blog/encoder-settings-hls-live-streaming/
https://www.zhihu.com/question/5199737