相关文档
什么是视频？
首先我们需要理解一个最基本的概念：视频。从感性的角度来看，视频就是一部充满趣味的影片，可以是电影，可以是短片，是一连贯的视觉冲击力表现丰富的画面和音频。但从理性的角度来看，视频是一种有结构的数据，用工程的语言解释，我们可以把视频剖析成如下结构：
内容元素 ( Content )
- 图像 ( Image )
- 音频 ( Audio )
- 元信息 ( Metadata )
编码格式 ( Codec )
- Video : H.264，H.265, …
- Audio : AAC， HE-AAC, …
容器封装 (Container)
MP4，MOV，FLV，RM，RMVB，AVI，…任何一个视频 Video 文件，从结构上讲，都是这样一种组成方式：
- 由图像和音频构成最基本的内容元素；
- 图像经过视频编码压缩格式处理（通常是 H.264）；
- 音频经过音频编码压缩格式处理（例如 AAC）；
- 注明相应的元信息（Metadata）；
最后经过一遍容器（Container）封装打包（例如 MP4），构成一个完整的视频文件。
如果觉得难以理解，可以想象成一瓶番茄酱。最外层的瓶子好比这个容器封装（Container），瓶子上注明的原材料和加工厂地等信息好比元信息（Metadata），瓶盖打开（解封装）后，番茄酱本身好比经过压缩处理过后的编码内容，番茄和调料加工成番茄酱的过程就好比编码（Codec），而原材料番茄和调料则好比最原本的内容元素（Content）。
再进一步解释，静止的画面叫图像（picture）。连续的图像变化每秒超过24帧（frame）画面以上时，根椐视觉暂留原理，人眼无法辨别每付单独的静态画面，看上去是平滑连续的视觉效果。这样的连续画面叫视频。
视频播放流程
解协议的作用，就是将流媒体协议的数据，解析为标准的相应的封装格式数据。视音频在网络上传播的时候，常常采用各种流媒体协议，例如HTTP，RTMP，或是MMS等等。这些协议在传输视音频数据的同时，也会传输一些信令数据。这些信令数据包括对播放的控制（播放，暂停，停止），或者对网络状态的描述等。解协议的过程中会去除掉信令数据而只保留视音频数据。例如，采用RTMP协议传输的数据，经过解协议操作后，输出FLV格式的数据。
解封装的作用，就是将输入的封装格式的数据，分离成为音频流压缩编码数据和视频流压缩编码数据。封装格式种类很多，例如MP4，MKV，RMVB，TS，FLV，AVI等等，它的作用就是将已经压缩编码的视频数据和音频数据按照一定的格式放到一起。例如，FLV格式的数据，经过解封装操作后，输出H.264编码的视频码流和AAC编码的音频码流。
解码的作用，就是将视频/音频压缩编码数据，解码成为非压缩的视频/音频原始数据。音频的压缩编码标准包含AAC，MP3，AC-3等等，视频的压缩编码标准则包含H.264，MPEG2，VC-1等等。解码是整个系统中最重要也是最复杂的一个环节。通过解码，压缩编码的视频数据输出成为非压缩的颜色数据，例如YUV420P，RGB等等；压缩编码的音频数据输出成为非压缩的音频抽样数据，例如PCM数据。
视音频同步的作用，就是根据解封装模块处理过程中获取到的参数信息，同步解码出来的视频和音频数据，并将视频音频数据送至系统的显卡和声卡播放出来。
色彩空间
色彩空间一词源于英文的“Color Space”，色彩学中，人们建立了多种色彩模型，以一维、二维、三维甚至四维空间坐标来表示某一色彩，这种用坐标系统来定义的色彩范围即色彩空间。
例如计算机监视器上显示颜色的时候，通常使用 RGB（红色、绿色、蓝色）色彩空间定义，红色、绿色、蓝色被当作 X、Y 和 Z坐标轴。
我们经常用到的色彩空间主要有RGB、YUV, CMYK, HSB, HSL等等，其中YUV和RGB是视讯通信领域用的较多的二种色彩空间。
1. RGB
计算机色彩显示器和彩色电视机显示色彩的原理一样，都是采用R、G、B相加混色的原理，通过发射出三种不同强度的电子束，使屏幕内侧覆盖的红、绿、蓝磷光材料发光而产生色彩。这种色彩的表示方法称为RGB色彩空间表示。
目前的显示设备大都是采用了RGB色彩空间，RGB是从颜色的原理来设计定的，它的颜色混合方式就如有红、绿、蓝三盏灯，当它们的光相互叠合的时候，色彩相混，亮度等于两者亮度之总和，即加法混合。
屏幕上的不同颜色，都由这红色，绿色，蓝色三种基本色光按照不同的比例（权重）混合而成的。一组红色绿色蓝色就是一个最小的显示单位。屏幕上的任何一个颜色都可以由一组RGB值来记录和表达。因此这红色绿色蓝色又称为三原色光，用英文表示就是R(red)、G(green)、B(blue)。RGB的所谓“多少”就是指亮度，并使用整数来表示。在用8位表示时，RGB各有256级亮度，用数字量化表示为从0、1、2...直到255。注意虽然数字最高是255，但0也是数值之一，因此共256级。
如下图表示RGB色彩空间从R,G,B三个维度看到的图像。
2. YUV
YUV(亦称YCrCb)是被欧洲电视系统所采用的一种颜色编码方法。在现代彩色电视系统中，通常采用三管彩色摄像机或彩色CCD摄影机进行取像，然后把取得的彩色图像信号经分色、分别放大校正后得到RGB，再经过矩阵变换电路得到亮度信号Y和两个色差信号R-Y(即U)、B-Y(即V)，最后发送端将亮度和两个色差总共三个信号分别进行编码，用同一信道发送出去。这种色彩的表示方法就是所谓的YUV色彩空间表示。
YUV色彩空间的重要性是它的亮度信号Y和色度信号U、V是分离的。如果只有Y信号分量而没有U、V分量，那么这样表示的图像就是黑白灰度图像。彩色电视采用YUV空间正是为了用亮度信号Y解决彩色电视机与黑白电视机的兼容问题，使黑白电视机也能接收彩色电视信号。
YUV色彩空间的Y亮度和色度信号U、V是分离还有一个优点是，人眼对亮度敏感，对色度不敏感。减少部分UV的数据量，但人眼感知不到。
如下图表示YUV色彩空间从Y,U,V三个维度看到的图像。
编解码介绍
视频编码的主要作用是将视频像素数据（RGB，YUV等）压缩成为视频码流，从而降低视频的数据量。如果视频不经过压缩编码的话，体积通常是非常大的，一部电影可能就要上百G的空间。视频编码是视音频技术中最重要的技术之一。视频码流的数据量占了视音频总数据量的绝大部分。高效率的视频编码在同等的码率下，可以获得更高的视频质量。
举个直播上的栗子：我们知道从 CCD 采集到的图像格式一般的 RGB 格式的（BMP），这种格式的存储空间非常大，它是用三个字节描述一个像素的颜色值，如果是 1080P 分辨率的图像空间：1920 x 1080 x 3 = 6MB，就算转换成 JPG 也有近 200KB，如果是每秒 12 帧用 JPG 也需要近 2.4MB/S 的带宽，这带宽在公网上传输是无法接受的。
视频编码器就是为了解决这个问题的，它会根据前后图像的变化做运动检测，通过各种压缩把变化的发送到对方，1080P 进行过 H.264 编码后带宽也就在 200KB/S ~ 300KB/S 左右。
我们平时所看到的视频，理论上就是一帧帧的图片连续的播放，形成动画效果。那么完整的保存所有图片，所占用的空间是非常巨大的。视频编码就是为了压缩这些图片，以节省空间。我先讲一下简单的理论，比如一秒钟的视频通常有24帧，这24张图画大部分区域可能都比较相近，那么我们是不是可以找到一种方法，只保存一张完整图片（我们称为关键帧），不保存其他图片，只保存和这个完整图片的不同（通过某种数学建模表达），这样就会节省很多空间，在播放的时候，通过和关键帧与每一帧的不同逆向恢复成一张完整的图片，这样就得到了24张完整的图片。（这里只是举例，实际应用中并不一定是每24帧图像被设定一个关键帧）。OK，那么所谓编码格式就指的一种压缩视频图像的算法。
H.264编码介绍
H.264是新一代的编码标准，以高压缩高质量和支持多种网络的流媒体传输著称，在编码方面，它的理论依据是：一段时间内图像的统计结果表明，在相邻几幅图像画面中，一般有差别的像素只有10%以内的点，亮度差值变化不超过2%，而色度差值的变化只有1%以内。所以对于一段变化不大的图像画面，我们可以先编码出一个完整的图像帧A，随后的B帧不编码全部图像，只写入与A帧的差别，这样B帧的大小就只有完整帧的1/10或更小！B帧之后的C帧如果变化不大，我们可以继续以参考B的方式编码C帧，这样循环下去。这段图像我们称为一个序列，当某个图像与之前的图像变化很大，无法参考前面的帧来生成，那我们就结束上一个序列，开始下一段序列。
编码器将多张图像进行编码后生产成一段一段的 GOP ( Group of Pictures )。
GOP是一组连续的画面，由一张 I 帧和数张 B / P 帧组成，是视频图像编码器和解码器存取的基本单位，它的排列顺序将会一直重复到影像结束。
I 帧是内部编码帧（也称为关键帧），P 帧是前向预测帧（前向参考帧），B 帧是双向内插帧（双向参考帧）。简单地讲，I 帧是一个完整的画面，而 P 帧和 B 帧记录的是相对于 I 帧的变化。
I、B、P各帧是根据压缩算法的需要，是人为定义的，它们都是实实在在的物理帧。一般来说，I帧的压缩率是7，P帧是20，B帧可以达到50。可见使用B帧能节省大量空间，节省出来的空间可以用来保存多一些I帧，这样在相同码率下，可以提供更好的画质。
在视频编码序列中,一个I帧所占用的字节数大于一个P帧，一个P帧所占用的字节数大于一个B帧。所以，在码率不变的前提下，GOP值越大，P、B帧的数量会越多，画面细节更多，也就更容易获取较好的图像质量。
小结一下，一个视频 ( Video ) ，其图像部分的数据是一组 GOP 的集合, 而单个 GOP 则是一组 I / P / B 帧图像的集合。
在这样的一种几何关系中，Video 好比一个 “物体”，GOP 好比 “分子”，I / P / B 帧的图像则好比 “原子”。
想象一下，如果我们把传输一个 “物体”，改成传输一个一个的 “原子”，将最小颗粒以极高的速度传送，那么以人的生物肉眼来感知，将是一种怎样的体验？
视频的实时传输
不难脑洞大开一下，直播就是这样的一种体验。视频直播技术，就是将视频内容的最小颗粒 ( I / P / B 帧，…)，基于时间序列，以高速进行传送的一种技术。
简而言之，直播就是将每一帧数据 ( Video / Audio / Data Frame )，打上时序标签 ( Timestamp ) 后进行流式传输的过程。发送端源源不断的采集音视频数据，经过编码、封包、推流，再经过中继分发网络进行扩散传播，播放端再源源不断地下载数据并按时序进行解码播放。如此就实现了 “边生产、边传输、边消费” 的直播过程。
流媒体协议
1. RTSP协议
该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。
2. RTMP协议
RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据实时传输开发的开放协议，因为是开放协议所以都可以使用。
RTMP协议用于对象、视频、音频的传输，这个协议建立在TCP协议或者轮询HTTP协议之上。
RTMP协议就像一个用来装数据包的容器，这些数据可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。
3. HLS协议
HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现基于HTTP的流媒体传输协议，传输内容包括两部分，一是M3U8描述文件，二是TS媒体文件。可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。
相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。
FFmpeg
FFmpeg的名称来自MPEG视频编码标准，前面的“FF”代表“Fast Forward”，FFmpeg是一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序。可以轻易地实现多种视频格式之间的相互转换。
FFmpeg的用户有Google、Facebook、Youtube、VLC、优酷、爱奇艺、土豆、Mplayer、射手播放器、暴风影音、KMPlayer、QQ影音、格式工厂、狸窝视频转换器、暴风转码等。
FFmpeg函数库
libavutil：简化编程的工具函数库，包括随机数生成器，数据结构，数学函数，多媒体核心工具函数等等。
libavcodec：包含音视频编解码的库。
libavformat：包含复用，解复用(封装格式处理)多媒体容器的库。
libavdevice：包含输入/输出设备的库，它能从一些通用的软件框架中抓取数据，也能将多媒体数据送到一些通用软件框架中去渲染。这些通用软件框架包括：Video4Linux，Video4Linux2,VfW以及ALSA等。
libavfilter：滤镜特效处理。
libswscale：用于执行高性能的图像缩放，颜色空间或像素格式转换的库。
libswresample：用于执行高性能音频重采样，重矩阵化（rematrixing，不确定翻译是否准确）
，采样格式转换以及混音（主要是声道转换（如5.1声道转到立体声等））等功能的库。
直播整体流程
推流端（采集、美颜处理、编码、推流）、服务端处理（转码、录制、截图、鉴黄）、播放器（拉流、解码、渲染）、互动系统（聊天室、礼物系统、赞）。
直播优化
1. 秒开优化
改写播放器逻辑让播放器拿到第一个关键帧后就给予显示。GOP 的第一帧通常都是关键帧，由于加载的数据较少，可以达到 “首帧秒开”。如果直播服务器支持 GOP 缓存，意味着播放器在和服务器建立连接后可立即拿到数据，从而省却跨地域和跨运营商的回源传输时间。
GOP 体现了关键帧的周期，也就是两个关键帧之间的距离，即一个帧组的最大帧数。假设一个视频的恒定帧率是 24fps（即1秒24帧图像），关键帧周期为 2s，那么一个 GOP 就是 48 张图像。一般而言，每一秒视频至少需要使用一个关键帧。
增加关键帧个数可改善画质（GOP 通常为 FPS 的倍数），但是同时增加了带宽和网络负载。这意味着，客户端播放器下载一个 GOP，毕竟该 GOP 存在一定的数据体积，如果播放端网络不佳，有可能不是能够快速在秒级以内下载完该 GOP，进而影响观感体验。
2. 马赛克、卡顿
如果 GOP 分组中的P帧丢失会造成解码端的图像发生错误,其实这个错误表现出来的就是马赛克。因为中间连续的运动信息丢失了，H.264 在解码的时候会根据前面的参考帧来补齐，但是补齐的并不是真正的运动变化后的数据，这样就会出现颜色色差的问题，这就是所谓的马赛克现象，如图：
这种现象不是我们想看到的。为了避免这类问题的发生，一般如果发现 P 帧或者 I 帧丢失，就不显示本 GOP 内的所有帧，直到下一个 I 帧来后重新刷新图像。但是 I 帧是按照帧周期来的，需要一个比较长的时间周期，如果在下一个 I 帧来之前不显示后来的图像，那么视频就静止不动了，这就是出现了所谓的卡顿现象。如果连续丢失的视频帧太多造成解码器无帧可解，也会造成严重的卡顿现象。视频解码端的卡顿现象和马赛克现象都是因为丢帧引起的，最好的办法就是让帧尽量不丢。
3. 传输协议优化
在服务端节点和节点之间尽量使用 RTMP 而非基于 HTTP 的 HLS 协议进行传输，这样可以降低整体的传输延迟。这个主要针对终端用户使用 HLS 进行播放的情况。
如果终端用户使用 RTMP 来播放，尽量在靠近推流端的收流节点进行转码，这样传输的视频流比原始视频流更小。
如果有必要，可以使用定制的 UDP 协议来替换 TCP 协议，省去弱网环节下的丢包重传可以降低延迟。它的主要缺点在于，基于 UDP 协议进行定制的协议的视频流的传输和分发不够通用，CDN 厂商支持的是标准的传输协议。另一个缺点在于可能出现丢包导致的花屏或者模糊（缺少关键帧的解码参考），这就要求协议定制方在 UDP 基础之上做好丢包控制。
4. 传输网络优化
在服务端节点中缓存当前 GOP，配合播放器端优化视频首开时间。
服务端实时记录每个视频流流向每个环节时的秒级帧率和码率，实时监控码率和帧率的波动。
客户端（推流和播放）通过查询服务端准实时获取当前最优节点（5 秒一次），准实时下线当前故障节点和线路。
5. 推流、播放优化
考察发送端系统自带的网络 buffer 大小，系统可能在发送数据之前缓存数据，这个参数的调优也需要找到一个平衡点。
播放端缓存控制对于视频的首开延迟也有较大影响，如果仅优化首开延迟，可以在 0 缓存情况下在数据到达的时候立即解码。但如果在弱网环境下为了消除网络抖动造成的影响，设置一定的缓存也有必要，因此需要在直播的稳定性和首开延迟优化上找到平衡，调整优化缓冲区大小这个值。
播放端动态 buffer 策略，这是上面播放端缓存控制的改进版本。如果只是做 0 缓存和固定大小的缓存之间进行选择找到平衡，最终还是会选择一个固定大小的缓存，这对亿级的移动互联网终端用户来说并不公平，他们不同的网络状况决定了这个固定大小的缓存并不完全合适。因此，我们可以考虑一种「动态 buffer 策略」，在播放器开启的时候采用非常小甚至 0 缓存的策略，通过对下载首片视频的耗时来决定下一个时间片的缓存大小，同时在播放过程中实时监测当前网络，实时调整播放过程中缓存的大小。这样即可做到极低的首开时间，又可能够尽量消除网络抖动造成的影响。
动态码率播放策略。除了动态调整 buffer 大小的策略之外，也可以利用实时监测的网络信息来动态调整播放过程中的码率，在网络带宽不足的情况下降低码率进行播放，减少延迟。
