视频直播知识入门

以直播过程中，主播直播到用户看到主播的过程为例，谈一下有关视频的知识，整个流程中主要经历了以下阶段：

• 采集：通过摄像头，麦克风等采集图像和音频数据。
• 处理：对采集的原始数据进行一些处理，比如打上时间戳，美颜和变声等处理。
• 编码：将采集到音频和图像数据，编码压缩，降低数据大小，并尽可能的保留精度。
• 封装：将编码后的数据，封装成各个格式，大家比较熟悉的如：FLV，MP4。
• 推流：将完成封装的数据，采用HTTP或者RTMP协议推送到服务端。
• 传输：把推送出去的流媒体传输到观众。
• 转码：将一个已压缩编码的视频流转换成另一个视频流，以适应不同的带宽，或者不通用户的需求。
• 分发：直播流服务将数据分发给各个客户端，也就是每个用户的浏览器或App上。
• 解码：将编码数据，解码为非压缩的原始数据。
• 拉流：把服务器已有的直播内容，用指定的地址进行拉取的过程。
• 播放：浏览器或App将收到的直播流数据进行解析或转码，并播放。

采集

采集分为音频采集和视频采集两个部分。

音频采集

通过麦克风等设备将环境中的模拟信号采集成 PCM 编码的原始数据。下面是关于音频的一些关键参数定义：

• 采样率： 每秒钟取得声音样本的次数。采样频率越高，数据量就越大，同时音频质量也就越高。
• 位宽：声卡的分辨率，它的数值越大，分辨率也就越高， 但数据量也越大。位宽的大小可以是：4bit、8bit、16bit、32bit 等等，常用的位宽是 8bit 或者 16bit。
• 声道数（channels）：声道数一般表示声音录制时的音源数量。如常见的单声道，就是声道数为1的。
• 音频帧：音频数据是流式的，本身没有明确的一帧帧的概念，一般约定俗成取 2.5ms~60ms为单位的数据量为一帧音频。这个时间被称之为“采样时间”，其长度没有特别的标准，它是根据编解码器和具体应用的需求来决定的。

视频采集

视频采集其实是一个图像采集的过程，视频的播放，其实也是一张张图片的快速切换。图像的采集过程主要由摄像头等设备拍摄成 YUV编码的原始数据，下面是视频的一些参数定义：

• 图像格式：通常采用 YUV 格式存储原始数据信息。
• 传输通道：正常情况下视频的拍摄只需 1 路通道，但如果是想拍一个全景视频，则需要通过不同角度拍摄，然后将多路视频数据合并。
• 分辨率：屏幕上的点、线和面都是由像素组成的，显示器可显示的像素越多，就越清晰，但数据量就越大。而分辨率就是指显示器所能显示的像素的多少。所以分辨率是一个很重要的参数。
• 采样率：跟音频的采样率类似，采样率越高，视频质量越好，数据量越大。
• 码率：码率(Data Rate)是指视频文件在单位时间内使用的数据流量。视频文件的码率越大，压缩比就越小，画面质量就越高。码率越大，说明单位时间内取样率越大，数据流，精度就越高。

处理

• 视频或者音频完成采集之后得到原始数据，为了增强一些现场效果或者加上一些额外的效果，我们一般会在将其编码压缩前进行处理，比如打上时间戳或者公司 Logo的水印，祛斑美颜和声音混淆等处理。

如上图所示，处理环节中分为音频和视频处理，音频处理中具体包含混音、降噪和声音特效等处理，视频处理中包含美颜、水印、以及各种自定义滤镜等处理。

常见视频处理功能

1.美颜

• 都说80% 的主播没有美颜根本没法看，美颜是直播产品中最常见的功能之一。美颜的主要原理是通过「磨皮+美白」来达到整体美颜的效果。磨皮的技术术语是「去噪」，也即对图像中的噪点进行去除或者模糊化处理，常见的去噪算法有均值模糊、高斯模糊和中值滤波等。
• 由于脸部的每个部位不尽相同，脸上的雀斑可能呈现出眼睛黑点的样子，对整张图像进行「去噪」处理的时候不需要将眼睛也去掉，因此这个环节中也涉及到人脸和皮肤检测技术。
• 直播系统中提供的 iOS 和 Android 推流 SDK 中内置了美颜功能，你可以根据自己的需要选择开关美颜功能，并且能够自由调节包括美颜，美白，红润等在内的参数。

2.视频水印

• 水印是图片和视频内容中常见的功能之一，它可用于简单是版权保护，或者进行广告设置。
• 在直播系统中提供的 iOS 和 Android 推流 SDK 中也内置了水印功能，可以根据自己的需要添加水印或移除水印，并且能够自由设置水印的大小和位置。

3.滤镜

• 除了上面提到的美颜和水印之外，滤镜的处理效果也在这个环节完成。

4.连麦

• 连麦是互动直播中常见的需求，主播和部分观众之间可以进行实时互动，然后将互动结果实时播放给其他观众观看。
• 基于以上业务需求，我们很容易想到基于单向直播原理，在主播端和连麦观众端进行双向推流和双向播流的方式互动，然后在服务端将两路推流合成一路推送给其他观众。但 RTMP 带来的延迟决定了这种方式无法做到用户可接受的互动直播。

实际上，互动直播的主要技术难点在于：

1. 低延迟互动：保证主播和互动观众之间能够实时互动，两者之间就像电话沟通，因此必须保证两者能在秒级以内听到对方的声音，看到对方的视频；
2. 音画同步：互动直播中对音画同步的需求和单向直播中类似，只不过互动直播中的延迟要求更高，必须保证在音视频秒级传输情况下的秒级同步。
3. 音视频实时合成：其他观众需要实时观看到对话结果，因此需要在客户端或者服务端将画面和声音实时合成，然后以低成本高品质的方式传输观众端。

编码

编码是一个数据压缩的过程。将音视频的原始数据，经过一系列算法，将其压缩，以减少数据量。而之所以要对数据进行压缩，是因为原始数据中存在大量的冗余。

数据冗余

• 如空间冗余、时间冗余、结构冗余、信息熵冗余等，即图像的各像素之间存在着很强的相关性。消除这些冗余并不会导致信息损失，属于无损压缩。 以时间冗余为例。序列图像（如电视图像和运动图像）一般是位于时间轴区间内的一组连续画面，其中的相邻帧，或者相邻场的图像中，在对应位置的像素之间，亮度和色度信息存在着极强的相关性。举个实际的例子说明一下，比如你拍一段视频，是一个苹果放在桌子上，一直没人动他，周围的光线也不会变化（室内嘛），那么这段时间的图像是相似的，也就存在冗余了。

视觉冗余

• 人眼的一些特性比如亮度辨别阈值，视觉阈值，对亮度和色度的敏感度不同，使得在编码的时候引入适量的误差，也不会被察觉出来。可以利用人眼的视觉特性，以一定的客观失真换取数据压缩。这种压缩属于有损压缩。

常见的视频编码格式如下：

视频编码格式	概述	特点
MPEG2-TS（又称TS、TP、MPEG-TS或M2T）	用于音效，图像与数据的通信协定，最早应用于DVD的实时传送节目	①动态带宽分配：由于TS的传输包长度是固定的，因此可过PID将规定的信道总频带在视频、音频和数据信息进行实时的、灵活的分配。利用这一特性，可在广播付费节目前实时地将解密钥匙插入到TS流中送给广大用户 ② 可分级性：允许一个复用的传输码流与其他视音频基本码流进行二次复用，生产占用频带给宽的更高一级的TS流 ③ 可扩展性 ④ 抗干扰性 ⑤ 接收机成本低廉
H.264	是高度压缩数字视频编解码器标准，广泛应用于Internet上的多媒体流服务、视频点播、可视游戏、低码率移动多媒体通信 (视频 手机等)、交互式多媒体应用、实时多媒体监控、数字电视与演播电视和虚拟视频会议等	①低码率（Low Bit Rate）：和MPEG2和MPEG4 ASP等压缩技术相比，在同等图像质量下，采用H.264技术压缩后的数据量只有MPEG2的1/8，MPEG4的1/3。 ②高质量的图像：H.264能提供连续、流畅的高质量图像（DVD质量）。 ③容错能力强：H.264提供了解决在不稳定网络环境下容易发生的丢包等错误的必要工具。 ④网络适应性强：H.264提供了网络抽象层，使得H.264的文件能容易地在不同网络上传输（例如互联网，CDMA，GPRS，WCDMA，CDMA2000等）。 ⑤H.264最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。
VC-1	起源于微软公司的Windows Media Video 9,是继MPEG-2 TS和H.264之后，最后被认可的高清编码标准格式.	①压缩比率高于MPEG2，低于H.264。 ②解码计算方面则更小一些，一般通过高性能的CPU就可以很流畅的观看高清视频。 ③一般来说，VC-1多为 “.wmv”后缀，但这不是绝对的
MPEG4	是一套用于音频、视频信息的压缩编码标准，主要用途在于网上流、光盘、语音发送，视频电话，以及电视广播。	①对于不同的对象可采用不同的编码算法，从而进一步提高压缩效率； ②对象各自相对独立，提高了多媒体数据的可重用性； ③允许用户对单个的对象操作，提供前所未有的交互性； ④允许在不同的对象之间灵活分配码率，对重要的对象可分配较多的字节，对次要的对象可分配较少的字节，从而能在低码率下获得较好的效果； ⑤可以方便的集成自然音视频对象和合成音视频对象。
DivX	DivX是一种将影片的音频由MP3来压缩、视频由MPEG-4技术来压缩的数字多媒体压缩格式。	①DivX就是从微软公司MPEG-4 v3编码技术中派生出的最为知名以及被广大DVDRipper广泛采用的视频编码技术。 ②最大程度上还原了DVD原本的画面质量，而且允许选择几乎所有格式的音频。 ③它的视频部分采用的是微软的MPEG－4技术进行压缩。
XviD	是目前世界上最常用的视频编码解码器	①是第一个真正开放源代码的，通过GPL协议发布。

封装

说到封装，可能很多人都会跟编码混在一起。其实两者是有区别的。区分封装和编码，要明确以下几点：

1. 不同的封装格式对编码各自的支持是不一样的。各种封装格式支持的编码格式可参考:Comparison of video container formats。而造成这个现象的原因，从编码的表格中也可以看出，编码是有专利权，拥有专利权的公司可以通过收取专利费来盈利。
2. 封装是一个把音频和视频数据整合在一起的过程，除此之外，还可以附带其他数据，如脚本（典型的如：FLV封装格式），字幕等信息。因此视频的封装格式，算是一种容器。真正的压缩，取决于编码格式。
3. 视频封装格式的存在是必要的，否则播放器无法实现进度条拖动等功能。
4. 经过了封装这一步才能，才构成了我们日常播放的视频文件。

推流

推流，指的是把采集阶段封装好的内容传输到服务器的过程。

传输

• 我们推送出去的流媒体需要传输到观众，整个链路就是传输网络，类比货运物流就是从出发地到目的地见的所有路程了，如果道路的容量不够，会引发堵车也就是网络拥塞，这时我们会改变路程也就是所谓的智能调度，但是传输网络会站在全局的角度进行调度，所以会比原子世界的调度有更好的效果.
• 常见的传输协议如下：

协议	传输和连接方式	客户端支持	优势	劣势
hls	HTTP短连接	ios/android端及H5原生支持，flash/PC端等需要自研播放器	支持广泛，HTTP请求支持简单，网络兼容性好，码率自适应，服务端及CDN支持好	延时太长，10s以上，单分片文件较小不便存储
http渐进式传输	HTTP长连接	flash支持，ios/android/PC端/H5需要自研	延迟相对较小，HTTP请求简单，网络兼容性好，服务端及CDN支持好	容易被劫持，多端兼容较为麻烦
rtp	UDP	Android端支持，其他各端都需要自研	延迟小	服务端逻辑复杂，协议及控制协议较难理解，开发周期长，客户端支持很难
dash	HTTP短连接	H5原生支持，其他端需要转换格式	开放标准支持广泛，码率自适应	服务端及商业CDN支持不够，使用不广泛
rtmp	TCP长连接	flash支持，其他需要自研	延迟较小	服务端压力相对较大，协议较为复杂，客户端兼容播放麻烦
私有协议	UDP	完全需要自研	延迟可以做到很小，保密性较好，业务自行扩展性高	开发难度极其大，客户端/协议定义/流服务端及CDN都需要自行开发支持，传输可靠性难以保证

转码

• 视频转码是指将已经压缩编码的视频码流转换成另一个视频码流，以适应不同的网络带宽、不同的终端处理能力和不同的用户需求。
• 转码本质上是一个先解码，再编码的过程，因此转换前后的码流可能遵循相同的视频编码标准，也可能不遵循相同的视频编码标准。 常见的转码需求有三种：

1. 不同视频格式间的转换，例如从MPEG-2或者MPEG-4转到H.264。
2. 内容传输，改变比特率满足不同网络带宽或者设备播放速度的需求。
3. 清晰度，将高清视频转为标清甚至更低的清晰度。

分发

• 直播流服务将数据分发给各个客户端，也就是每个用户的浏览器或App上。

拉流

• 把服务器已有的直播内容，用指定的地址进行拉取的过程。

播放

播放则是一个解封装，解编码的过程。具体需要经过以下几个步骤：解协议，解封装，解码视音频，视音频同步。如果播放本地文件则不需要解协议，为以下几个步骤：解封装，解码视音频，视音频同步。他们的过程如图所示:

 

Q&A

Q1:美颜功能工作在哪个阶段？

• 美颜功能工作在处理阶段。主播端打开设备(摄像头),采集音视频信息，此时，美颜滤镜SDK开始运转,对视频进行处理
• 美颜过的视频数据被编码、推流至服务器,通过CDN分发到各节点服务器上
• 用户拉取视频流、解码数据包，播放美颜后的直播视频
• 所以，美颜的工作，其实是从打开摄像头开始，就自动开始工作的，它被接入在程序上，且通常是以"美颜滤镜SDK"的形式出现。

Q2：在较差的网络状况下有哪些技术手段可以使用，用以提高视频主观感受或降低延迟？

• 移动网络下，通常容易遇到网络不稳定，连接被重置，断线重连，一方面频繁重连，建立连接需要开销。另一方面尤其是发生 GPRS / 2G / 3G / 4G 切换时，带宽可能出现瓶颈。

1. 当带宽不够，帧率较高/码率较高的内容较难发送出去，这个时候就需要可变码率支持。即在推流端，可检测网络状态和简单测速，动态来切换码率，以保障网络切换时的推流流畅。
2. 其次编码、封包、推流 这一部分的逻辑也可以做微调，可以尝试选择性丢帧，比如优先丢视频参考帧（不丢 I 帧和音频帧 )，这样也可以减少要传输的数据内容，但同时又达到了不影响画质和版视听流畅的目的。

Q3:直播过程中有哪些提高视频质量以及降低延迟的手段？

编码优化

1. 确保 Codec 开启了最低延迟的设置。Codec 一般都会有低延迟优化的开关，对于 H.264 来说其效果尤其明显。

2. 编码器一般都会有码控造成的延迟，一般也叫做初始化延迟或者视频缓存检验器 VBV 的缓存大小，把它当成编码器和解码器比特流之间的缓存，在不影响视频质量的情况下可以将其设置得尽可能小也可以降低延迟。

3. 如果是仅仅优化首开延迟，可以在视频帧间插入较多的关键帧，这样客户端收到视频流之后可以尽快解码。

4. 不要使用视频 MJPEG 的视频压缩格式，至少使用不带 B 帧的 MPEG4 视频压缩格式（Simple profile），甚至最好使用 H.264 baseline profile（X264 还有一个「-tune zerolatency」的优化开关）。这样一个简单的优化可以降低延迟，因为它能够以更低的码率编码全帧率视频。

5. 如果使用了 FFmpeg，降低「-probesize 」和「 -analyze duration」参数的值。

6. 使用可变码率编码 VBR 可以节省一些不必要的网络带宽，降低一定的延迟。

传输协议优化

1. 在服务端节点和节点之间尽量使用 RTMP 而非基于 HTTP 的 HLS 协议进行传输，这样可以降低整体的传输延迟。
2. 如果终端用户使用 RTMP 来播放，尽量在靠近推流端的收流节点进行转码，这样传输的视频流比原始视频流更小。
3. 如果有必要，可以使用定制的 UDP 协议来替换 TCP 协议，省去弱网环节下的丢包重传可以降低延迟。

传输网络优化

1. 在服务端节点中缓存当前 GOP，配合播放器端优化视频首开时间。

2. 服务端实时记录每个视频流流向每个环节时的秒级帧率和码率，实时监控码率和帧率的波动。

3. 客户端（推流和播放）通过查询服务端准实时获取当前最优节点，准实时下线当前故障节点和线路。

推流、播放优化

1. 考率发送端系统自带的网络 buffer 大小，系统可能在发送数据之前缓存数据，这个参数的调优也需要找到一个平衡点。
2. 播放端缓存控制对于视频的首开延迟也有较大影响，因此需要在直播的稳定性和首开延迟优化上找到平衡，调整优化缓冲区大小这个值。
3. 播放端动态 buffer 策略，在播放器开启的时候采用非常小甚至 0 缓存的策略，通过对下载首片视频的耗时来决定下一个时间片的缓存大小，同时在播放过程中实时监测当前网络，实时调整播放过程中缓存的大小。这样即可做到极低的首开时间，又可能够尽量消除网络抖动造成的影响。
4. 动态码率播放策略。除了动态调整 buffer 大小的策略之外，也可以利用实时监测的网络信息来动态调整播放过程中的码率，在网络带宽不足的情况下降低码率进行播放，减少延迟。