5G时代来临，前端开发工程师必须了解的音视频入门基础知识

本文作者：IMWeb jaychen 原文出处：IMWeb社区 未经同意，禁止转载

1. 音视频基础

本文将给大家进行音视频基础的常规知识点的梳理。当然，短短的一篇文章并不能让大家立即变成音视频领域的专家，但这些知识点已经基本涵盖了音视频的入门知识。我们将按照下面的内容给大家

• 音视频的基本概念
• 音视频播放的流程
• 音视频编解码
• 音视频封装格式
• 音视频常见的传输协议

1.1 音视频基本概念

首先，我们需要先主了解下一些音视频常见的技术概念以及简单的原理。

1.1.1 采样率

采样，是指把物理信号转化为数字信号的过程。采样频率，定义了每秒从连续信号中提取并组成离散信号的采样个数，单位为赫兹(Hz)。形象来说，采样频率是指将模拟信号转换成数字信号时的采样频率，也就是单位时间内采样多少点。 拿声音来说，采样频率可以是描述声音文件的音质、音调，衡量声卡、声音文件的质量标准。采样频率越高，即采样的间隔时间越短，则在单位时间内计算机得到的样本数据就越多，对信号波形的表示也越精确。

1.1.2 比特率

比特率是指将模拟信号转化为数字信号后，单位时间内的二进制数据量，是衡量音视频质量的指标之一。单位为比特每秒(bps或者bit/s)。单位时间内比特率越大，精度就越高，处理出来的文件就越接近原始文件，音视频文件的质量也越高。 1000 bit/s = 1 kbit/s （一千位每秒） 1000 kbit/s = 1 Mbit/s （一兆或一百万位每秒） 1000 Mbit/s = 1 Gbit/s (一吉比特或十亿位每秒） 拿声音来说，能够分辨语音的最低码率为800bps，通话质量一般来说是8kbps, FM广播一般是96kbps, MP3文件范围在8-320kbps之间(一般为128kpbs)， 16位CD一般为 1411kbps。 音频比特率计算公式：【比特率】（kbps)=【量化采样点】（kHz）×【位深】（bit/采样点）×【声道数量】（一般为2）

在视频中，比特率又常被称为码率。16kbps为可视电话质量，128-384kpbs为商用视频会议质量，VCD一般为1.25Mbps，DVD为5Mkpbs，蓝光光碟为40Mbps。 计算公式为：【码率】(kbps)=【文件大小】(KB) * 8 / 【时间】(秒)。比如一部1G的电影，时长60分钟，那么它的码率则为 1 x 1024 x 1024 x 8 / 3600 = 2300Kbps/s。

1.1.3 帧率

帧，可以理解为一张采集到的静止的画面。帧率则指的是每秒显示的帧数(Frames per Sercond, 简称FPS)。由于人眼的生理构造，当画面的帧率高于16帧每秒(16fps)时，就会产生一个视觉停留，看起来就是一个连贯的画面。比如我们看的动画片，也是同样的原理，动画师将一个个场景画出来，然后以一定的频率切换，就产生了一个连贯的动画场景。一般来说，电影的帧率为23.97fps,电视为25fps。

1.1.4 分辨率

分辨率主要有2个分类：显示分辨率跟像素分辨率。显示分辨率指显示器能显示多少像素。像素分辨率指图像单位英寸中包含的像素点数量。 描述分辨率的单位有：（dpi点每英寸）、lpi（线每英寸）和ppi（像素每英寸）。lpi是描述光学分辨率的尺度的，与dpi/ppi含义不同。dpi一般用于印刷行业较多，而ppi常见于计算机领域。 常见的分辨率尺寸： DV: 480 x 720 720P: 720 x 1280 1080P: 1080 x 1920 2K: 1152 x 2048 4k: 2160 x 4096

1.2 音视频播放流程

整个音视频播放的流程，可以拆解为下面几个主要流程：音视频采集->前处理->音视频编码->音视频处理/分发->音视频解码->后处理->渲染、播放。那么，音视频流在整个上下行链路中，具体有哪些流程，每一步具体做了什么？我们常见的直播美颜，滤镜，是在哪一步流程中处理的？下面会一一详细展开讲解。

1.2.1 上行和下行

直播场景针对音视频流的来源，我们一般会分为上行以及下行，上行指的是音视频采集端将画面通过采集设备（摄像头，麦克风）采集后，通过编码后上行到 server，一般我们称主播端为上行端。下行指上行的视频流经过在server处理或者转发后，传输到 CDN 或者观众端。

1.2.2 音视频采集

这一过程主要是利用摄像头/麦克风去分别捕获图像/声音信号，并将声音、图像从物理信号转化为数字信号。拿视频来说，如果设置了摄像头分辨率为640×480，帧率为30帧/s，那么每个画面大小约为50kb左右，那么摄像头每秒采集到的数据转化为数字信号后的比特率则为：50×30/s＝1500kbps＝1.5Mbps。

1.2.3 前处理

前处理介于采集以及编码中间，按照类型划分可以分为音频前处理和视频前处理，音频前处理包括降噪、回音消除、人声检测、自动增益等，视频前处理包括美颜、磨皮、设置对比度、镜像、水印等。一般来说，前处理都是在上行方客户端完成的，因为其需要消耗较大的cpu资源，放在server端成本较大，性能不佳。

1.2.4 音视频编码

前面提到的音视频采集后的音视频流为裸码流，即没有经过编码压缩处理的数据。这里再举个例子，例如一个例子，一个720p(1280x720)，每秒30帧，60分钟的电影，其占用磁盘大小为：12Bx1280x720x30x60x100 = 1.9T。如果不经过压缩，传输这个视频的时间无疑将非常漫长，以电信100M宽带，大概需要下载43小时。所以需要对原始视频裸码流进行压缩，采用的手段就是音视频的编码，而编码的目的就是压缩。 视频编码通常都是有损压缩，目标是降低一点清晰度的同时让体积得到大大的减少，降低的清晰度能达到对人眼不可察觉或者几乎无法分辨的水平。主要是方法是去除视频里面的冗余信息，对于很多不是剧烈变化的场面，相邻帧里面有很多重复信息，通过帧间预测等方法分析和去除，而帧内预测可去掉同个帧里的重复信息，还有对画面观众比较关注的前景部分高码率编码，而对背景部分做低码率编码，等等，这些取决于不同的压缩算法。而解码相对的就是解压缩，还原成原始像素。常见的音视频编解码算法前面-章节已经提到，这里就不展开细讲了。

1.2.5 音视频处理/分发

编码后的音视频数据通过某种传输协议(rtp,rtmp,rtsp等)上行到音视频处理/分发的服务器，服务器可以根据具体的业务场景去实现多路音视频的混流，转码，转协议，转发给具体的下行段。

1.2.6 音视频解码

当观众接收到音视频流时，浏览器是怎么把数据渲染成画面跟播放出声音的呢？

上面是chrome内核Chromium对接收到的音视频数据进行处理的流程。当我们用HTML5播放视频，通过初始化一个video标签创建一个DOM对下，它会实例化一个WebMediaPlayer,这个Player通过去请求多媒体数据，进行解协议，就是图中Internet到DataSource这个过程，得到音视频的封装格式，比如MP4,FLV等。接着再解封装，这个过程一般称为demux，拿到音视频轨。拿视频轨道来说，里面分别会有I帧,B帧(可能没有),P帧。其中I帧是关键帧（I帧，Intra frame），包含了该帧的完整图象信息。另一些帧只是记录和参考帧的差异，叫帧间预测帧（Inter frame），所以比较小，预测帧有前向预测帧P帧和双向预测帧B帧，P帧是参考前面解码过的图像，而B帧参考双向的。用对应的音视频解码器去解码，得到原始数据。这里解demux使用的是chrome里面内置的开源第三方FFmpeg解码模块。

1.2.7 渲染、播放

把解码后的数据传给相应的渲染器对象进行渲染绘制，最后让video标签去显示或者声卡进行播放。

1.3 音视频封装格式

导语：所谓视频的封装，就是将编码好的音频、视频、或者是字幕、脚本之类的文件根据相应的规范组合在一起，从而生成一个封装格式的文件。

1.3.1 封装格式

封装格式，其是将已经编码压缩好的视频轨和音频轨按照一定的格式放到一个文件中，也就是说仅仅是一个外壳，或者大家把它当成是一个可组合视频和音频的容器。 说得形象一点，视频相当于米饭，而音频相当于菜，此时封装格式就是一个碗，可用来盛放饭菜的容器。当然不同的碗（封装格式）有不同特点。下面是一些常见的封装格式。其实不然，试想一下，有的菜，例如排骨，比较大，碗放不下，得换锅。有的饭比较烫，也不能放在塑料的容器里，当然个人喜好也有一定关系。所以容器的选择，基本在于其对视频/音频兼容性，以及适合范围。

AVI容器（后缀为.AVI）

AVI是微软1992年推出用于对抗苹果Quicktime的技术，尽管国际学术界公认AVI已经属于被淘汰的技术，但是由于windows的通用性，和简单易懂的开发API，还在被广泛使用。

这种视频格式的优点是图像质量好。由于无损AVI可以保存alpha通道，经常被我们使用。缺点太多，体积过于庞大，而且更加糟糕的是压缩标准不统一，最普遍的现象就是高版本Windows媒体播放器播放不了采用早期编码编辑的AVI格式视频，而低版本Windows媒体播放器又播放不了采用最新编码编辑的AVI格式视频，所以我们在进行一些AVI格式的视频播放时常会出现由于问题而造成的视频不能播放或即使能够播放，但存在不能调节播放进度和播放时只有声音没有图像等一些莫名其妙的问题。

Matroska格式（后缀为.MKV）

是一种新的多媒体封装格式，这个封装格式可把多种不同编码的视频及16条或以上不同格式的音频和语言不同的字幕封装到一个Matroska Media档内。它也是其中一种开放源代码的多媒体封装格式。Matroska同时还可以提供非常好的交互功能，而且比MPEG的方便、强大。

QuickTime File Format格式（后缀为.MOV）

美国Apple公司开发的一种视频格式，默认的播放器是苹果的QuickTime。

具有较高的压缩比率和较完美的视频清晰度等特点，并可以保存alpha通道。大家可能注意到了，每次安装EDIUS，我们都要安装苹果公司推出的QuickTime。安装其目的就是为了支持JPG格式图像和MOV视频格式导入。

MPEG格式

MPEG格式（文件后缀可以是 .MPG .MPEG .MPE .DAT .VOB .ASF .3GP .MP4等）：它的英文全称为 Moving Picture Experts Group，是一个国际标准化组织（ISO）认可的媒体封装形式，受到大部份机器的支持。其存储方式多样，可以适应不同的应用环境。MPEG的控制功能丰富，可以有多个视频（即角度）、音轨、字幕（位图字幕）等等。

WMV格式（后缀为.WMV .ASF）

它的英文全称为Windows Media Video，也是微软推出的一种采用独立编码方式并且可以直接在网上实时观看视频节目的文件压缩格式。

WMV格式的主要优点包括：本地或网络回放,丰富的流间关系以及扩展性等。WMV格式需要在网站上播放，需要安装Windows Media Player（简称WMP），很不方便，现在已经几乎没有网站采用了。

Flash Video格式（后缀为.FLV）

由Adobe Flash延伸出来的的一种流行网络视频封装格式。随着视频网站的丰富，这个格式已经非常普及。

1.4 音视频编解码

音视频在网络中传播，主要分为如下几个阶段：录制-编码-传输-解码-播放，音视频编解码发挥这不可忽视的作用，能够优化数据包大小，通常通过媒体采集设备采集的音视频频数据被编码后，可以极大的压缩数据，并且画质影响不大，通常用户对直播画面实时性要求很高，了解编码底层原理有助于优化直播流畅性。本节主要介绍常见的音视频编解码格式。

1.4.1 常见音频编码格式

音频编码是为了将 PCM 音频采样数据转换为音频码流， 优化网络传输效率。常见的格式有：FLAC、APE、WAV、Opus、MP3、WMA、AAC。

FLAC、APE、WAV 是属于无损编码格式，压缩率低，通常用于音质要求较高的音乐等内容; Opus、MP3、WMA、AAC 属于有损压缩格式，压缩率高利于网络传输; 其中 Opus、OGG 属于完全免费开源的编码格式。不同的编码格式特点也不尽相同，不同编码面向的使用场景不同，没有绝对的优劣。

下面详细介绍常见的编码格式： 1, FLAC

FLAC 全称 Free Lossless Audio Codec，中文直译为自由无损音频压缩编码。无损也就是说当你将从音频 CD 上读取的音频数据文件压缩成 FLAC 格式后，你还可以再将 FLAC 格式的文件还原，而还原后的音频文件与压缩前的一模一样，没有任何损失。

FLAC 是一款的自由音频压缩编码，其特点是可以对音频文件无损压缩。不同于其他有损压缩编码，如 MP3 、AAC，压缩后不会有任何音质损失，现在已被很多软件及硬件音频产品所支持，很多流行的音乐播放器默认的无损音频格式都是 FLAC。

特点：无损压缩格式，体积较大，但是兼容性好，编码速度快，播放器支持广。

2, APE

APE 是一种常见的无损音频压缩编码格式，APE 是其编码后的文件扩展名，该编码格式的名称是 Monkey's Audio。

Monkey's Audio 压缩比高于其他常见的无损音频压缩格式，约在 55%上下，但编解码速度略慢。在搜寻回放位置时，如果文件压缩比过高，在配备较差的计算机会有延迟的现象。另外，由于它没有提供错误处理的功能，若发生文件损坏，损坏位置之后的数据有可能会丢失。

Monkey's Audio 是开放源代码的免费软件，但因其授权协议并非自由软件而是准自由软件（Semi-free Software）而受到排挤。因为这意味着许多基于 GNU/Linux 的 Linux 发行包或是其他只能基于自由软件的操作系统不能将其收入。较之其他使用更自由的许可证的无损音频编码器（如 FLAC），受其他软件的支持也更少。

特点：无损压缩格式，其体积比其它无损压缩格式较小，编码速度偏慢。

3, WAV

WAV 全称 Waveform Audio File Format，是微软公司开发的一种声音文件格式，也叫波形声音文件，是最早的数字音频格式，被 Windows 平台及其应用程序广泛支持。

WAV 格式支持许多压缩算法，支持多种音频位数、采样频率和声道，采用 44.1kHz 的采样频率，16 位量化位数，因此 WAV 的音质与 CD 相差无几，但 WAV 格式对存储空间需求太大不便于交流和传播。

特点：无损压缩格式，体积十分大。

4,Opus

Opus 是一个有损声音编码的格式，由 Xiph.Org 基金会开发，之后由 IETF 互联网工程任务组进行标准化，适用于网上低延迟的即时声音传输，标准格式定义于 RFC 6716 文件。Opus 格式是一个开放格式，使用上没有任何专利或限制。

Opus 集成了两种声音编码的技术：以语音编码为导向的 SILK 和低延迟的 CELT。Opus 可以无缝调节高低比特率。在编码器内部它在较低比特率时使用线性预测编码在高比特率时候使用变换编码（在高低比特率交界处也使用两者结合的编码方式）。Opus 具有非常低的算法延迟（默认为 22.5 ms），非常适合用于低延迟语音通话的编码，像是网上上的即时声音流、即时同步声音旁白等等，此外 Opus 也可以透过降低编码码率，达成更低的算法延迟，最低可以到 5 ms。在多个听觉盲测中，Opus 都比 MP3、AAC 等常见格式，有更低的延迟和更好的声音压缩率。

在 WebRTC 实现中，强制要求支持 Opus，也是其默认的音频编码格式。

特点：有损压缩;可动态调节比特率，音频带宽和帧大小;开放免费、没有专利限制。

5, MP3

MP3 的全称是 Moving Picture Experts Group Audio Layer III。由于这种压缩方式的全称叫 MPEG Audio Layer3，所以简称为 MP3。

MP3 是利用 MPEG Audio Layer 3 的技术，将音乐以 1:10 甚至 1:12 的压缩率，压缩成容量较小的 file，换句话说，能够在音质丢失很小的情况下把文件压缩到更小的程度。而且还非常好的保持了原来的音质。

正是因为 MP3 体积小，音质高的特点使得 MP3 格式几乎成为网上音乐的代名词。

特点：有损压缩，压缩率高，文件体积小，最高比特率 320K

6, WMA

WMA 的全称是 Windows Media Audio，是微软力开发的一种音频编码格式。一般情况下相同音质的 WMA 和 MP3 音频，前者文件体积较小，并且可以通过 DRM（Digital Rights Management）方案加入防止拷贝，或者加入限制播放时间和播放次数，甚至是播放机器的限制，可有力地防止盗版。

特点：支持 DRM 防盗版，相比 MP3 格式压缩率更高

7, AAC

AAC 全称 Advanced Audio Coding，是一种基于 MPEG-2 的有损数字音频压缩的专利音频编码标准，由 Fraunhofer IIS、杜比实验室、AT&T、Sony、Nokia 等公司共同开发。MPEG-4 标准 出台后，在原本的基础上加上了 PNS（Perceptual Noise Substitution）等技术，并提供了多种扩展工具。为了区别于传统的 MPEG-2 AAC 又称为 MPEG-4 AAC。其作为 MP3 的后继者而被设计出来，在相同的位元率之下，AAC 相较于 MP3 通常可以达到更好的声音质量。

AAC 提供了低至 8 kHz 高至 96 kHz 的多种采样率、更高的比特深度(8, 16, 24, 32 bit)，并且支持 1 到 48 之间的任何声道数

特点：目前最好的有损格式之一，压缩率高

1.4.2 常见视频编码格式

视频编码主要是为了将视频像素数据压缩成视频码流，以降低视频的大小，从而方便网络传输和存储。常见的格式有：MPEG-2、H.264、H.265、VP8、VP9。

1, MPEG-2

MPEG-2 是 MPEG 工作组于 1994 年发布的视频和音频压缩国际标准，视频编码是 MPEG-2 标准的第二部分，其视频通常包含多个 GOP(Group Of Pictures)，每一个 GOP 包含多个帧（frame）。帧类型（frame type）通常包括 I-帧（I-frame）、P-帧（P-frame）和 B-帧（B-frame）。其中 I-帧采用帧内编码，P-帧采用前向估计，B-帧采用双向估计。通常 I 帧被称为关键帧，包含了完整的一帧图像。

I 帧图像采用帧内编码方式，即只利用了单帧图像内的空间相关性，而没有利用时间相关性。I 帧使用帧内压缩，不使用运动补偿，由于 I 帧不依赖其它帧，所以是随机存取的入点，同时是解码的基准帧。I 帧主要用于接收机的初始化和信道的获取，以及节目的切换和插入，I 帧图像的压缩倍数相对较低。I 帧图像是周期性出现在图像序列中的，出现频率可由编码器选择。

P 帧和 B 帧图像采用帧间编码方式，即同时利用了空间和时间上的相关性。P 帧图像只采用前向时间预测，可以提高压缩效率和图像质量。P 帧图像中可以包含帧内编码的部分，即 P 帧中的每一个宏块可以是前向预测，也可以是帧内编码。

B 帧图像采用双向时间预测，可以大大提高压缩倍数。值得注意的是，由于 B 帧图像采用了未来帧作为参考，因此 MPEG-2 编码码流中图像帧的传输顺序和显示顺序是不同的。

2, H.264

H.264，又称为 MPEG-4 第 10 部分，高级视频编码（英语：MPEG-4 Part 10, Advanced Video Coding，缩写为 MPEG-4 AVC）是一种面向块，基于运动补偿的视频编码标准 。到 2014 年，它已经成为高精度视频录制、压缩和发布的最常用格式之一。第一版标准的最终草案于 2003 年 5 月完成。该编码标准被广泛用于网络流媒体数据传输，在国内流媒体资源普遍采用该编码格式。

3, H.265

高效率视频编码（High Efficiency Video Coding，简称 HEVC），又称为 H.265 和 MPEG-H 第 2 部分，是一种视频压缩标准，被视为是 ITU-T H.264/MPEG-4 AVC 标准的继任者。2004 年开始由 MPEG(ISO/IEC Moving Picture Experts Group)和 VCEG(ITU-T Video Coding Experts Group)作为 MPEG-H Part 2 或称作 ITU-T H.265 开始制定。第一版的 HEVC/H.265 视频压缩标准在 2013 年 4 月 13 日被接受为国际电信联盟（ITU-T）的正式标准。

HEVC 被认为不仅提升视频质量，同时也能达到 H.264/MPEG-4 AVC 两倍之压缩率（等同于同样画面质量下位元率减少到了 50%），可支持 4K 清晰度甚至到超高清电视（UHDTV），最高清晰度可达到 8192×4320（8K 清晰度）。

4, VP8

是开放免费的编码格式，是 Google 收购 On2 公司之后获得的软件，旨在提供免费的编码格式提供给 HTML5 使用，通常被封装在 webM 容器中传播。该编码很少有公司采用。

5, VP9

VP9 是谷歌公司为了替换老旧的 VP8 视频编码格式并与动态专家图像组（MPEG）主导的高效率视频编码（H.265/HEVC）竞争所开发的免费、开源的视频编码格式。VP9 一般与 Opus 音频编码一起以 WebM 格式封装

相比于 H.265，许多浏览器都支持 VP9 视频格式，截止 2018 年 6 月，约有 4/5 的浏览器（包括移动设备）支持 WebM 封装容器和 VP9 视频编码，例如: Chrome、Microsoft Edge、Firefox、Opera 等浏览器都内置了 VP9 解码器，可在 HTML5 播放器中播放 VP9 视频格式。Windows 10 操作系统也内置了 WebM 分离器和 VP9 解码器。

1.5 音视频传输协议

导语：服务端（例如主播的直播画面）的音视频，如何传输到观众（用户端），这之间相关传输细节的沟通（传输的编解码格式，传输方式等）其是音视频传输协议来定义。

目前在网络上传输音/视频（英文缩写A/V）等多媒体信息主要有下载和流式传输两种方案。

下载式传输

我们知道音视频文件普通体积都比较大，在网络带宽的限制，下载常常需要耗费花较长的时间。所以这种处理方法延迟也很大。并且用户需要等到把整个音视频文件全部下载完后才能使用播放器进行观看。

流式传输（流媒体协议）

流式传输时，声音、影像或动画等时基媒体由音视频服务器向用户计算机的连续、实时传送，用户不必等到整个文件全部下载完毕，而只需经过几秒或十数秒的启动延时即可进行观看。当声音等时基媒体在客户机上播放时，文件的剩余部分将在后台从服务器内继续下载。流式不仅使启动延时成十倍、百倍地缩短，而且不需要太大的缓存容量。流式传输避免了用户必须等待整个文件全部从 Internet 上下载才能观看的缺点。而定义音视频数据如何流式传输的则是流媒体传输协议。

RTP/RTCP/RTSP 基础协议族

本协议族是最早的视频传输协议。其中RTSP协议用于视频点播的会话控制，例如发起点播请求的SETUP请求，进行具体播放操作的PLAY、PAUSE请求，视频的跳转也是通过PLAY请求的参数支持的。而RTP协议用于具体的视频数据流的传输。RTCP协议中的C是控制的意思，用于在视频流数据之外，丢包或者码率之类的控制。该协议族RTSP是建立在TCP之上的，RTP、RTCP建立在UDP之上。不过也可以通过interleave的方式，将RTP和RTSP一起在同一个TCP连接上传输。RTSP协议族，是最早被提出来的，因此很多考虑的地方，都还带有早期的特征。比如使用UDP，是考虑到传输的效率，以及视频协议本身对丢包就有一定的容忍度。但是UDP协议，显然不能用于更大规模的网络，而且复杂网络下路由器的穿透也是问题。从视频角度而言，RTSP协议族的优势，在于可以控制到视频帧，因此可以承载实时性很高的应用。这个优点是相对于HTTP方式的最大优点。H.323视频会议协议，底层一般采用RTSP协议。RTSP协议族的复杂度主要集中在服务器端，因为服务器端需要parse视频文件，seek到具体的视频帧，而且可能还需要进行倍速播放（就是老旧的DVD带的那种2倍速，4倍速播放的功能），倍速播放功能是RTSP协议独有的，其他视频协议都无法支持。缺点，就是服务器端的复杂度也比较高，实现起来也比较复杂。

需要注意的是, WebRTC 音视频传输就是基于 RTP 协议

RTMP

Time Messaging Protocol，实时消息传送协议)RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种：1、工作在TCP之上的明文协议，使用端口1935；2、RTMPT封装在HTTP请求之中，可穿越防火墙；3、RTMPS类似RTMPT，但使用的是HTTPS连接；RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器，这些数据既可以是AMF格式的数据，也可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。

HLS

HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。

相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。　

总结

若想进入Web音视频领域，以上的基本概念必须都要了解，每个概念都可以单独拎出来往很深入的方向去研究。随着5G时代的到来，相信未来的Web将有更加广泛的音视频应用场景，掌握音视频知识，为未来做好准备。未来的前端开发不单知识HTML, JavaScript，相信音视频相关的开发也是必须掌握的技能。