一、引言

       在线教育平台利用一切线上工具进行教育活动，采用网络先进技术改变师生的交流方式，进一步提高学生掌握知识的效率。随着在线教育直播平台的如火如荼，我们有必要对直播平台相关的基础知识点有一个系统性的了解。如图一所示。

                

二、流媒体协议

         可用于视频直播的流媒体协议包括：NDI、SRT、RIST、CMAF、HLS、DASH、HTTP-FLV、RTSP、RTMP、WebRTC。下面将一一介绍。

2.1 NDI

    NDI(Network Device Interface,网络设备接口协议)是NewTek公司于2015年推出的，是一种基于局域网络的信号传输协议。使用NDI传输技术，在局域网内的一个设备可以通过一条网线输出或者接收多个NDI信号，可完全取代传统SDI/HDMI视频线传输，它让视频在IP空间进行简捷高效的传输成为现实。音视频信号在进行NDI编码后，能实时通过IP网络对多重广播级质量信号进行传输和接收，同时具有低延迟、数据流相互识别与通信等特性。 

2.2 SRT

SRT（Secure Reliable Transport，安全可靠的传输）是新一代低延迟视频传输协议，是一套开源的应用灵活的规范。它的性能与专用的协议一样优秀，同时能够在不同制造商生产的产品之间工作。SRT是一种能够在复杂网络环境下实时、准确地传输数据流的网络传输技术，SRT协议建立在开源的UDT（UDP-based Data Transfer Protocol，基于UDP的数据传输协议）之上，具备UDP速度快、开销低的传输特性，支持点对点传输，无需中间进行服务器中转，互联网点对点传输可小于1s。

SRT可广泛应用于节目远程制作、活动直播、互联网远程教学、集团公司对异地施工现场视频监管等领域，以及其他需要在互联网远程视频传输的场合。需要注意的是，SRT传输应用需要发送端或接收端任意一端具备固定公网IP地址。

2.3 RIST

RIST（Reliable Internet Stream Transport，可靠的互联网流传输协议），是由Video Services Forum (VSF) 于2017年初成立的小组，为协议创建公开的通用规范。

RIST的首选流传输协议是RTP配合RTCP。RIST需要两个端口：第一个端口用于传输媒体流；第二个端口使用RTCP创建控制界面。RTCP协议是双向的。相较于SRT（基于UDT非实时流媒体的技术栈构建），RIST一开始便使用较为成熟的RTP+RTCP 技术，而且它只定义了标准化的语法，允许厂家在此基础上进行扩展，又不会互相影响。

2.4 CMAF

CMAF（Common Media Application Format，通用媒体应用格式），由微软、苹果联合MLBAM、思科、Akamai和Comcast在2016年2月向动态图像专家组（MPEG）提出，并已被批准成为国际标准。CMAF是一种可扩展的编码标准，通过指定一致的媒体包装和加密来实现内容和设备之间的互操作性。

CMAF目标是将HLS和DASH格式结合在一起，以简化在线视频传输。与普遍看法相反，CMAF本身不会减少延迟，而是提供了一种低延迟模式，可以将媒体段划分为更小的块。与DASH和HLS不同，CMAF不是一种演示格式（presentation format），它是一种容器格式，可以包含一组音频/视频文件。

2.5 HLS

HLS（HTTP Live Streaming，基于HTTP的网络传输协议），由苹果公司提出。它和DASH 协议的原理非常类似，通过将整个流切割成一个个小的可以通过 HTTP 下载的媒体文件, 然后提供一个配套的媒体列表文件, 提供给客户端。让客户端顺序地拉取这些媒体文件播放, 来实现看上去是在播放一个文件的效果。HLS目前广泛地应用于点播和直播领域。

2.6 DASH

DASH(Dynamic Adaptive Streaming over HTTP，自适应流媒体协议)是在2011年底由MPEG和ISO共同制定的标准，通过HTTP共同影音档案通讯协定，可使高品质影音内容通过网路传送到网络电视、机顶盒及移动终端设备。

DASH采用服务端/客户端的流媒体解决方案。服务端将视频内容分割为一个个分片，每个分片可以存在不同的编码形式（不同的codec、profile、分辨率、码率等）；播放器端可以自由选择需要播放的媒体分片；不同画质内容无缝切换，提供更好的播放体验。

2.7 HTTP-FLV

Http-FLV（RTMP over HTTP，基于HTTP之上的RTMP），将流媒体数据封装成 FLV 格式，然后通过HTTP协议传输给客户端。

HTTP-FLV依靠MIME的特性，根据协议中的Content-Type来选择相应的程序去处理相应的内容，使得流媒体可以通过HTTP传输。优点：相较于 RTMP 协议，HTTP-FLV能够很好的穿透防火墙，它是基于 HTTP/80 传输，有效避免被防火墙拦截。除此之外，也可以通过HTTP 302跳转灵活调度/负载均衡，支持使用HTTPS加密传输。缺点：流媒体资源缓存在本地客户端，在保密性方面不够好。另外网络流量较大，也不适合做拉流协议。

    备注：FLV (Flash Video) 是 Adobe 公司推出的另一种视频格式，是一种在网络上传输的流媒体数据存储容器格式。其格式相对简单轻量，不需要很大的媒体头部信息。

2.8  RTSP

RTSP(Real-Time Stream Protocol，实时流传输协议)是由Real Network和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。

RTSP对流媒体提供了诸如暂停，快进等控制，提供了一个可供扩展的框架，使得流媒体的受控和点播变得可能，它主要用来控制具有实时特性的数据发送，但其本身并不用于传送流媒体数据，而必须依赖下层传输协议(例如：RTP/RTCP)所提供的服务来完成流媒体数据的传送。RTSP负责定义具体的控制信息、操作方法、状态码，以及描述与RTP之间的交互操作。如图二所示。

                                                                                                

2.9 RTMP

RTMP（Real Time Messaging Protocol，实时消息传输协议）是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的协议。这是一个标准的，未加密的实时消息传递协议，默认端口是1935。

RTMP基于TCP协议，而TCP协议实时性不如UDP，也非常占用带宽。目前基于UDP的RTMFP协议能很好的解决这个问题。备注：这个协议的播放依赖于Flash Player。如果没有这个播放媒介，这个协议就没有用武之地了。

使用场景如图三所示。

                                                                                                   

2.10 WebRTC

WebRTC（Web Real-Time Communication，网页实时通信）是一个由Google发起的实时通讯解决方案，其中包含视频音频采集，编解码，数据传输，音视频展示等功能。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。

WebRTC使用安全实时传输协议（Secure Real-time Transport Protocol，SRTP）对RTP数据进行加密，消息认证和完整性检查以及重播攻击保护。它是一个安全框架，通过加密RTP负载和支持原始认证来提供机密性。WebRTC不光支持Web之间的音视频通讯，还支持Android以及IOS端，此外由于该项目是开源的，我们也可以通过编译C++代码，从而达到全平台的互通。

内部协议栈如图四所示。

                                                                                                                  

2.10.1 信令，STUN，TURN和ICE

1） 信令

信令服务器负责端到端的连接，如SDP，Candidate等。元数据是通过信令服务器中转来发给另一个客户端，但是对于流媒体数据，一旦会话建立，首先尝试使用点对点连接。如图五所示。

信令（Signaling）是协调通讯的过程，信令处理过程需要客户端能够来回传递消息，这个过程在WebRTC里面是没有实现的，需要自己创建。一旦信令服务建立好了，两个客户端之间建立了连接，理论上他们就可以进行点对点通讯了，这样可以减轻信令服务的压力和消息传递的延迟。

为了建立一个WebRTC的通讯过程，客户端需要交换如下信息：

会话控制信息：用来开始和结束通话，即开始视频、结束视频这些操作指令。

处理错误的消息。

元数据：例如各自的音视频解码方式、带宽。

网络数据：对方的公网IP及端口，内网IP及端口。

2） STUN，TRUN和ICE

每个客户端都有一个唯一的公网IP地址，它能用来和其他客户端进行通讯和数据交换。然而现实生活中客户端通常位于一个或多个NAT（Network Address Translator）之后；或者一些杀毒软件还阻止了某些端口和协议，又或者在公司还有防火墙或代理等；防火墙和NAT或许是同一个设备，例如我们家里用的路由器。基于以上原因，由于获取不到公网的IP，导致两端用户不能直接找到对方。如何有效地穿透各种NAT（Network Address Translator）/FW(Fire Wall)成为一个问题。目前NAT类型主要分为完全锥型，地址限制锥型，端口限制锥型，对称型，每种类型数据交互模式也不同，需要记住对称型NAT会存在打洞失败的问题。这个时候就会用到STRN、TURN和ICE技术。

STUN相当于打洞服务器，是用来获取外网地址的。

TURN相当于转发服务器，是在打洞失败时进行转发的。

ICE（Interactive Connectivity Establishment，交互式连接建立），是一组基于Offer/Answer模式解决NAT穿越的协议集合。ICE主要包含STUN+TURN协议，TURN协议的主要作用就是用于NAT打洞失败后，利用Relay进行转发。ICE通过综合利用现有协议，以一种更有效的方式来组织会话建立过程，使之在不增加任何延迟同时比STUN等单一协议更具有健壮性和灵活性。

如图六所示。

                                                           

 2.10.2 DTLS、SRTP和SCTP

 2.10.2.1 基础概念

SRTP（Secure Realtime Transport Protocol，安全实时传输协议），主要用来传输对实时性要求比较高的数据。例如音视频数据。

SRTCP（Secure RTP Trasport Control Protocol，安全RTP传输控制协议），跟RTP在同一份RFC中定义，主要用来监控数据传输的质量，并给予数据发送方反馈。

SCTP（Stream Control Transmission Protocol，流控制传输协议），之前介绍过，(S)RTP/(S)RTCP主要用来传输音视频数据，是为了流媒体设计的。而对于自定义应用数据的传输，WebRTC使用了SCTP协议。

DTLS（Datagram Transport Level Security，数据报安全协议），提供了UDP 传输场景下的安全解决方案，能防止消息被窃听、篡改、身份冒充等问题。DTLS的主要用途就是让通信双方协商密钥，用来对数据进行加解密。在WeRTC中使用DTLS的地方包括两部分：一是DataChannel 数据通道，一个是RTCPeerConnection音视频媒体通道。在数据通道中，WebRTC完全使用DTLS来进行协商和加解密；在音视频通道中WebRTC使用SRTP来进行数据的加解密，DTLS的作用仅仅是用来做密钥交换，RTP/RTCP的数据加解密就交给了SRTP。

SDP（Session Description Protocol，会话描述协议），是一个用来描述多媒体会话的应用层控制协议，为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述；它是一个基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围；SDP完全是一种会话描述格式，它不属于传输协议，它只使用不同适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现。SDP文本信息包括：会话名称和意图；会话持续时间；构成会话的媒体；有关接收媒体的信息（地址等）。

WebRTC传输音视频数据相关协议：UDP、DTLS、RTP/SRTCP。

WebRTC传输自定义应用数据相关协议：UDP、DTLS、SCTP。

对WebRTC应用来说，不管是音视频数据，还是自定义应用数据，都要求基于加密的信道进行传输。DTLS有点类似TLS，在UDP的基础上，实现信道的加密。

       2.10.2.2 加密信道建立过程（DTLS）

通信双方：通过DTLS握手，协商生成一对密钥；

发送方：对数据进行加密；

发送方：通过UDP传输加密数据；

接收方：对加密数据进行解密；

2.10.2.3 音视频数据传输过过程（RTP/SRTP、RTCP/SRTCP）

通信双方：通过DTLS握手，协商生成一对密钥；

数据发送方：将音视频数据封装成RTP包，将控制数据封装成RTCP包；

数据发送方：利用加密密钥，对RTP包、RTCP包进行加密，生成SRTP包、SRTCP包；

数据发送方：通过UDP传输SRTP包、SRTCP包；

2.10.2.4 自定义应用数据传输过程（SCTP）

通信双方：通过DTLS握手，协商生成一对密钥；

数据发送方：将自定义应用数据，通过密钥进行加密，生成SCTP包；

数据发送方：通过UDP传输SCTP包；

2.10.3 RTCPeerConnection和DataChannel

RTCPeerConnection音视频媒体通道，是一个用于使WebRTC调用视频和音频流并交换数据的API接口集，代表一个由本地计算机到远端的WebRTC连接。该接口提供了创建、保持、监控、关闭连接的方法实现。一个RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。

DataChannel数据通道，表示一个在两个节点之间的双向的数据通道。RTCDataChannel数据通道是浏览器之间建立的非媒体的交互连接，即不传递媒体消息，绕过服务器直接传递数据。相比WebSocket、Http消息，数据通道支持的流量大、延迟低。

2.11 几款主流媒体协议对比

如表一所示。

三、编解码格式

可用于视频直播的编解码包括：音频编解码和视频编解码。

3.1  音频编解码格式

 3.1.1 Opus

Opus 是一个完全开源，通用性高的音频解码器。Opus 在网络上有着无与伦比的交互式语音和音乐传播功能，但也可以用来存储，在流媒体上使用。Opus 遵从 Internet Engineering Task Force (IETF) RFC 6716 标准，整合了 Skype's SILK 解码和 Xiph.Org's CELT 解码的技术。

新的WebRTC中默认是采用Opus编码，Opus编码是由silk编码和celt编码合并在一起，silk编码是由skype公司开源的一种语音编码，特别适合人声，适合于Voip语音通信。celt和mp3,aac类似，适合于传输音乐。

3.1.2  其它格式

如表二所示。

3.2 视频编解码格式

3.2.1 AV1

AV1是一个开放、免专利的影片编码格式，专为通过网络进行流传输而设计。它由开放媒体联盟（AOMedia）开发，该联盟由半导体企业、视频点播供应商和网页浏览器开发商于 2015 年成立。互联网工程任务组（IETF）也将这项工作标准化为互联网视频编解码器（NetVC）。AV1 的目标是取代其前身，即由 Google 开发的 VP9 视频压缩格式，并与动态图像专家组（MPEG）领导开发的高效率视频编码（HEVC）竞争。

AV1可以与Opus音频格式一起封装在WebM容器格式中，并可用于 HTML5 网络视频和网页即时通信。

AV1是一种使用传统的基于区块编码但也加入了新技术的频率变换格式，AV1 所使用的编码技术主要来源于谷歌VP9的下一代视频压缩格式 VP10，但同时也包含了由Xiph.Org基金会的主要赞助者Mozilla开发的Daala视频压缩格式和由Cisco开发的Thor视频压缩格式中所使用的视频编码技术。

 3.2.2 其它格式

如表三所示。

3.3 音视频容器

视频格式：mp4、rmvb、avi、mkv、mov...，其实是包裹了音视频编码数据的容器。用来把以特定编码标准编码的视频流和音频流混在一起，成为一个文件。例如：mp4支持H264、H265等视频编码/AAC、MP3等音频编码。

四、直播平台架构

 4.1 传统直播平台架构

RTMP+CDN模式，如图七所示。

                             

4.2 WebRTC架构

WebRTC虽然是一项主要使用P2P的实时通讯技术，本应该是无中心化节点的，但是在很多大型多人通讯场景，如果都使用端对端直连，端上很容易会遇到带宽和性能的问题。所以就有了下图的三种服务端架构，如图八所示。

建议：如果规模不大(5人以下) Mesh框架就够用了，毕竟实现简单；如果50人以下，且带宽有限，选择MCU比较适合；如果规模更大，且带宽良好，SFU相对更适合。

4.2.1 MESH服务端架构

Mesh每个端都与其它端互连。以上图最左侧为例：5个浏览器，二二建立P2P连接，每个浏览器与其它4个建立连接，总共需要10个连接。如果每条连接占用1M带宽，则每个端上行需要4M，下行带宽也要4M，总共带宽消耗20M。而且除了带宽问题，每个浏览器上还要有音视频“编码/解码”、CPU使用率等也是问题。一般这种架构只能支持4-6人左右，不过优点也很明显，没有中心节点，实现简单。

4.2.2 MCU服务端架构

MCU（MultiPoint Control Unit，多点控制单元）是一种传统的中心化架构(上图中间部分)：每个浏览器仅与中心的MCU服务器连接，MCU服务器负责所有的视频编码、转码、解码、混合等复杂逻辑。每个浏览器只要1个连接，整个应用仅消耗5个连接，带宽占用(包括上行、下行）共10M，浏览器端的压力要小很多，可以支持更多的人同时音视频通讯，比较适合多人视频会议。但是MCU服务器的压力较大，需要较高的配置。

4.2.3 SFU服务端架构

SFU(Selective Forwarding Unit，可选择转发单元)，见上图右侧部分：有中心节点服务器，但是中心节点只负责转发，不做复杂的逻辑处理，所以服务器的压力会低很多，配置也不象MCU要求那么高。但是每个端需要建立一个连接用于上传自己的视频，同时还要有N-1个连接用于下载其它参与方的视频信息。所以总连接数为5*5，消耗的带宽也是最大的，如果每个连接1M带宽，总共需要25M带宽，它的典型场景是1对N的视频互动。

4.2.4 WebRTC内部架构

WebRTC的内部架构，如图九所示。

最上层的带箭头的浅紫色部分是指开发者基于WebRTC技术规范所开发的应用程序。严格来说这并不属于WebRTC的架构内容。

中间的深紫色的Web API部分表示的是WebRTC开放给应用层开发人员调用的API(主要是JavaScript API供Web端使用),在这层中开发者无需关心复杂的底层技术，只需了解WebRTC的大致流程原理，调其API即可利用WebRTC实现点对点的通讯功能。

下方的绿色部分是WebRTC的核心功能层，这一层又被分为了四个子功能层。分别是C++API层、会话管理层、引擎层和驱动层。

客户端提供了Android和iOS的SDK，并支持Windows、MAC、Linux的浏览器。

五、开源项目

 5.1 RTMP开源项目

Nginx-RTMP

C++开源。基于Nginx的扩展，提供RTMP，HTTP-FLV ，HLS。

SRS

C++开源。功能提供RTMP，HTTP-FLV，HLS等。商业级服务端，支持多台服务器扩展。

EasyRTMP

C开源。结合了多种音视频缓存及网络技术的一个RTMP直播推流端，包括：圆形缓冲区(Circular Buffer)、智能丢帧、自动重连、RTMP协议等多种技术。

OBS

C++/QT开源。OBS(Open Broadcaster Software)是一款开源可以直接视频直播的软件。常常用在游戏直播中，软件支持串流、音频、视频等设置，能够让用户可以自由选择自己的直播模式。基于著名的开源项目FFmpeg(跨平台视频/音频流方案)。

5.2 RTSP开源项目

live555

C++开源。live555是重量级的一个流媒体开源项目，其中不仅包括了传输协议（SIP、RTP）、音视频编码器（H.264、MPEG4）等，还包括流媒体服务器的例子，是流媒体项目的首选。

VLC

C++/QT开源。跨平台媒体播放器，并集合先进的流媒体功能可以通过IPv4或IPv6的高带宽网络进行流媒体传输。它还支持多种视频格式和流协议。基于著名的开源项目FFmpeg(跨平台视频/音频流方案)。

5.3 WebRTC开源项目

如表四所示。

 

                                                                                                                         

————————————————

版权声明：本文为CSDN博主「Johnny-Xu」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/jz_x/article/details/113756871