音视频传输技术探讨

柳 欢

（安徽省广播电视科研所，安徽 合肥 230000）

0 引 言

随着信息技术的发展，在线点播、直播、视频聊天、远程会议等已成为常态，短视频平台强势增长，虚拟现实（Virtual Reality，VR）、增强现实（Augmented Reality，AR）、远程医疗等越来越多音视频应用场景被挖掘。音视频技术需要不断升级以支持新应用、新模式和新场景下的需求。

音视频技术是将声音或一系列静态影像等模拟信号转换成数字信号，再通过压缩编码、封装等一系列处理，发送给接收端，接收端再解封装、解码还原成音视频的技术。最初，人们获取音视频，需要将整个音视频文件下载到本地，再利用播放器播放，通常需要花较长时间等待音视频文件下载完成。随着技术的发展，出现了两种边下载边播放的技术，即超文本传输协议（HyperText Transfer Protocol，HTTP）渐进式下载和流媒体传输。其中，流媒体传输包括HTTP流式传输和实时流传输两种方式。

1 HTTP渐进式下载

HTTP渐进式下载的原理基于音视频文件的特点，即使用音视频文件的元信息和部分帧数据就可以实现解码播放。但通常音视频的元信息不一定放在文件的开头，如果按顺序接收文件，一开始可能无法获得元信息，就无法实现边下载边播放。因此，HTTP 1.1版本之后的协议增加了range-request请求，即在请求报文中有一个字段range来指定请求资源的字节范围。这样就可以跨字节获得音视频的元信息，从而实现边下载边解码播放。

MP4和FLV格式的文件对HTTP渐进式下载支持比较好[1]。通常，元文件在文件的末尾，所以一般会发送3个请求，具体实现步骤如下：第一个请求先从媒体文件0 Byte开始找元文件；如果没找到，则通过range-request发送第二个请求到媒体文件的末尾去找；找到元文件后，再发送一个请求从文件开头开始，这时媒体文件开始解码播放。如果媒体文件是经过优化的，元文件放在开头，则只需发送一个请求。

2 流媒体传输

流媒体传输原理是将音视频文件通过一定的算法编码压缩成一个个压缩包，再由流媒体服务器通过特定的网络协议进行连续、实时的传送，用户端接收到压缩包后再实时地解压缩播放。

其中，传输层的网络协议有用户数据报协议（User Datagram Protocol，UDP）和传输控制协议（Transmission Control Protocol，TCP）。使用UDP协议，可以实现低时延，网络出现分组丢失时，不会触发重传导致播放不流畅，适合对实时性要求较高的场景，比如实况转播等。另外，UDP协议是无序的，需要额外的协议如实时传输协议（Real-time Transport Protocol，RTP）、实时流传输协议（Real Time Streaming Protocol，RTSP）辅助传输，增加成本；还有可能会被防火墙阻拦。使用TCP协议，可以实现有序可靠传输，通常应用在对实时性要求较低的场景中。

在TCP/UDP之上的协议主要有HTTP、RTSP、实时信息传输协议（Real Time Message Protocol，RTMP）、RTP等。根据协议或者是服务器的不同，流媒体传输主要分为HTTP流式传输和实时流传输。HTTP流式传输，通过HTTP协议顺序下载文件，用户只能观看已下载的音视频内容，无法快进到未下载部分。实时流传输，需要保持音视频信号带宽与网络连接匹配，使音视频能够被实时看到，需要有专门的流媒体服务器与传输协议。下面分别介绍这两种传输方式。

2.1 HTTP流式传输

HTTP流式传输是通过HTTP协议传输音视频的。首先，在Web服务器端将音视频文件分割成一个个很小的独立切片，同时生成一个索引文件。索引文件记录着一个个切片的地址。客户端通过HTTP协议向服务器请求索引文件，再根据索引文件请求一个个切片文件，从而实现音视频文件的播放，传输流程如图1所示。

图1 HTTP流式传输流程图

HTTP流式传输具体实现主要有基于HTTP的自适应码率流媒体（HTTP Live Streaming，HLS）流式传输、基于HTTP的动态自适应（Dynamic Adaptive Streaming over HTTP，DASH）流式传输[2]、基于Adobe的HTTP动态（HTTP Dynamic Streaming，HDS）流式传输等。这里介绍下HLS流式传输和DASH流式传输。

2.1.1 HLS流式传输

HLS协议是由苹果公司针对移动端音视频接收而开发的，现在很多桌面应用也支持该协议，比如H5就支持HLS协议。

2.1.1.1 HLS流式传输原理

HLS流式传输要求视频编码格式为H264，音频编码格式为AAC、MP3、AC-3，封装格式为MPEG-2 TS。编码器将输入的音视频数据转换成支持的音视频格式，再封装为MPEG-2 TS格式文件，按一定的时间段（通常是10 s）切割成一个个ts文件，同一码率的ts切片地址形成一个二级索引文件。根据这些不同码率的二级索引文件地址再形成一个一级索引文件。索引文件的格式为m3u8。如果音视频文件只有一个码率，则只有一个索引文件。具体如图2所示。

图2 HLS音视频切片分割图

客户端通过HTTP协议请求一级索引文件，根据自身网络条件自适应地请求合适码率的二级索引文件，从该索引文件中获取适应码率的ts切片地址，再请求ts文件，进而实现音视频的播放。

2.1.1.2 HLS流式传输的应用

HLS流式传输通常应用在点播和直播中。其中，点播应用不需要更新索引文件，直播应用需要不断更新索引文件。当采集端将视音频流推送到服务器时，服务器将收到的信息流缓存一段时间封装成ts文件，同时服务器会更新m3u8索引文件。播放端不断从索引文件中获取最新的ts文件，从而实现直播。

2.1.2 DASH流式传输

DASH协议是国际标准化组织（International Organization for Standardization，ISO）制定的开放协议。

2.1.2.1 DASH流式传输原理

DASH流式传输与HLS流类似，也是服务器端将媒体内容分割成一个个切片，每个切片可以存有不同的码率，客户端可以根据自身和网络情况选择不同的码率播放。它的索引文件是MPD格式，格式如图3所示，由外至内分别是Period（时间段）→AdaptationSet（自适应子集）→Representation（媒体展示）→Segment（分段）。Period将媒体内容按时间段划分，一个DASH码流可能有一个或多个时间段，一个时间段里面的内容不再变更；AdaptationSet是一个时间段里的不同媒体内容，如音频、视频、字幕等；Representation是同一媒体类型的不同码率版本；Segment是同一码率的媒体内容的多个分片地址，也就是真正的媒体内容地址。自适应播放就是在不同码率的Representation之间切换。DASH流支持的视频编码格式有H264等，音频编码格式有AAC、MP3、AC-3等，封装格式有MPEG-2 TS或MP4格式等多种格式，分片可以是MP4（fmp4）文件，也可以是ts文件。

图3 MPD文件格式

2.1.2.2 DASH流式传输的应用

DASH流式传输通常应用在点播和直播中。点播不需要更新MPD文件，直播需要不断更新MPD文件，添加新的Period，在新的Period里添加新的媒体内容。直播和点播就是通过不断轮询MPD、不断发送HTTP请求媒体内容分片来实现的。

2.2 实时流传输

实时流传输需要保持音视频信号带宽与网络连接匹配，需要有专门的流媒体服务器和传输协议，更有效地为用户提供音视频服务。实时流传输主要有基于RTMP协议的实时流传输[3-4]、基于RTP/RTCP协议的实时流传输[5]等。

2.2.1 基于RTMP协议的实时流传输

基于RTMP协议的实时流传输，是通过RTMP协议实现音视频的实时传送。RTMP协议是Adobe公司为Flash播放器与服务器进行音视频数据传输而开发的。

RTMP的原理是在RTMP客户端和RTMP服务器之间建立通信链路来实现数据快速、可靠传输。首先，在RTMP客户端和RTMP服务器之间建立TCP连接，来保证信息传输的可靠性。然后，客户端和服务器之间要进行RTMP握手，主要是为了验证客户端和服务器端使用的RTMP版本一致，相互之间可以通信，以及双方的时间戳。具体流程如图4所示。完成RTMP握手后，客户端和服务器之间交互连接URL、音视频编解码器等信息实现网络连接。它是服务器应用程序与客户端之间的基础连接，只能建立一个。完成网络连接建立后，就可以建立网络流。网络流是服务器与客户端发送多媒体数据通道，完成网络流建立后就可以通过play等命令来实现音视频的传输了。

图4 RTMP握手

RTMP音视频数据传输是发送端先将音视频数据封装成RTMP消息（每个RTMP消息都有一个Message ID），为了实现低时延，再把消息拆分成一个个更小的Chunk单元。其中，对于Chunk单元的大小，服务器和客户端可以协商，通常音频默认为64 Bytes，视频默认为128 Bytes。完成拆分后，发送端再将这些Chunk单元发送给接收端。接收端接收到Chunk单元，根据Message ID恢复成RTMP消息，再解压缩恢复成音视频数据。RTMP协议就是这样实现低时延音视频传输的。

2.2.2 基于RTP/RTCP协议的实时流传输

基于RTP/RTCP协议的实时流传输，是通过RTP/RTCP协议来传递音视频数据。RTP/RTCP协议是国际互联网工程任务组（The Internet Engineering Task Force，IETF）为在网络上实现一对一或一对多传递实时多媒体信息设计的，工作在应用层协议之下，TCP/UDP协议之上。RTP只负责传递音视频数据，RTCP负责音视频数据传输的质量控制、媒体间同步等。而发送端向谁发送音视频、如何控制音视频的播放，则由其他应用层协议如会话描述协议（Session Description Protocal，SDP）、会话初始协议（Session Initiation Protocol，SIP）、RTSP等来实现。RTP、RTCP通常工作在UDP协议之上，RTP端口在1 025到65 535之间选择一个偶数端口，RTCP端口为相邻的下一个奇数端口。协议层架构如图5所示。

图5 协议层架构

2.2.2.1 基于RTP/RTCP协议的实时流传输原理

应用程序建立一个RTP会话时，会确定一对传输地址。传输地址由一个网络地址加两个端口号组成，一个端口传输RTP数据包，用于传输音视频信息；一个端口传输RTCP数据包，用于传输控制信息。上层将音视频数据压缩编码后发送给RTP协议层，RTP协议层将音视频数据封装成RTP包发送给UDP层再发送到网络；上层将控制信息发送给RTCP层，RTCP协议将控制信息封装成RTCP包再发送到网络。接收端处理就是上述过程的逆过程。RTP/RTCP传输流程如图6所示。下面介绍下RTP、RTCP的包格式。

图6 RTP/RTCP传输流程图

2.2.2.2 RTP包格式

RTP包由RTP包头+RTP载荷构成。RTP载荷就是实际要传输的音视频数据。RTP包头格式如图7所示。前12 Bytes为固定头，后面的部分为可选部分。

图7 RTP包头格式

有效载荷类型表示RTP载荷部分的数据类型，接收方可以根据载荷类型来进行解码，恢复成音视频。同步源标识发送RTP包的端。发送方每发送一个RTP包，序列号值加1。接收方可根据序列号值来排序、检测丢包等。时间戳是RTP包第一个八位字节的采样时刻，接收端可以用来计算延时、抖动和同步。参与源是指当几个不同来源的RTP流通过混合器混合成一个新的RTP流，这个新流有一个同步源标识，而这些原同步源标识将作为新RTP流的参与源标识，目的站通过参与源标识来把不同RTP流分开。一个RTP流最多可以有15个参与源。CC表示参与源的数量。

2.2.2.3 RTCP包格式

RTCP协议主要是反馈当前RTP包传输质量及实现媒体间同步等。RTP会话期间，各参与者周期性地发送RTCP包，统计发送端发送RTP包信息以及接收端接收情况等。系统根据RTCP包信息来做出相应的调整，以便提供更好的传输服务。RTCP包有五种常用类型：发送端报告SR、接收端报告RR、源点描述SDES、BYE结束以及特定应用报告App。发送端报告SR是发送RTP流的端向所有接收端发送其传输和接收统计报告，以便让接收端进行同步、计算丢包数、丢包率等。接收端报告RR，是接收端向所有端发送其RTP流接收情况统计报告，以便让发送端知道其发送的RTP流被接收的情况，从而调整数据发送速率等。当一个端既是发送端也是接收端则发送SR报告，只作为接收端不作为发送端则发送RR报告。源点描述SDES描述会话参与者，包括参与者的规范名CNAME。CNAME可以用来实现同一参与者不同媒体源的同步，比如同一参与者的音频流和视频流是分开传输的，同步源标识不同但CNAME相同，就可以实现音频和视频的同步。BYE结束表示关闭一个源，即通知其他参会员者自己将退出会话。这里详细介绍一下发送端报告SR，其报文格式如图8所示。

图8中，SSRC of sender表示该发送端的标识，NTS（分高位和低位）表示发送此报告时的绝对时间戳；RTS为相对时间戳，与RTP包的时间戳具有相同的初始值和单位；SPC代表该发送端从发送RTP包开始到此刻总共发送的RTP包数，SOC代表该发送端从发送RTP包开始到此刻总共发送的RTP包净荷的总字节数。

下面是该发送端从别的发送端接收到的RTP包情况。

SSRC_1标识向该接收端发送RTP流的一个发送端，F表示从上一次RR报文发送之后，从SSRC_1发送端来的包的丢包率；C表示从开始接收SSRC_1数据包到当前时刻丢失的总包数，EHSN表示从SSRC_1接收到的RTP包的最大序列号，LSR表示最近接收到的SSRC_1 SR报文的时间戳，DLSR表示从最近接收到SSRC_1 SR报文到发送本报文的时延。

基于RTP/RTCP协议的实时流传输通过发送端发送RTP流传输音视频信息，各参与者周期性发送RTCP包传输控制信息，接收端根据RTP包头中的载荷类型、时间戳、序号以及RTCP SR包中的时间戳等信息将音视频信息解析出来并实现同步；各参与者根据RTCP报告来评估网络状况，从而采取相应措施来调整传输质量。

目前，还有谷歌公司主导的网页即时通信WebRTC（其实是RTP的一种实现，其中包含许多协议）、腾讯云等私有协议来实现音视频传输。

3 几种音视频传输方法的优缺点及应用

以上所述这些音视频传输方式都具有不同的特点。例如，HTTP渐进式下载使用Web服务器，实现、维护简单，不易被防火墙拦截，对MP4和FLV格式文件支持较好，但传输延迟长、文件会保存到本地占用存储空间，保密性差；HLS协议的实现、维护简单，可以自适应调节码率，不易被防火墙拦截，但延迟较大，本地播放占用存储空间且保密性差，支持的音视频格式较少；DASH协议实现、维护简单，可以自适应调节码率，不易被防火墙拦截，延迟较HLS协议小，切片灵活，本地播放占用存储空间且保密性差；RTMP协议实时播放、传输延迟较低，需要有专门的流媒体服务器，开销大，使用非公共端口，可能会被防火墙拦截，且随着flash不再维护，被各大浏览器弃用，在网页端的应用大大减少；RTP/RTCP协议传输延迟低，支持的音视频格式多，但需要有专门的流媒体服务器，开销大，且使用非公共端口，可能会被防火墙拦截。表1具体分析了这几种音视频传输方式各自的优点、缺点和应用场景。具体应用时，相关从业人员应结合实际情况来选择合适的传输方式。

表1 音视频传输方式的优缺点和应用场景

4 音视频技术面临的问题

随着信息技术的发展，音视频业务类型越来越多，包括现在的点播、直播、即时通信，正在发展的VR、AR、远程医疗、云游戏、元宇宙等等，对音视频技术的要求越来越高。当前，音视频技术面临的主要问题如下。

（1）对音视频质量的要求越来越高。当前，用户对视听体验的要求越来越高，朝着超高清、低时延、流畅、互动方向发展。这对系统的带宽、存储能力要求越来越高，导致成本越来越高。VR、AR、远程医疗、云游戏等新兴技术对低时延、互动性、沉浸感的要求也越来越高。

（2）飞速增长的音视频数据量对系统的算力要求越来越高。传统的单机算法无法满足大规模数据处理要求。

（3）访问量大。音视频服务器负载较大，且影响访问的因素较多，访问量存在不确定性。对此，需要保障业务高峰时的服务质量和稳定运行，避免业务访问量较小时的资源浪费，实现最优配置。

（4）要适应不同终端。未来，音视频在各行各业中的应用会越来越多，应用场景也会越来越多，意味着会有各种各样类型的终端需要适应。

针对这些问题，本文提出以下几点建议：

（1）可以通过优化音视频编码算法，来降低存储、带宽成本，减少算力消耗；

（2）可以通过优化应用程序、文件系统、缓存、磁盘等来提升系统输入/输出性能，提高数据的读写速度，从而实现低时延；

（3）通过分布式算法，将数据分散到多个节点上来处理，以提高数据处理效率，从而满足音视频传输对系统算力的要求；

（4）选择合适的负载均衡方式、合理的调度策略来合理分配任务，充分发挥各服务器的性能，提高系统的可用性和稳定性，从而解决系统高并发访问量问题；

（5）选择能够匹配海量终端的音视频标准和传输协议，来适应不同终端。

5 结 语

本文探讨了音视频传输技术和各种传输方式的优缺点、应用场景，分析了音视频传输面临的问题，并针对这些问题提出了一些建议。未来，音视频将会有更多的应用场景，如云游戏、元宇宙等，业务类型会越来越多，要求也会越来越高，希望本文能给相关从业人员提供参考和借鉴。