流媒体｜从入门到出家：流媒体系统（上）

一套大规模的流媒体系统，由编码工具负责对音视频文件编码压缩（h.264/h.265/VP9/AAC等）；由流媒体服务器负责对数据包进行容器封装（flv/ts等）以及负责网络协议打包（RTMP/HTTP等）；由CDN网络进行全网分发；由播放层负责对图像进行解码显示（FLASH/VLS/VIDEO JS等）。流媒体系统所需的核心组件包括：

（1）编码工具：用于流媒体文件生成的编码工具

（2）流媒体服务器：用于控制、传送流媒体数据的流媒体服务器

（3）CDN网络：用于支撑流媒体的全网分发网络

（4） 网络协议：用于支持特定的流式传输的网络协议

（5）播放器：各操作平台用于显示流式数据的播放器

本篇内容将对上述5个环节做一个整体性论述，由于本系列分享着重讨论流媒体传输分发，所以在后续文章不会再讲编码和播放两个端上的环节。本篇对编码和播放将稍微展开讨论，其它3个环节只简单提及，后续将分章详细讨论。本篇最后将给出一个实例，让大家能直观的看出一个完整的流媒体系统各环节是如何运用到直播系统中。

2.1

编码工具

视音频的编码应该是整个视音频技术中最复杂、涉及知识点最多的技术了，当然也是最重要的技术，这是一门专业学科。我们研究流媒体时，如果不是专业做编解码的，倒不必对编解码技术进行系统学习。因为当下市面上有大量优秀的专业编码设备、编码软件、开源工具，我们只需要了解视音频编解码大致的原理，了解各种编码标准，做流媒体时如何选择及使用编码工具就达到目的了。

（1）视音频编码原理

我们所谓的视音频编码，其实就是一个对数据进行压缩的过程。在编码原理这块，我们无需掌握其过于深奥的数学原理和计算机算法，只需要搞清楚两个问题即可，一是为什么要压缩？二是为什么能压缩？

为什么要压缩，在回答这个问题之前我们需要搞清楚我们天天在网上看的直播里面那些视频和音频到底是个什么东西。视频，是通过摄像头采集下来的YUV等原始数字格式；音频，是通过麦克风拾音器采集下来的PCM等原始数字格式（YUV/RGB/PCM数据格式原理网络上有大量文章）。如果直接通过网络传输这些原始数据，大概需要多大的带宽呢？下图给出了不同YUV分量格式、采样频率、量化比特位数下这些数据所需的传输速率。

几百兆（音频是需要几兆），这根本无法在网络上传输，同时也不利于存储，一部1小时的电影大约是几百个G。所以，我们必须通过编码技术将原始视音频数据进行大幅度的压缩，以能在互联网上传输及存储。编码设备或编码软件所做的，一是将原始YUV或PCM数据进行大小上的压缩，二是将压缩后的数据打包进流媒体协议发送给流媒体服务器。

为什么能压缩，主要是由于原始视音频数据存在以下两种冗余数据，所以我们才能使用编码算法对数据量进行大幅压缩，以此实现网络上的传输和存储。

·          数据冗余：比如视频画面的众多像素在空间上、时间上、结构上等等方面存在着很强的相似性甚至是完全一模一样。消除这些冗余数据并不会导致信息损失，此为无损压缩。

·          视觉/听觉冗余：人眼对亮度和色度的敏感度不同，使得数据在一定范围内压缩引入误差，也基本不会有显著感知；人耳对20Hz～20KHz范围外的声音无法察觉，或者一定程度引入误差也无法感知。利用人类眼睛和耳朵的特性，在不影响正常感知的情况下对数据进行压缩，此为有损压缩。

（2）编码器工作流程

在我们熟悉的直播系统中，编码工作一般由硬件编码器、PC端OBS/FMLE、移动端各种采集SDK来完成。这些编码工具除了压缩编码之外，其实还完成了下图所示的采集、编码、封装、协议打包、推流5大环节，其中每一个环节都涉及非常多的理论知识和巨大的研发工作量，此处只介绍各环节作用。

采集：该环节作用是通过音视频硬件采集卡（如BlackMagic等）、桌面采集程序（如OBS的videoCapture）、移动端采集程序（如IOS的AVFoundation框架等）将视音信号变为YUV/PCM等数字视音频信号。观止云自主研发广电级编码器，在采集环节也遇到过较多的坑，以往微信号分享文章中做过多次论述。

编码：该环节作用是通过特定的视频、音频编码算法，将原始的YUV/PCM数据进行数量级的压缩，压缩后成为H.264/AAC等压缩数据。编码环节是整个编码工具中最为核心和复杂的部分，其中涉及了多种压缩算法选取、数十项压缩参数的设置、软编/硬编的适配优化及技术方案等等。虽然该环节及其复杂，但我们只需要记住4点结论性的知识点就够了：

·          目前最主流的编码算法为：h.264(视)/AAC（音）

·          未来可能成为趋势并且竞争激烈的是：h.265（也叫HEVC）（MPEG/ITU-T两个组织2013年联合推出）和VP9（Google 2013年推出）

·          视频算法性能排名：h.265（HEVC） > VP9 > H.264> VP8 > MPEG4 > H.263 > MPEG2

·          音频算法性能排名：AAC+ > MP3PRO > AAC> RealAudio > WMA > MP3

封装：该环节将H.264/AAC等压缩数据按照一个统一的格式组装到一个文件里面，这就是我们经常所说的视音频文件格式，也就是文件的后缀名，文件只有有了格式客户端才知道该用什么程序打开。整体上封装格式可能有上百种，但我们经常碰到或者流媒体系统常用的大概有如下几种。

协议打包：该环节将上述如flv等封装数据加上一些信令数据后进行流媒体协议打包。流媒体协议将在后续分章细述，此处给出目前常用的流媒体协议列表。

推流：很多编码工具也叫“串流”，就是编码工具将编码、封装好的音视频最终通过流媒体协议发送给流媒体服务器。

（3）重要的编码参数

我们在基于一些商用编码设备、开源编码工具搭建流媒体系统或者操作直播相关业务时，掌握了基本概念后，其实更重要的是对编码相关的参数要有深刻的认识和熟练的配置优化。以下给出一些比较重要的参数概念：

▣   GOP（Group of Pictures）：一个GOP就是一组连续的画面，每个画面就是一帧， GOP就是很多帧的集合。这里面有I/P/B帧的概念，播放器显示画面是去找到最近的I帧（关键帧）来显示，所以为了实现秒开的体验，一般流媒体服务器会有GOP Cache配置，GOP Cache越长，播放体验会越好，但不好的一面是GOP Cache会增加直播的延迟。所以，我们在配置时一方面要做好延时与画质的平衡，另一方面可以通过追帧播放等技术来进行优化。

▣  关键帧距离：关键帧（I帧）之间的最大距离（单位：秒），它是根据视频内容中的场景变换自动决策的，但两个关键帧之间的最大距离不超过该设定值，推荐配置：5-10。这个参数会影响到直播的延时，如果为了追求最低延时，可将其配置为1。

▣  码率控制VBR/CBR/ABR：

·          CBR(Constant Bitrate)：恒定比特率，相对于VBR和ABR来讲，它无法根据视频内容的变换而动态变换，导致某些情况下图像质量较差或某些情况下浪费带宽 。

·          ABR(Average Bitrate)：平均比特率，是介于CBR和VBR之间的一种折中算法。 对于较简单的图像或场景使用相对低的码率，高复杂度和大动态表现时使用高码率。互联网直播推荐使用才控制策略。

·          VBR(Variable Bitrate)：动态比特率。也就是没有固定的比特率，保持恒定质量的参数，推荐用于内网视频应用或视频存档。

▣  码率控制缓冲区时长：缓冲区起到平滑码率波动的作用。在编码端，数据输入缓冲区的码率是变化的，而输出端则取决于码率控制模式。缓冲区越大平滑效果就越好同时延时也越大，缓冲区小能保证低延时同时可能由于上溢导致跳帧。

▣  前向预测延迟：单位为秒，通过缓冲一定数量的视频帧（提高编码延迟）来提高编码质量，默认为自动，该参数跟编码延迟有关

▣  超低延迟：如观止云广电级编码器等部分编码设备或者编码工具由此选项，启用超低延迟，将关闭B帧、关闭MBtree、关闭码率控制前向预测，使编码的同时能够同步输出；由于启用低延迟模式，会在一定程度上降低视频质量，适用于视频通话和视频会议等。

▣  参考帧数：控制DPB (Decoded Picture Buffer)的大小。可以在0-16之间选择。简单地说，就是设置P帧可以选择它之前的多少帧作为参照帧。最小可以选择值1，只参照自己前面的那帧。注意H.264标准限制了每个level可以参照的帧的数量。如果选择level4.1，1080p最大选4，720p最大选9。推荐设置为自动，将根据编码复杂度中相关参数设置。

▣  B帧数量：手动指定在I帧或P帧之间创建的连续B帧的数量，范围是0－16。推荐设置为自动，将根据编码复杂度中相关参数设置。

▣  视频质量与体验质量：视频是由图像和声音组成的，所以它本身是有质量属性的，我们可以简单的用清晰度、流畅感（帧率）来描述它。但我们在互联网上看视频尤其是直播，其实更需要整体的视听体验要好，这里面大致会涉及到的参数有采样率、帧率、分辨率、码率等，另外还和接入带宽、每个人不同的眼镜、耳朵感知程度等都有关系，是个比较复杂的过程。参数的具体含义之前文章的术语表中都能找到，总体来说，我们需要做的是一种各参数之间的平衡，来保障最终的观看体验。以下是观止云的编码参数配置建议：

以下几点需要提醒：

·          1080P VBR的码率范围一般为2.3-4Mbps，新闻类节目一般建议采用2.3Mbps，运动类节目一般建议采用4Mbps，观止推荐3Mbps；

·          720P VBR的码率范围一般为1.2-2Mbps，新闻类节目一般建议采用1.2Mbps，运动类节目一般建议采用2Mbps，观止推荐1.5Mbps；

·          576P VBR的码率范围一般为600k-1Mbp，新闻类节目一般建议采用1.2Mbps，运动类节目一般建议采用2Mbps，观止推荐800kbps；

·       480P VBR的码率范围一般为400kbps-600kbps，新闻类节目一般建议采用400kMbps，运动类节目一般建议采用600kbps，观止推荐500kbps；

·        360P VBR的码率范围一般为200kbps-400kbps，新闻类节目一般建议采用200kMbps，运动类节目一般建议采用400kbps，观止推荐300kbps；

·            本编码建议不适合IPTV、数字电视等采用CBR编码方式，通常采用IPTV和数字电视指提供576P和1080P两个选项，码率为2.5Mbps（576P 720x576）和8Mbps（1080P 1920x1080），个别地方提供720P，码率为4Mbps左右（720P 1280x720）

·       移动端的编码参数可参照PC-720P、PC-576P

▣  视频质量评价：它讲的是如何评价视频本身质量，一般分为主观评价方法和客观评价方法。当下有多种成熟的评价模型、评价工具可供直接使用。目前使用的比较广泛的是客观质量评价SSIM和峰值信噪比PSNR，网络上有大量的其算法模型文章。

▣ 编码级别(Level)：该指标是用来标识解码端解码能力的重要参数，跟每秒解码器能够处理的数据量相关，如果你的编码端有此选项，建议设置为自动，它就会根据当前编码复杂度、分辨率、帧率等配置计算出合适的Level值。如果很懂该参数，那就可以手动限制输出码流的Level值，以适配相应设备。

（4）开源项目等资料

FFmpeg：一个跨平台的开源视频框架,能实现如视频编码、解码、转码、串流、播放、字幕、滤镜等丰富的功能。其支持的视频格式以及播放协议非常丰富,几乎包含了所有音视频编解码、封装格式以及播放协议。

X264/X265：一个简单的额将YUV数据编码为h.264/h.265的开源项目，可以基于它实现编码器功能，是目前视频编码应用最广的，但需要注意的是它只提供编码，不提供解码。

Xvid：一个开放源代码的MPEG-4视频编解码器。

libvpx：Google发起的VP8/VP9开源编码器。

Thor： 思科开源的视频编码解码器。

Opus：IETF Codec工作组、Skype等共同发起的专注网络音频的编解码器。

Speex：开源的音频编码项目。

IQA(Image Quality Assessment)：一个快速，精确，可靠的基于C的开源视频质量评价项目，支持SIMM, MSE 和 PSNR等多种质量评价方法。

另外：国内各大云公司基本都有移动端采集SDK供免费使用。

音频编码算法对比一览：

https://en.wikipedia.org/wiki/Comparison_of_audio_coding_formats

视频编码算法对比一览：

https://en.wikipedia.org/wiki/Comparison_of_video_codecs

所有视音频封装格式对比一览：

https://en.wikipedia.org/wiki/Comparison_of_video_container_formats

更多开源的音视频编码项目一览：

https://en.wikipedia.org/wiki/List_of_open-source_codecs