背景：
最近入行数字媒体行业，结合学习，总结一下音视频的传播知识，并会结合工作内容，加入自己的一些理解和体会。
Ⅰ、视频直播流程
（一）采集
（二）处理
（三）编码和封装
（四）推流和传输
（五）现代播放器原理
（六）延迟优化
（七）SDK性能测试模型
一、采集
采集是整个视频推流过程中的第一个环节，它从系统的采集设备中获取原始视频数据，将其输出到下一个环节。视频的采集涉及两方面数据的采集：音频采集和图像采集，它们分别对应两种完全不同的输入源和数据格式。
1.音频采集
音频数据既能与图像结合组合成视频数据，也能以纯音频的方式采集播放，后者在很多成熟的应用场景如在线电台和语音电台等起着非常重要的作用。音频的采集过程主要通过设备将环境中的模拟信号采集成PCM编码的原始数据，然后编码压缩成MP3等格式的数据分发出去。常见的音频压缩格式有：MP3、AAC、OGG、WMA、Opus、FLAC、APE、m4a和AMR等。
音频采集和编码主要面临的挑战在于：延时敏感、卡顿敏感、噪声消除（Denoise）、回声消除（AEC）、静音检测（VAD）和各种混音算法等。
在音频采集阶段，参考的主要技术参数有：
采样率（samplerate）：采样就是把模拟信号数字化的过程，采样频率越高，记录这一段音频信号所用的数据量就越大，同时音频质量也就越高。
位宽：每一个采样点都需要用一个数值来表示大小，这个数值的数据类型大小可以是：4bit、8bit、16bit、32bit等，位数越多，表示得就越精细，声音质量自然就越好，而数据量也会成倍增大。我们在音频采样过程中常用的位宽是8bit或者16bit。
声道数（channels）：由于音频的采集和播放是可以叠加的，因此，可以同时从多个音频源采集声音，并分别输出到不同的扬声器，故声道数一般表示声音录制时的音源数量或回放时相应的扬声器数量。声道数为1和2分别称为单声道和双声道，是比较常见的声道参数。
音频帧（frame）：音频跟视频很不一样，视频每一帧就是一张图像，而从上面的正玄波可以看出，音频数据是流式的，本身没有明确的一帧帧的概念，在实际的应用中，为了音频算法处理/传输的方便，一般约定俗成取2.5ms~60ms为单位的数据量为一帧音频。这个时间被称之为“采样时间”，其长度没有特别的标准，它是根据编解码器和具体应用的需求来决定的。
根据以上定义，我们可以计算一下一帧音频帧的大小。假设某音频信号是采样率为8kHz、双通道、位宽为16bit，20ms一帧，则一帧音频数据的大小为：
size = 8000 x 2 x 16bit x 0.02s = 5120 bit = 640 byte
2.图像采集
图像采集的图片结果组合成一组连续播放的动画，即构成视频中可肉眼观看的内容。图像的采集过程主要由摄像头等设备拍摄成YUV编码的原始数据，然后经过编码压缩成H.264等格式的数据分发出去。常见的视频封装格式有：MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB和WebM等。
图像由于其直观感受最强并且体积也比较大，构成了一个视频内容的主要部分。图像采集和编码面临的主要挑战在于：设备兼容性差、延时敏感、卡顿敏感以及各种对图像的处理操作如美颜和水印等。
在图像采集阶段，参考的主要技术参数有：
图像传输格式：通用影像传输格式（Common Intermediate Format）是视讯会议（video conference）中常使用的影像传输格式。
图像格式：通常采用YUV格式存储原始数据信息，其中包含用8位表示的黑白图像灰度值，以及可由RGB三种色彩组合成的彩色图像。
传输通道：正常情况下视频的拍摄只需1路通道，随着VR和AR技术的日渐成熟，为了拍摄一个完整的360°视频，可能需要通过不同角度拍摄，然后经过多通道传输后合成。
分辨率：随着设备屏幕尺寸的日益增多，视频采集过程中原始视频分辨率起着越来越重要的作用，后续处理环节中使用的所有视频分辨率的定义都以原始视频分辨率为基础。视频采集卡能支持的最大点阵反映了其分辨率的性能。
采样频率：采样频率反映了采集卡处理图像的速度和能力。在进行高度图像采集时，需要注意采集卡的采样频率是否满足要求。采样率越高，图像质量越高，同时保存这些图像信息的数据量也越大。
以上，构成了一个视频采集的主要技术参数，以及视频中音频和图像编码的常用格式。而对于直播App开发者来说，了解这些细节虽然更有帮助，但实际开发过程中可能很少能够关注采集环节中技术参数的控制，而是直接在SDK中将采集后的数据传递给下一个「处理」和「编码」环节。
采集源
1.摄像头采集
对于视频内容的采集，目前摄像头采集是社交直播中最常见的采集方式，比如主播使用手机的前置和后置摄像头拍摄。在现场直播场景中，也有专业的摄影、摄像设备用来采集。安防监控场景中也有专业的摄像头进行监控采集。
目前大多数直播厂商会提供的SDK对以上两类摄像头的采集都支持，对于手机，iOS和Android分别支持前置后置摄像头的采集，只是iOS由于设备种类和系统版本不多，因此采集模块兼容性较好；而Android需要适配的硬件设备和系统则非常多，目前支持Android 4.0.3及以上的摄像头采集。对于专业摄像机或者摄像头，厂商提供了兼容适合嵌入式系统的C语言采集模块的实现，欢迎参考使用：https://github.com/pili-engineering/ipcam_sdk
2.屏幕录制
屏幕录制采集的方式在游戏直播场景中非常常见，目前我们在Android SDK中实现了屏幕录制的功能。而iOS则由于系统本身没有开放屏幕录制的权限而没法直接操作，但对于iOS 9以上的版本，是有个取巧的办法，可以通过模拟一个AirPlay镜像连接到（当前App）自身，这样就可以在软件上捕获到屏幕上的任何操作，达到录制屏幕的效果。
在教育直播或者会场演讲场合，我们经常看见需要录制电脑桌面上PPT的场景，针对这种场景，目前市面上比较方便的方案是使用开源的桌面推流工具OBS来进行屏幕录制和推流：https://obsproject.com/
3.从视频文件推流
除了从硬件设备采集视频进行推流之外，我们也可能需要将一个视频或者音频文件以直播流的形式实时传输给观众，比如在线电台或者电视节目，它们的输入可能直接来自于一些已经录制剪辑好的视频内容。
开放式设计
以上从采集内容和采集源两个维度分别介绍了视频采集相关的知识，但对于采集源来说，市场上可见的采集源远远不止这三种，即便是摄像头也有很多分类。对于一个完整的覆盖推流、传输和播放三个环节的直播云服务来说，支持尽可能多的采集源和播放终端是一项既无法规避也很难完成的工作。
为了支持市场上所有采集源的接入，我们在SDK中采用了开放式的设计，只要采集源实现方遵循相应的接口，即可支持任意的采集源。
图中我们把采集的内容分为图像和音频，其中图像的采集源包含摄像头、屏幕录制或者本地的视频文件，甚至是其它需要重新定义和实现的采集源。而音频的采集源包含麦克风、系统声音或者本地音频文件，当然也可以为它定义别的输入源。
这样设计最大的好处在于，可以以轻量的设计方式支持丰富的采集源，而采集源的具体实现也可以交给使用者。
二、处理
我们将讲解常见视频处理功能如美颜、视频水印、滤镜、连麦等。
视频或者音频完成采集之后得到原始数据，为了增强一些现场效果或者加上一些额外的效果，我们一般会在将其编码压缩前进行处理，比如打上时间戳或者公司Logo的水印，祛斑美颜和声音混淆等处理。在主播和观众连麦场景中，主播需要和某个或者多个观众进行对话，并将对话结果实时分享给其他所有观众，连麦的处理也有部分工作在推流端完成。
一、开放式设计
如上图所示，处理环节中分为音频和视频处理，音频处理中具体包含混音、降噪和声音特效等处理，视频处理中包含美颜、水印、以及各种自定义滤镜等处理。对于直播云服务来说，为了满足所有客户的需求，除了要提供这些「标准」处理功能之外，我们还需要将该模块设计成可自由接入自定义处理功能的方式。
二、常见视频处理功能
1. 美颜
都说「80%的主播没有美颜根本没法看」，美颜是直播产品中最常见的功能之一。最近准备在香港上市的美图公司的主打产品就是美颜相机和美拍，有媒体戏称其会冲击化妆品行业，其实就是美颜的效果的功劳，让美女主播们不化妆也可以自信的直播，而美颜相机的用户则可以拍出「更好的自己」。
美颜的主要原理是通过「磨皮+美白」来达到整体美颜的效果。磨皮的技术术语是「去噪」，也即对图像中的噪点进行去除或者模糊化处理，常见的去噪算法有均值模糊、高斯模糊和中值滤波等。当然，由于脸部的每个部位不尽相同，脸上的雀斑可能呈现出眼睛黑点的样子，对整张图像进行「去噪」处理的时候不需要将眼睛也去掉，因此这个环节中也涉及到人脸和皮肤检测技术。
直播云提供的iOS和Android推流SDK中内置了美颜功能，你可以根据自己的需要选择开关美颜功能，并且能够自由调节包括美颜，美白，红润等在内的参数。其中iOS端SDK PLCameraStreamingKit的参数设置如下：
1）按照默认参数开启或关闭美颜：
-(void)setBeautifyModeOn:(BOOL)beautifyModeOn;
2）设置美颜程度，范围为0~1：
-(void)setBeautify:(CGFloat)beautify;
3）设置美白程度，范围为0~1：
-(void)setWhiten:(CGFloat)whiten;
4）设置红润程度，范围为0~1：
-(void)setRedden:(CGFloat)redden;
2. 视频水印
水印是图片和视频内容中常见的功能之一，它可用于简单是版权保护，或者进行广告设置。处于监管的需求，国家相关部门也规定视频直播过程中必须打上水印，同时直播的视频必须录制存储下来保存一定的时间，并在录制的视频上打上水印。
视频水印包括播放器水印和视频内嵌水印两种方式可供选择，对于播放器水印来说，如果没有有效的防盗措施，对于没有播放鉴权的推流，客户端拿到直播流之后可以在任何一个不带水印的播放器里面播放，因此也就失去了视频保护的能力。综合考虑云端录制对于水印的需求，我们一般会选择「视频内嵌水印」的方式打水印。
直播云提供的iOS和Android推流SDK中也内置了水印功能，你可以根据自己的需要添加水印或移除水印，并且能够自由设置水印的大小和位置。其中iOS端SDK PLCameraStreamingKit的参数设置如下：
1）添加水印
-(void)setWaterMarkWithImage:(UIImage *)wateMarkImage position:(CGPoint)position;
该方法将为直播流添加一个水印，水印的大小由wateMarkImage的大小决定，位置由position决定，需要注意的是这些值都是以采集数据的像素点为单位的。例如我们使用AVCaptureSessionPreset1280x720进行采集，同时wateMarkImage.size为(100, 100)对应的origin为(200, 300)，那么水印的位置将在大小为1280×720的采集画幅中位于(200, 300)的位置，大小为(100, 100)。
2）移除水印
-(void)clearWaterMark;
3. 滤镜
除了上面提到的美颜和水印之外，视频中还有很多其它的处理效果也在这个环节完成。直播云提供的SDK在开放性设计基础之上，通过数据源回调接口，可以支持各种自定义滤镜的接入。
为了实现丰富的滤镜效果，在iOS端可以考虑使用GPUImage这个库，这是一个开源的基于GPU的图片或视频的处理框架，内置了多达120多种常见的滤镜效果。有了它，添加实时的滤镜只需要简单地添加几行代码，还可以基于这个库自己写算法实现更丰富端效果。GPUImage地址：https://github.com/BradLarson/GPUImage
除了iOS端之外，Android也有GPUImage这个库的移植：https://github.com/CyberAgent/android-gpuimage
同时，Google官方也开源了一个伟大的库，覆盖了Android上面很多多媒体和图形图像相关的处理：https://github.com/google/grafika
4. 连麦
连麦是互动直播中常见的需求，其流程如上图所示。主播和部分观众之间可以进行实时互动，然后将互动结果实时播放给其他观众观看。基于以上业务需求，我们很容易想到基于单向直播原理，在主播端和连麦观众端进行双向推流和双向播流的方式互动，然后在服务端将两路推流合成一路推送给其他观众。但RTMP带来的延迟决定了这种方式无法做到用户可接受的互动直播。实际上，互动直播的主要技术难点在于：
1）低延迟互动：保证主播和互动观众之间能够实时互动，两者之间就像电话沟通，因此必须保证两者能在秒级以内听到对方的声音，看到对方的视频；
2）音画同步：互动直播中对音画同步的需求和单向直播中类似，只不过互动直播中的延迟要求更高，必须保证在音视频秒级传输情况下的秒级同步。
3）音视频实时合成：其他观众需要实时观看到对话结果，因此需要在客户端或者服务端将画面和声音实时合成，然后以低成本高品质的方式传输观众端。
在视频和电话会议领域，目前比较成熟的方案是使用思科或者WebEx的方案，但这些商用的方案一不开源，二比较封闭，三成本比较高。对于互动人数比较少的互动直播，目前市场上比较成熟的方案是使用基于WebRTC的实时通讯方案。
上图是一个基于WebRTC协议实现多方实时通讯的示意图，本地用户（主播）和远程用户（连麦观众）之间的连接通过RTCPeerConnection API管理，这个API包装了底层流管理和信令控制相关的细节。基于该方案可以轻松实现多人（14人以下）的多方实时通信，如下图所示：
当然，在通信人数少的情况下，其复杂度相对简单，如2人情况下。但人数增多至4人之后，其可选的网络结构就增多了，如上图所示，可以每个点之间形成自组织网络的方式通信，也可以以1人为中心形成星型通信网络，还可以让大家都通过一个集中式的服务端进行通信。
作为一个高性能、可伸缩的直播基础服务提供商，七牛直播云经过评估选择了以主播为中心形成星形通信网络，支持主播和多个观众之间的互动质量。同时，为了保证合成后的音视频实时传输到其他观众端，这里采用经过改造的UDP协议传输：
①通过UDP降低传输延迟；
②在UDP之上进行传输控制，保证用户互动体验QoS。
三、编码和封装
视频编码是本系列一个重要的部分，如果把整个流媒体比喻成一个物流系统，那么编解码就是其中配货和装货的过程，这个过程非常重要，它的速度和压缩比对物流系统的意义非常大，影响物流系统的整体速度和成本。同样，对流媒体传输来说，编码也非常重要，它的编码性能、编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本。
视频编码的意义
原始视频数据存储空间大，一个1080P的7s视频需要817MB
原始视频数据传输占用带宽大，10Mbps的带宽传输上述7s视频需要11分钟
而经过H.264编码压缩之后，视频大小只有708k,10Mbps的带宽仅仅需要500ms，可以满足实时传输的需求，所以从视频采集传感器采集来的原始视频势必要经过视频编码。
基本原理
那为什么巨大的原始视频可以编码成很小的视频呢？这其中的技术是什么呢？核心思想就是去除冗余信息：
空间冗余：图像相邻像素之间有较强的相关性
时间冗余：视频序列的相邻图像之间内容相似
编码冗余：不同像素值出现的概率不同
视觉冗余：人的视觉系统对某些细节不敏感
知识冗余：规律性的结构可由先验知识和背景知识得到
视频本质上讲是一系列图片连续快速的播放，最简单的压缩方式就是对每一帧图片进行压缩，例如比较古老的MJPEG编码就是这种编码方式，这种编码方式只有帧内编码，利用空间上的取样预测来编码。形象的比喻就是把每帧都作为一张图片，采用JPEG的编码格式对图片进行压缩，这种编码只考虑了一张图片内的冗余信息压缩，如图1，绿色的部分就是当前待编码的区域，灰色就是尚未编码的区域，绿色区域可以根据已经编码的部分进行预测（绿色的左边，下边，左下等）。
图 1
但是帧和帧之间因为时间的相关性，后续开发出了一些比较高级的编码器可以采用帧间编码，简单点说就是通过搜索算法选定了帧上的某些区域，然后通过计算当前帧和前后参考帧的向量差进行编码的一种形式，通过下面两个图2连续帧我们可以看到，滑雪的同学是向前位移的，但实际上是雪景在向后位移，P帧通过参考帧（I或其他P帧）就可以进行编码了，编码之后的大小非常小，压缩比非常高。
图 2
可能有同学对这两张图片怎么来的感兴趣，这里用了FFmpeg的两行命令来实现，具体FFmpeg的更多内容请看后续章节：
第一行生成带有移动矢量的视频
第二行把每一帧都输出成图片
ffmpeg -flags2 +export_mvs -i tutu.mp4 -vf codecview=mv=pf+bf+bb tutudebug2.mp4 ffmpeg -i tutudebug2.mp4 'tutunormal-d.bmp'
除了空间冗余和时间冗余的压缩，主要还有编码压缩和视觉压缩，下面是一个编码器主要的流程图：
图 3
图 4
图3、图4两个流程，图3是帧内编码，图4是帧间编码，从图上看到的主要区别就是第一步不相同，其实这两个流程也是结合在一起的，我们通常说的I帧和P帧就是分别采用了帧内编码和帧间编码。
编码器的选择
前面梳理了一下编码器的原理和基本流程，编码器经历了数十年的发展，已经从开始的只支持帧内编码演进到现如今的H.265和VP9为代表的新一代编码器，就目前一些常见的编码器进行分析，带大家探索一下编码器的世界。
1) H.264简介
H.264/AVC项目意图创建一种视频标准。与旧标准相比，它能够在更低带宽下提供优质视频（换言之，只有MPEG-2，H.263或MPEG-4第2部分的一半带宽或更少），也不增加太多设计复杂度使得无法实现或实现成本过高。另一目的是提供足够的灵活性以在各种应用、网络及系统中使用，包括高、低带宽，高、低视频分辨率，广播，DVD存储，RTP/IP网络，以及ITU-T多媒体电话系统。
H.264/AVC包含了一系列新的特征，使得它比起以前的编解码器不但能够更有效的进行编码，还能在各种网络环境下的应用中使用。这样的技术基础让H.264成为包括YouTube在内的在线视频公司采用它作为主要的编解码器，但是使用它并不是一件很轻松的事情，理论上讲使用H.264需要交纳不菲的专利费用。
专利许可
和MPEG-2第一部分、第二部分，MPEG-4第二部分一样，使用H.264/AVC的产品制造商和服务提供商需要向他们的产品所使用的专利的持有者支付专利许可费用。这些专利许可的主要来源是一家称为MPEG-LA LLC的私有组织，该组织和MPEG标准化组织没有任何关系，但是该组织也管理著MPEG-2第一部分系统、第二部分视频、MPEG-4第二部分视频和其它一些技术的专利许可。
其他的专利许可则需要向另一家称为VIA Licensing的私有组织申请，这家公司另外也管理偏向音频压缩的标准如MPEG-2 AAC及MPEG-4 Audio的专利许可。
H.264的开源实现
OpenH264
x264
OpenH264是思科实现的开源H.264编码，虽然H.264需要交纳不菲的专利费用，但是专利费有一个年度上限，思科把OpenH264实现的年度专利费交满后，OpenH264事实上就可以免费自由地使用了。
x264是一个采用GPL授权的视频编码自由软件。x264的主要功能在于进行H.264/MPEG-4 AVC的视频编码，而不是作为解码器（decoder）之用。
除去费用问题比较来看：
OpenH264CPU的占用相对x264低很多
OpenH264只支持baseline profile，x264支持更多profile
2) HEVC/H.265简介
高效率视频编码（High Efficiency Video Coding，简称HEVC）是一种视频压缩标准，被视为是ITU-T H.264/MPEG-4 AVC标准的继任者。2004年开始由ISO/IEC Moving Picture Experts Group（MPEG）和ITU-T Video Coding Experts Group（VCEG）作为ISO/IEC 23008-2 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分辨率）。
H.265的开源实现
libde265
x265
libde265 HEVC由struktur公司以开源许可证GNU LesserGeneral Public License(LGPL)提供，观众可以较慢的网速下欣赏到最高品质的影像。跟以前基于H.264标准的解码器相比，libde265 HEVC解码器可以将您的全高清内容带给多达两倍的受众，或者，减少50%流媒体播放所需要的带宽。高清或者4K/8K超高清流媒体播放，低延迟/低带宽视频会议，以及完整的移动设备覆盖。具有「拥塞感知」视频编码的稳定性，十分适合应用在3/4G和LTE网络。
x265是由MulticoreWare开发，并开源。采用GPL协议，但是资助这个项目的几个公司组成了联盟可以在非GPL协议下使用这个软件。
3) VP8简介
VP8是一个开放的视频压缩格式，最早由On2 Technologies开发，随后由Google发布。同时Google也发布了VP8编码的实做库：libvpx，以BSD授权条款的方式发行，随后也附加了专利使用权。而在经过一些争论之后，最终VP8的授权确认为一个开放源代码授权。
目前支持VP8的网页浏览器有Opera、Firefox和Chrome。
专利许可
2013年三月，Google与MPEG LA及11个专利持有者达成协议，让Google获取VP8以及其之前的VPx等编码所可能侵犯的专利授权，同时Google也可以无偿再次授权相关专利给VP8的用户，此协议同时适用于下一代VPx编码。至此MPEG LA放弃成立VP8专利集中授权联盟，VP8的用户将可确定无偿使用此编码而无须担心可能的专利侵权授权金的问题。
VP8 的开源实现
libvpx
libvpx是VP8的唯一开源实现，由On2 Technologies开发，Google收购后将其开放源码，License非常宽松可以自由使用。
4) VP9简介
VP9的开发从2011年第三季开始，目标是在同画质下，比VP8编码减少50%的文件大小，另一个目标则是要在编码效率上超越HEVC编码。
2012年12月13日，Chromium浏览器加入了VP9编码的支持。Chrome浏览器则是在2013年2月21日开始支持VP9编码的视频播放。
Google宣布会在2013年6月17日完成VP9编码的制定工作，届时Chrome浏览器将会把VP9编码默认引导。2014年3月18日，Mozilla在Firefox浏览器中加入了VP9的支持。
2015年4月3日，谷歌发布了libvpx1.4.0增加了对10位和12位的比特深度支持、4:2:2和4:4:4色度抽样，并VP9多核心编/解码。
专利许可
VP9是一个开放格式、无权利金的视频编码格式。
VP9的开源实现
libvpx
libvpx是VP9的唯一开源实现，由Google开发维护，里面有部分代码是VP8和VP9公用的，其余分别是VP8和VP9的编解码实现。
VP9和H.264和HEVC比较
HEVC和H.264在不同分辨率下的比较
跟H.264/MPEG-4相比，HEVC的平均比特率减低值为：
可见码率下降了60%以上。
HEVC(H.265)对VP9和H.264在码率节省上有较大的优势，在相同PSNR下分别节省了48.3%和75.8%。
H.264在编码时间上有巨大优势，对比VP9和HEVC(H.265)，HEVC是VP9的6倍，VP9是H.264的将近40倍
5) FFmpeg
谈到视频编码相关内容就不得不提一个伟大的软件包——FFmpeg。
FFmpeg是一个自由软件，可以运行音频和视频多种格式的录影、转换、流功能，包含了libavcodec——这是一个用于多个项目中音频和视频的解码器库，以及libavformat——一个音频与视频格式转换库。
FFmpeg这个单词中的FF指的是Fast Forward。有些新手写信给FFmpeg的项目负责人，询问FF是不是代表Fast Free或者Fast Fourier等意思，FFmpeg的项目负责人回信说：「Just for the record, the original meaning of FF in FFmpeg is Fast Forward.」
这个项目最初是由Fabrice Bellard发起的，而现在是由Michael Niedermayer在进行维护。许多FFmpeg的开发者同时也是MPlayer项目的成员，FFmpeg在MPlayer项目中是被设计为服务器版本进行开发。
FFmpeg下载地址是：https://ffmpeg.org/download.html
可以浏览器输入下载，目前支持Linux、Mac OS、Windows三个主流的平台，也可以自己编译到Android或者iOS平台。
如果是Mac OS，可以通过brew安装
brew install ffmpeg –with-libvpx –with-libvorbis –with-ffplay
我们可以用FFmpeg来做哪些有用有好玩的事情呢？通过一系列小实验来带大家领略FFmpeg的神奇和强大。
FFmpeg录屏
通过一个小例子看一下怎么在Mac OS下面使用FFmpeg进行录屏:
输入：
ffmpeg -f avfoundation -list_devices true -i ""
输出：
[AVFoundation input device @ 0x7fbec0c10940] AVFoundation video devices: [AVFoundation input device @ 0x7fbec0c10940] [0] FaceTime HD Camera [AVFoundation input device @ 0x7fbec0c10940] [1] Capture screen 0 [AVFoundation input device @ 0x7fbec0c10940] [2] Capture screen 1 [AVFoundation input device @ 0x7fbec0c10940] AVFoundation audio devices: [AVFoundation input device @ 0x7fbec0c10940] [0] Built-in Microphone
给出了当前设备支持的所有输入设备的列表和编号，我本地有两块显示器，所以1和2都是我屏幕，可以选择一块进行录屏。
查看当前的H.264编解码器：
输入：
ffmpeg -codecs | grep 264
输出：
DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vda ) (encoders: libx264 libx264rgb )
查看当前的VP8编解码器：
输入：
ffmpeg -codecs | grep vp8
输出：
DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx ) (encoders: libvpx )
可以选择用vp8或者h264做编码器
ffmpeg -r 30 -f avfoundation -i 1 -vcodec vp8 -quality realtime screen2.webm # -quality realtime 用来优化编码器，如果不加在我的 Air 上帧率只能达到 2
or
ffmpeg -r 30 -f avfoundation -i 1 -vcodec h264 screen.mp4
然后用ffplay播放就可以了
ffplay screen.mp4
or
ffplay screen2.webp
FFmpeg视频转换成gif
有一个特别有用的需求，在网上发现了一个特别有趣的视频想把她转换成一个动态表情，作为一个IT从业者，我第一个想到的不是下载一个转码器，也不是去找一个在线转换网站，直接利用手边的工具FFmpeg，瞬间就完成了转码：
ffmpeg -ss 10 -t 10 -i tutu.mp4 -s 80×60 tutu.gif ## -ss 指从 10s 开始转码,-t 指转换 10s 的视频 -s
FFmpeg录制屏幕并直播
可以继续扩展例子1，直播当前屏幕的内容，向大家介绍一下怎么通过几行命令搭建一个测试用的直播服务：
Step 1：首先安装docker：访问https://www.docker.com/products/docker，按操作系统下载安装。
Step 2：下载nginx-rtmp镜像：
docker pull chakkritte/docker-nginx-rtmp
Step 3：创建nginx html路径，启动docker-nginx-rtmp:
mkdir ~/rtmp docker run -d -p 80:80 -p 1935:1935 -v ~/rtmp:/usr/local/nginx/html chakkritte/docker-nginx-rtmp
Step 4：推送屏幕录制到nignx-rtmp:
ffmpeg -y -loglevel warning -f avfoundation -i 2 -r 30 -s 480×320 -threads 2 -vcodec libx264 -f flv rtmp://127.0.0.1/live/test
Step 5：用FFplay播放:
ffplay rtmp://127.0.0.1/live/test
总结一下，FFmpeg是个优秀的工具，可以通过它完成很多日常的工作和实验，但是距离提供真正可用的流媒体服务、直播服务还有非常多的工作要做，这方面可以参考直播云服务。
封装
介绍完了视频编码后，再来介绍一些封装。沿用前面的比喻，封装可以理解为采用哪种货车去运输，也就是媒体的容器。
所谓容器，就是把编码器生成的多媒体内容（视频，音频，字幕，章节信息等）混合封装在一起的标准。容器使得不同多媒体内容同步播放变得很简单，而容器的另一个作用就是为多媒体内容提供索引，也就是说如果没有容器存在的话一部影片你只能从一开始看到最后，不能拖动进度条（当然这种情况下有的播放器会话比较长的时间临时创建索引），而且如果你不自己去手动另外载入音频就没有声音，下面介绍几种常见的封装格式和优缺点：
1）AVI格式（后缀为.avi）：它的英文全称为Audio Video Interleaved，即音频视频交错格式。它于1992年被Microsoft公司推出。这种视频格式的优点是图像质量好。由于无损AVI可以保存alpha通道，经常被我们使用。缺点太多，体积过于庞大，而且更加糟糕的是压缩标准不统一，最普遍的现象就是高版本Windows媒体播放器播放不了采用早期编码编辑的AVI格式视频，而低版本Windows媒体播放器又播放不了采用最新编码编辑的AVI格式视频，所以我们在进行一些AVI格式的视频播放时常会出现由于视频编码问题而造成的视频不能播放或即使能够播放，但存在不能调节播放进度和播放时只有声音没有图像等一些莫名其妙的问题。
2）DV-AVI格式（后缀为.avi）：DV的英文全称是Digital Video Format，是由索尼、松下、JVC等多家厂商联合提出的一种家用数字视频格式。数字摄像机就是使用这种格式记录视频数据的。它可以通过电脑的IEEE 1394端口传输视频数据到电脑，也可以将电脑中编辑好的的视频数据回录到数码摄像机中。这种视频格式的文件扩展名也是AVI。电视台采用录像带记录模拟信号，通过EDIUS由IEEE 1394端口采集卡从录像带中采集出来的视频就是这种格式。
3）QuickTime File Format格式（后缀为.mov）：美国Apple公司开发的一种视频格式，默认的播放器是苹果的QuickTime。具有较高的压缩比率和较完美的视频清晰度等特点，并可以保存alpha通道。
4）MPEG格式（文件后缀可以是.mpg、.mpeg、.mpe、.dat、.vob、.asf、.3gp、.mp4等)：它的英文全称为Moving Picture Experts Group，即运动图像专家组格式，该专家组建于1988年，专门负责为CD建立视频和音频标准，而成员都是为视频、音频及系统领域的技术专家。MPEG文件格式是运动图像压缩算法的国际标准。MPEG格式目前有三个压缩标准，分别是MPEG－1、MPEG－2、和MPEG－4。MPEG－1、MPEG－2目前已经使用较少，着重介绍MPEG－4，其制定于1998年，MPEG－4是为了播放流式媒体的高质量视频而专门设计的，以求使用最少的数据获得最佳的图像质量。目前MPEG-4最有吸引力的地方在于它能够保存接近于DVD画质的小体积视频文件。
5）WMV格式（后缀为.wmv、.asf）：它的英文全称为Windows Media Video，也是微软推出的一种采用独立编码方式并且可以直接在网上实时观看视频节目的文件压缩格式。WMV格式的主要优点包括：本地或网络回放,丰富的流间关系以及扩展性等。WMV格式需要在网站上播放，需要安装Windows Media Player（简称WMP），很不方便，现在已经几乎没有网站采用了。
6）Real Video格式（后缀为.rm、.rmvb）：Real Networks公司所制定的音频视频压缩规范称为Real Media。用户可以使用RealPlayer根据不同的网络传输速率制定出不同的压缩比率，从而实现在低速率的网络上进行影像数据实时传送和播放。RMVB格式：这是一种由RM视频格式升级延伸出的新视频格式，当然性能上有很大的提升。RMVB视频也是有着较明显的优势，一部大小为700 MB左右的DVD影片，如果将其转录成同样品质的RMVB格式，其个头最多也就400 MB左右。大家可能注意到了，以前在网络上下载电影和视频的时候，经常接触到RMVB格式，但是随着时代的发展这种格式被越来越多的更优秀的格式替代，著名的人人影视字幕组在2013年已经宣布不再压制RMVB格式视频。
7）Flash Video格式（后缀为.flv）:由Adobe Flash延伸出来的的一种流行网络视频封装格式。随着视频网站的丰富，这个格式已经非常普及。
8）Matroska格式（后缀为.mkv）:是一种新的多媒体封装格式，这个封装格式可把多种不同编码的视频及16条或以上不同格式的音频和语言不同的字幕封装到一个Matroska Media档内。它也是其中一种开放源代码的多媒体封装格式。Matroska同时还可以提供非常好的交互功能，而且比MPEG的方便、强大。
9）MPEG2-TS格式(后缀为.ts)（Transport Stream「传输流」；又称MTS、TS）是一种传输和存储包含音效、视频与通信协议各种数据的标准格式，用于数字电视广播系统，如DVB、ATSC、IPTV等。MPEG2-TS定义于MPEG-2第一部分，系统（即原来之ISO/IEC标准13818-1或ITU-T Rec. H.222.0）。Media Player Classic、VLC多媒体播放器等软件可以直接播放MPEG-TS文件。
目前，我们在流媒体传输，尤其是直播中主要采用的就是FLV和MPEG2-TS格式，分别用于RTMP/HTTP-FLV和HLS协议。
四、推流和传输
推流是直播的第一公里，直播的推流对这个直播链路影响非常大，如果推流的网络不稳定，无论我们如何做优化，观众的体验都会很糟糕。所以也是我们排查问题的第一步，如何系统地解决这类问题需要我们对相关理论有基础的认识。
推送协议
下面就先介绍一下都有哪些推送协议，他们在直播领域的现状和优缺点。
-
RTMP
-
WebRTC
-
基于UDP的私有协议
RTMP
RTMP是Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。
RTMP是目前主流的流媒体传输协议，广泛用于直播领域，可以说市面上绝大多数的直播产品都采用了这个协议：
优点
-
CDN支持良好，主流的CDN厂商都支持
-
协议简单，在各平台上实现容易
缺点
-
基于TCP，传输成本高，在弱网环境丢包率高的情况下问题显著
-
不支持浏览器推送
-
Adobe私有协议，Adobe已经不再更新
WebRTC
WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。
目前主要应用于视频会议和连麦中，协议分层如下：
优点
-
W3C标准，主流浏览器支持程度高
-
Google在背后支撑，并在各平台有参考实现
-
底层基于SRTP和UDP，弱网情况优化空间大
-
可以实现点对点通信，通信双方延时低
缺点
-
ICE，STUN，TURN传统CDN没有类似的服务提供
基于UDP的私有协议
有些直播应用会使用UDP做为底层协议开发自己的私有协议，因为UDP在弱网环境下的优势通过一些定制化的调优可以达到比较好的弱网优化效果，但同样因为是私有协议也势必有现实问题：
优点
-
更多空间进行定制化优化
缺点
-
开发成本高
-
CDN不友好，需要自建CDN或者和CDN达成协议
-
独立作战，无法和社区一起演进
传输网络
我们推送出去的流媒体需要传输到观众，整个这个链路就是传输网络，类比货运物流就是从出发地到目的地见的所有路程了，如果道路的容量不够，会引发堵车也就是网络拥塞，这时我们会改变路程也就是所谓的智能调度，但是传输网络会站在全局的角度进行调度，所以会比原子世界的调度有更好的效果，可以想象有一个上帝在天空中俯视出发地和目的地间的所有的路况信息，而且还是实时的，然后给出你一条明路，何等的神奇，但这些我们在LiveNet中都已经实现了。
这里先回顾一下传统的内容分发网络。
为什么要有内容分发网络，内容分发网络的由来
互联网起源于美国军方的一个内部网络，Tim Berners-Lee是互联网发明者之一，他很早就预见到在不久的将来网络拥塞将成为互联网发展的最大障碍，于是他提出了一个学术难题，要发明一种全新的、从根本上解决问题的方法来实现互联网内容的无拥塞分发，这项学术难题最终催生出一种革新性的互联网服务——CDN。当时Berners-Lee博士隔壁是Tom Leighton教授的办公室，一位麻省理工学院应用数学教授，他被Berners-Lee的挑战激起了兴趣。Letghton最终解决了这个难题并开始自己的商业计划，成立了Akamai公司，成为世界上第一家CDN公司。
传统CDN的架构
上图是一个典型的CDN系统的三级部署示意图，节点是CDN系统中的最基本部署单元，分为三级部署，中心节点、区域节点和边缘节点，最上面一级是中心节点，中间一级是区域节点，边缘节点地理位置分散，为用户提供就近的内容访问服务。
下面介绍一下CDN节点的分类，主要分成两大类，骨干节点和POP节点，骨干节点又分为中心节点和区域节点：
-
骨干节点
-
中心节点
-
区域节点
-
POP节点
-
边缘节点
逻辑上来讲，骨干节点主要负责内容分发和边缘节点未命中时进行回源，POP节点主要负责提供给用户就近的内容访问服务。但如果CDN网络规模较大，边缘节点直接向中心节点回源会给中间层的核心设备造成的压力过大，在物理上引入区域节点，负责一个地理区域的管理，保存部分热点数据。
直播传输网络有别于传统CDN的痛点
随着Live时代的到来，直播成为当前CDN厂商的又一个主要的战场，那么Live时代CDN需要支持什么样的服务呢？
-
流媒体协议的支持，包括RTMP、HLS、HTTP-FLV等。
-
首屏秒开，从用户点击到播放控制在秒级以内
-
1~3延迟控制，从推流端到播放端，延迟控制在1~3秒之间
-
全球全网智能路由，可以利用整个CDN网络内的所有节点为某一单一用户服务，不受地域限制。随着全球一体化进程不断推进，跨区域、跨国家、跨洲的直播正变为常态，很可能主播在欧美，而用户在亚洲。
-
天级别的节点按需增加，中国公司出海已成大势，CDN需要更多的海外节点，如今比拼的更多的是海外节点可以快速部署，从提出节点增加需求到节点入网提供服务，需要达到一天之内，对CDN运维和规划提出非常高的要求。原有的月级别规划和入网满足不了先进的要求。
传统CDN的链路路由
CDN基于树状网络拓扑结构，每一层都有GSLB(Global Server Load Balancing)用于同一层内的多个CDN节点负载均衡，这样有什么好处呢？
前面提到的众多CDN的应用场景中，网页加速、视频加速、文件传输加速，都是同时依赖GSLB和Cache系统的，Cache系统是整个CDN系统中的成本所在，设计树形结构可以最大化的节省Cache系统的资本投入。因为只有中心节点需要保持机会所有的Cache副本，向下逐级减少，到了边缘节点只需要少量的热点Cache就可以命中大部分CDN访问请求，这样极大的降低了CDN网络的成本，也符合当时CDN用户的需求，可谓双赢。但是到了Live时代，直播业务是流式业务，很少涉及到Cache系统，基本都是播完就可以释放掉存储资源，即使因为政策原因有存储的需求也都是冷存储，对于存储的投入相对非常低廉，而且不要求存储在所有节点中，只要保证数据可回溯，可用即可。
我们看看树状网络拓扑，用户的链路选择数量是有限的，如下图，用户在某一个区域内可选择的链路数是：2*5=10
用户在某一区域内，则GSLB（通常在边缘节点这一层是Smart DNS）会把用户路由到该区域内的某个边缘节点，上一层又会路由到某个区域节点（这里的GSLB通常是内部的负载均衡器），最后又回溯到中心节点，中心节点会链接源站。
这里的假设是：
用户能访问的最快节点一定是该区域内的边缘节点，如果该区域没有边缘节点则最快的一定是逻辑相邻的区域内的边缘节点。
边缘节点能访问的最快节点一定是该区域内的区域节点，一定不会是其他区域的节点。
区域节点到中心节点一定是最快的，这个链路的速度和带宽都是最优的。
但实际真的如此么？引入了如此多的假设真的正确么？
实际上就算理论上我们可以证明以上假设有效，但是节点规划和区域配置大都依赖于人的设计和规划，我们知道人多是不靠谱的，而且就算当时区域规划正确，谁能保证这些静态的网络规划不会因为铺设了一条光纤或者因为某些IDC压力过大而发生了改变呢？所以我们可以跳出树状网络拓扑结构的桎梏，探索新的适合直播加速的网络拓扑结构。
为了摆脱有限的链路路由线路限制，激活整理网络的能力，我们可以把上述的节点变成网状网络拓扑结构：
我们看到一旦我们把网络结构改成了网状结构，则用户的可选择链路变为：无向图的指定两点间的所有路径，学过图论的同学都知道，数量惊人。
系统可以通过智能路由选择任何一个最快的链路而不用依赖于系统部署时过时的人工规划，无论是某些链路间增加了光纤或者某个IDC压力过大都可以实时的反映到整理网络中，帮助用户实时推倒出最优链路。这时我们可以去掉前面的一些假设，通过机器而不是人类来时实时规划网络的链路路由，这种实时大规模的计算任务天生就不是人类的强项，我们应该交给更适合的物种。
CDN的扩容
前面提到中国公司的出海已成大势，CDN海外节点的需求越来越大，遇到这种情况需要CDN厂商在新的区域部署新的骨干网和边缘节点，需要做详细的网络规划。时代发生变化，原来CDN用户都是企业级用户，本身业务线的迭代周期较长，有较长时间的规划，留给CDN厂商的时间也比较多。而互联网公司讲究的是速度，双周迭代已成常态，这里面涉及到成本和响应速度的矛盾，如果提前部署节点可以更好的为这些互联网公司服务，但是有较高的成本压力，反之则无法响应这些快速发展的互联网公司。
理想情况是，用户提出需求，CDN厂商内部评估，当天给出反馈，当天部署，客户当天就可以测试新区域的新节点。怎么解决？
答案是基于网状拓扑结构的对等网络，在网状拓扑结构中每个节点都是Peer，逻辑上每个节点提供的服务对等，不需要按区域设计复杂的网络拓扑结构，节点上线后不需要复杂的开局过程，直接上线注册节点信息，就可以对用户提供服务了,结合虚拟化技术前后时间理论上可以控制在一天之内。
回归本质：LiveNet
我们知道最早的互联网就是网状拓扑结构，后来才慢慢加入了骨干网来解决各种各样的问题，我们是时候该回归本质，拥抱下一代Live分发网络：LiveNet。总结前面的讨论，我们发现Live时代我们需要的内容分发网络是：
-
对Cache的要求没有以前那么高
-
对实时性的要求非常高
-
对节点运维的要求高，要更智能，尽量减少人工干预
-
对扩容这种运维事件响应度要求非常高
要做到如上几点，我们需要：
-
去中心化，网状拓扑
-
全球全网调度
-
节点无状态，节点对等
-
智能运维
以上这些就是LiveNet设计时候的斟酌，让运维更自动化，系统运行高度自治，依赖机器计算而不是人工判断，下面分别介绍一下。
去中心，网状拓扑
网状拓扑结构是设计的根本和基础，只有看清了我们对Cache需求的降低，网状拓扑结构才更有优势。
全球全网调度
基于全球一张网，不在受限于区域网络调度，将调度的范围从区域网络扩展到全球，全网内的节点都可以响应用户的请求，参与链路路由，不再先由人工假设选定一部分节点进行路由，去掉人工干预，让整个系统更智能。
节点无状态，节点对等
LiveNet节点无状态和节点对等都方便了运维，去掉了区域概念后的全球一张网让整个拓扑结构变的异常复杂，如果各个节点间有先后依赖关系，势必让运维成为噩梦，需要专有的服务编排系统，同时也给扩容带来困难，需要运维人员设计复杂的扩容方案，需要预演多次才敢在复杂的网络拓扑中扩容。当时如果节点本身对等且无状态，则运维和扩容都变的容易很多。
但整个系统在运行过程中还是会一些状态和数据需要保持，比如某些Live内容需要落地回放的需求，这些通过久经考验的七牛云存储来存储。
智能运维
智能运维建立在以上的「网状拓扑结构的对等网络」的基础上会变的容易的多。可以方便的下线有问题的节点而不影响整个LiveNet网络，可以方便快速的上线新节点，提升系统容量。通过节点的数据分析可以更好的了解整个网络的整体状态。
下面列举部分LiveNet采用的智能运维方案，让内容分发网络再次升级，以符合Live时代的要求。
监控节点健康状况，实时下线有问题的节点
-
Failover机制，保证服务一直可用
-
快速扩容
-
LiveNet VS P2P
最后我们和P2P网络做一个对比：
我们发现P2P方案，节点的可控性和链路的稳定性上还有很大提升空间，比较适合在实时性要求不高的场景使用、适合长尾需求，在Live的场景下面多是对实时性要求比较高的重度用户，无法忍受频繁的FailOver和节点质量参差不齐带来的网络抖动，但是如果是文件分发就比较适合用这种混合方案，可以有效降低CDN厂商成本，利用共享经济提高资源利用率。
介绍了推送和传输网络部分，我们已经把流媒体送到了观众的终端中，下一步就是把它展现在屏幕上了。
五、现代播放器原理
近年来，多平台适配需求的增长导致了流媒体自适应码率播放的兴起，这迫使Web和移动开发者们必须重新思考视频技术的相关逻辑。首先，巨头们分分发布了HLS、HDS和Smooth Streaming等协议，把所有相关细节都隐藏在它们专供的SDK中。开发者们没法自由的修改播放器中的多媒体引擎等逻辑：你没法修改自适应码率的规则和缓存大小，甚至是你切片的长度。这些播放器可能用起来简单，但是你没有太多去定制它的选择，即便是糟糕的功能也只能忍受。
但是随着不同应用场景的增加，可定制化功能的需求越来越强。仅仅是直播和点播之间，就存在不同的buffer管理、ABR策略和缓存策略等方面的差别。这些需求催生了一系列更为底层关于多媒体操作API的诞生：Flash上面的Netstream，HTML5上的Media Source Extensions，以及Android上的Media Codec，同时业界又出现了一个基于HTTP的标准流格式MPEG-DASH。这些更高级的能力为开发者提供了更好的灵活性，让他们可以构建适合自己业务需求的播放器和多媒体引擎。
今天我们来分享一下如何构建一个现代播放器，以及构建这样一个播放器需要哪些关键组件。通常来说，一个典型的播放器可以分解成三部分：UI、多媒体引擎和解码器，如图1所示：
图1 现代播放器架构
-
用户界面（UI）：这是播放器最上层的部分。它通过三部分不同的功能特性定义了终端用户的观看体验：皮肤（播放器的外观设计）、UI（所有可自定义的特性如播放列表和社交分享等）以及业务逻辑部分（特定的业务逻辑特性如广告、设备兼容性逻辑以及认证管理等）。
-
多媒体引擎：这里处理所有播放控制相关的逻辑，如描述文件的解析，视频片段的拉取，以及自适应码率规则的设定和切换等，我们将在下文中详细讲解这部分内容。由于这些引擎一般和平台绑定的比较紧，因此可能需要使用多种不同的引擎才能覆盖所有平台。
-
解码器和DRM管理器：播放器最底层的部分是解码器和DRM管理器，这层的功能直接调用操作系统暴露出来的API。解码器的主要功能在于解码并渲染视频内容，而DRM管理器则通过解密过程来控制是否有权播放。
接下来我们将使用例子来介绍各层所扮演的不同角色。
（一）用户界面（UI）
UI层是播放器的最上层，它控制了你的用户所能看到和交互的东西，同时也可以使用你自己的品牌来将其定制，为你的用户提供独特的用户体验。这一层最接近于我们说的前端开发部分。在UI内部，我们也包含了业务逻辑组件，这些组件构成了你播放体验的独特性，虽然终端用户没法直接和这部分功能进行交互。
UI部分主要包含三大组件：
1. 皮肤
皮肤是对播放器视觉相关部分的统称：进度控制条、按钮和动画图标等，如图2所示。和大部分设计类的组件一样，这部分组件也是使用CSS来实现的，设计师或者开发者可以很方便地拿来集成（即便你使用的是JW Player和Bitdash这种整套解决方案）。
图2 播放器皮肤
2. UI逻辑
UI逻辑部分定义了播放过程中和用户交互方面所有可见的交互：播放列表、缩略图、播放频道的选择以及社交媒体分享等。基于你预期达到的播放体验，还可以往这部分中加入很多其它的功能特性，其中有很多以插件的形式存在了，或许可以从中找到一些灵感：https://github.com/videojs/video.js/wiki/Plugins#community-plugins
UI逻辑部分包含的功能较多，我们不一一详细介绍，直接以Eurosport播放器的UI来作为例子直观感受一下这些功能。
图3 Eurosport播放器的用户界面
从图3可以看出，除了传统的UI元素之外，还有一个非常有趣的特性，在用户观看DVR流媒体的时候，直播以小视窗的形式展示，观众可以通过这个小窗口随时回到直播中。由于布局或者UI和多媒体引擎完全独立，这些特性在HTML5中使用dash.js只需要几行代码就能实现。
对于UI部分来说，最好的实现方式是让各种特性都以插件/模块的形式添加到UI核心模块中。
3. 业务逻辑
除了上面两部分「可见」的功能特性之外，还有一个不可见的部分，这部分构成了你业务的独特性：认证和支付、频道和播放列表的获取，以及广告等。这里也包含一些技术相关的东西，比如用于A/B测试模块，以及和设备相关的配置，这些配置用于在多种不同类型的设备之间选择多个不同的媒体引擎。
为了揭开底层隐藏的复杂性，我们在这里更详细的讲解一下这些模块：
设备检测与配置逻辑：这是最重要的特性之一，因为它将播放和渲染剥离开来了。例如，基于你浏览器的不同版本，播放器可能会自动为你选择一个基于HTML5 MSE的多媒体引擎hls.js，或者为你选择一个基于flash的播放引擎FlasHls来播放HLS视频流。这部分的最大特点在于，无论你使用什么样的底层引擎，在上层都可以使用相同的JavaScript或者CSS来定制你的UI或者业务逻辑。
能够检测用户设备的能力允许你按需配置终端用户的体验：如果是在移动设备而非4K屏幕设备上播放，你可能需要从一个较低的码率开始。
A/B测试逻辑：A/B测试是为了能够在生产环节中灰度部分用户。例如，你可能会给部分Chrome用户提供一个新的按钮或者新的多媒体引擎，并且还能保证它所有的工作都正常如期进行。
广告（可选）：在客户端处理广告是最复杂的业务逻辑之一。如videojs-contrib-ads这个插件模块的流程图给出一样，插入广告的流程中包含多个步骤。对于HTTP视频流来说，你或多或少会用到一些已有的格式如VAST、VPAID或者Google IMA，它们能够帮你从广告服务器中拉取视频广告（通常是过时的非自适应格式），放在视频的前期、中期和后期进行播放，且不可跳过。
总结
针对你的定制化需求，你可能选择使用包含所有经典功能的JW Player来播放（它也允许你定制部分功能），或者基于Videojs这样的开源播放器来定制你自己的功能特性。甚至为了在浏览器和原生播放器之间统一用户体验，你也可以考虑使用React Native来进行UI或者皮肤的开发，使用Haxe来进行业务逻辑的开发，这些优秀的库都可以在多种不同类型的设备之间共用同一套代码库。
图4 业务逻辑流程图
（二）多媒体引擎
近年来，多媒体引擎更是以一种全新独立的组件出现在播放器架构中。在MP4时代，平台处理了所有播放相关的逻辑，而只将一部分多媒体处理相关的特性（仅仅是播放、暂停、拖拽和全屏模式等功能）开放给开发者。
然而，新的基于HTTP的流媒体格式需要一种全新的组件来处理和控制新的复杂性：解析声明文件、下载视频片段、自适应码率监控以及决策指定等甚至更多。起初，ABR的复杂性被平台或者设备提供商处理了。然而，随着主播控制和定制播放器需求的递增，一些新的播放器中慢慢也开放了一些更为底层的API（如Web上的Media Source Extensons，Flash上的Netstream以及Android平台的Media Codec），并迅速吸引来了很多基于这些底层API的强大而健壮的多媒体引擎。
图5 Google提供的多媒体处理引擎Shakaplayer的数据流程图
接下来我们将详细讲解现代多媒体处理引擎中各组件的细节：
1. 声明文件解释和解析器
在基于HTTP的视频流中，一切都是以一个描述文件开始。该声明文件包含了媒体服务器所需理解的元信息：有多少种不同类型的视频质量、语言以及字母等，它们分别是什么。解析器从XML文件（对于HLS来说则是一种特殊的m3u8文件）中取得描述信息，然后从这些信息中取得正确的视频信息。当然，媒体服务器的类型很多，并不是所有都正确地实现了规范，因此解析器可能需要处理一些额外的实现错误。
一旦提取了视频信息，解析器则会从中解析出数据，用于构建流式的视觉图像，同时知道如何获取不同的视频片段。在某些多媒体引擎中，这些视觉图像先以一副抽象多媒体图的形式出现，然后在屏幕上绘制出不同HTTP视频流格式的差异特征。
在直播流场景中，解析器也必须周期性地重新获取声明文件，以便获得最新的视频片段信息。
2. 下载器（下载声明文件、多媒体片段以及密钥）
下载器是一个包装了处理HTTP请求原生API的模块。它不仅用于下载多媒体文件，在必要的时候也可以用于下载声明文件和DRM密钥。下载器在处理网络错误和重试方面扮演着非常重要的角色，同时能够收集当前可用带宽的数据。
注意：下载多媒体文件可能使用HTTP协议，也可能使用别的协议，如点对点实时通信场景中的WebRTC协议。
3. 流播放引擎
流播放引擎是和解码器API交互的中央模块，它将不同的多媒体片段导入编码器，同时处理多码率切换和播放时的差异性（如声明文件和视频切片的差异，以及卡顿时的自动跳帧）。
4. 资源质量参数预估器（带宽、CPU和帧率等）
预估器从各种不同的维度获取数据（块大小，每片段下载时间，以及跳帧数），并将其汇聚起来用于估算用户可用的带宽和CPU计算能力。这是输出用于ABR（Adaptive Bitrate，自适应码率）切换控制器做判断。
5. ABR切换控制器
ABR切换器可能是多媒体引擎中最为关键的部分——通常也是大家最为忽视的部分。该控制器读取预估器输出的数据（带宽和跳帧数），使用自定义算法根据这些数据做出判断，告诉流播放引擎是否需要切换视频或者音频质量。
该领域有很多研究性的工作，其中最大的难点在于在再缓冲风险和切换频率（太频繁的切换可能导致糟糕的用户体验）之间找到平衡。
6. DRM管理器（可选组件）
今天所有的付费视频服务都基于DRM管理，而DRM则很大程度上依赖于平台或者设备，我们将在后续讲解播放器的时候看到。多媒体引擎中的DRM管理器是更底层解码器中内容解密API的包装。
只要有可能，它会尽量通过抽象的方式来屏蔽浏览器或者操作系统实现细节的差异性。该组件通常和流处理引擎紧密连接在一起，因为它经常和解码器层交互。
7. 格式转换复用器（可选组件）
后文中我们将看到，每个平台在封包和编码方面都有它的局限性（Flash读的是FLV容器封装的H.264/AAC文件，MSE读的是ISOBMFF容器封装的H.264/AAC文件）。这就导致了有些视频片段在解码之前需要进行格式转换。例如，有了MPEG2-TS到ISOBMFF的格式转换复用器之后，hls.js就能使用MSE格式的内容来播放HLS视频流。多媒体引擎层面的格式转换复用器曾经遭受质疑；然而，随着现代JavaScript或者Flash解释权性能的提升，它带来的性能损耗几乎可以忽略不计，对用户体验也不会造成多大的影响。
总结
多媒体引擎中也有非常多的不同组件和特性，从字幕到截图到广告插入等。接下来我们也会单独写一篇文章来对比多种不同引擎的差异，通过一些测试和市场数据来为引擎的选择给出一些实质性的指导。值得注意的是，要构建一个兼容各平台的播放器，提供多个可自由替换的多媒体引擎是非常重要的，因为底层解码器是和用户平台相关的，接下来我们将重点讲解这方面的内容。
（三）解码器和DRM管理器
出于解码性能（解码器）和安全考虑（DRM），解码器和DRM管理器与操作系统平台密切绑定。
图6 解码器、渲染器和DRM工作流程图
1. 解码器
解码器处理最底层播放相关的逻辑。它将不同封装格式的视频进行解包，并将其内容解码，然后将解码后的视频帧交给操作系统进行渲染，最终让终端用户看到。
由于视频压缩算法变得越来越复杂，解码过程是一个需要密集计算的过程，并且为了保证解码性能和流畅的播放体验，解码过程需要强依赖于操作系统和硬件。现在的大部分解码都依赖于GPU加速解码的帮助（这也是为什么免费而更强大的VP9解码器没有赢得H.264市场地位的原因之一）。如果没有GPU的加速，解码一个1080P的视频就会占去70%左右的CPU计算量，并且丢帧率还可能很严重。
在解码和渲染视频帧的基础之上，管理器也提供了一个原生的buffer，多媒体引擎可以直接与该buffer进行交互，实时了解它的大小并在必要的时候刷新它。
我们前面提到，每个平台都有它自己的渲染引擎和相应的API：Flash平台有Netstream，Android平台有Media Codec API，而Web上则有标准的Media Sources Extensions。MSE越来越吸引眼球，将来可能会成为继浏览器之后其它平台上的事实标准。
2. DRM管理器
图7 DRM管理器
今天，在传输工作室生产的付费内容的时候，DRM是必要的。这些内容必须防止被盗，因此DRM的代码和工作过程都向终端用户和开发者屏蔽了。解密过的内容不会离开解码层，因此也不会被拦截。
为了标准化DRM以及为各平台的实现提供一定的互通性，几个Web巨头一起创建了通用加密标准Common Encryption（CENC）和通用的多媒体加密扩展Encrypted Media Extensions，以便为多个DRM提供商（例如，EME可用于Edge平台上的Playready和Chrome平台上的Widewine）构建一套通用的API，这些API能够从DRM授权模块读取视频内容加密密钥用于解密。
CENC声明了一套标准的加密和密钥映射方法，它可用于在多个DRM系统上解密相同的内容，只需要提供相同的密钥即可。
在浏览器内部，基于视频内容的元信息，EME可以通过识别它使用了哪个DRM系统加密，并调用相应的解密模块（Content Decryption Module，CDM）解密CENC加密过的内容。解密模块CDM则会去处理内容授权相关的工作，获得密钥并解密视频内容。
CENC没有规定授权的发放、授权的格式、授权的存储、以及使用规则和权限的映射关系等细节，这些细节的处理都由DRM提供商负责。
（四）总结
今天我们深入了解了一下视频播放器三个层面的不同内容，这个现代播放器结构最优秀之处在于其交互部分完全和多媒体引擎逻辑部分分离，让主播可以无缝而自由灵活地定制终端用户体验，同时在多种不同终端设备上使用不同的多媒体引擎还能保证顺利播放多种不同格式的视频内容。
在Web平台，得益于多媒体引擎如dash.js、Shaka Player和hls.js这些趋于成熟库的帮助，MSE和EME正在成为播放的新标准，同时越来越多有影响力的厂家也使用这些播放引擎。近年来，注意力也开始投向机顶盒和互联网电视，我们也看到越来越多这样的新设备使用MSE来作为其底层多媒体处理引擎。我们也将持续投入更多的力量去支持这些标准。
六、直播延迟优化
我们在很多线上和线下场合分享了如何优化直播体验，详细讲解了各部分造成低延迟和卡顿的原因和相应的优化原理。实际上，音视频直播系统是一个复杂的工程系统，要做到非常低延迟的直播，需要复杂的系统工程优化和对各组件非常熟悉的掌握。这里面我们再分享几个简单而常用的调优技巧。
编码优化
-
确保Codec开启了最低延迟的设置。Codec一般都会有低延迟优化的开关，对于H.264来说其效果尤其明显。很多人可能不知道H.264的解码器正常情况下会在显示之前缓存一定的视频帧，对于QCIF分辨率大小的视频（176×144）一般会缓存16帧，对于720P的视频则缓存5帧。对于第一帧的读取来说，这是一个很大的延迟。如果你的视频不是使用H.264来编码压缩的，确保没有使用到B帧，它对延迟也会有较大的影响，因为视频中B帧的解码依赖于前后的视频帧，会增加延迟。
-
编码器一般都会有码控造成的延迟，一般也叫做初始化延迟或者视频缓存检验器VBV的缓存大小，把它当成编码器和解码器比特流之间的缓存，在不影响视频质量的情况下可以将其设置得尽可能小也可以降低延迟。
-
如果是仅仅优化首开延迟，可以在视频帧间插入较多的关键帧，这样客户端收到视频流之后可以尽快解码。但如果需要优化传输过程中的累计延迟，尽可能少使用关键帧也就是I帧（GOP变大），在保证同等视频质量的情况下，I帧越多，码率越大，传输所需的网络带宽越多，也就意味着累计延迟可能越大。这个优化效果可能在秒级延迟的系统中不是很明显，但是在100ms甚至更低延迟的系统中就会非常明显。同时，尽量使用ACC-LC Codec来编码音频，HE-ACC或者HE-ACC 2虽然编码效率高，但是编码所需时间更长，而产生更大体积的音频造成的传输延迟对于视频流的传输来说影响更小。
-
不要使用视频MJPEG的视频压缩格式，至少使用不带B帧的MPEG4视频压缩格式（Simple profile），甚至最好使用H.264 baseline profile（X264还有一个「-tune zerolatency」的优化开关）。这样一个简单的优化可以降低延迟，因为它能够以更低的码率编码全帧率视频。
-
如果使用了FFmpeg，降低「-probesize」和「-analyze duration」参数的值，这两个值用于视频帧信息监测和用于监测的时长，这两个值越大对编码延迟的影响越大，在直播场景下对于视频流来说analyzeduration参数甚至没有必要设定。
-
固定码率编码CBR可以一定程度上消除网络抖动影响，如果能够使用可变码率编码VBR可以节省一些不必要的网络带宽，降低一定的延迟。因此建议尽量使用VBR进行编码。
传输协议优化
在服务端节点和节点之间尽量使用RTMP而非基于HTTP的HLS协议进行传输，这样可以降低整体的传输延迟。这个主要针对终端用户使用HLS进行播放的情况。
如果终端用户使用RTMP来播放，尽量在靠近推流端的收流节点进行转码，这样传输的视频流比原始视频流更小。
如果有必要，可以使用定制的UDP协议来替换TCP协议，省去弱网环节下的丢包重传可以降低延迟。它的主要缺点在于，基于UDP协议进行定制的协议的视频流的传输和分发不够通用，CDN厂商支持的是标准的传输协议。另一个缺点在于可能出现丢包导致的花屏或者模糊（缺少关键帧的解码参考），这就要求协议定制方在UDP基础之上做好丢包控制。
传输网络优化
我们曾经介绍过七牛直播云的实时流传输网络，它是一种新型的节点自组织的网状传输网络，既适合国内多运营商网络条件下的传输优化，也适合众多海外直播的需求。
在服务端节点中缓存当前GOP，配合播放器端优化视频首开时间。
服务端实时记录每个视频流流向每个环节时的秒级帧率和码率，实时监控码率和帧率的波动。
客户端（推流和播放）通过查询服务端准实时获取当前最优节点（5秒一次），准实时下线当前故障节点和线路。
推流、播放优化
考察发送端系统自带的网络buffer大小，系统可能在发送数据之前缓存数据，这个参数的调优也需要找到一个平衡点。
播放端缓存控制对于视频的首开延迟也有较大影响，如果仅优化首开延迟，可以在0缓存情况下在数据到达的时候立即解码。但如果在弱网环境下为了消除网络抖动造成的影响，设置一定的缓存也有必要，因此需要在直播的稳定性和首开延迟优化上找到平衡，调整优化缓冲区大小这个值。
播放端动态buffer策略，这是上面播放端缓存控制的改进版本。如果只是做0缓存和固定大小的缓存之间进行选择找到平衡，最终还是会选择一个固定大小的缓存，这对亿级的移动互联网终端用户来说并不公平，他们不同的网络状况决定了这个固定大小的缓存并不完全合适。因此，我们可以考虑一种「动态buffer策略」，在播放器开启的时候采用非常小甚至0缓存的策略，通过对下载首片视频的耗时来决定下一个时间片的缓存大小，同时在播放过程中实时监测当前网络，实时调整播放过程中缓存的大小。这样即可做到极低的首开时间，又可能够尽量消除网络抖动造成的影响。
动态码率播放策略。除了动态调整buffer大小的策略之外，也可以利用实时监测的网络信息来动态调整播放过程中的码率，在网络带宽不足的情况下降低码率进行播放，减少延迟。
以上，是我们在低延迟优化方面的部分技巧。实际上我们优化低延迟的时候并不是只关注「低延迟」，而是在保证其它条件不影响用户体验的情况下尽量做到低延迟，因此它的内容涉及到更多广泛的话题。而视频直播的优化也包含方方面面，这里只分享了其中经过我们实践的部分。随着实践的积累，我们接下来会在线上和线下分享更多关于视频直播甚至点播的优化技巧。
七、SDK性能测试模型
直播云SDK性能测试模型，SDK的性能对最终App的影响非常大。SDK版本迭代快速，每次发布前都要进行系统的测试，测试要有比较一致的行为，要有性能模型作为理论基础，对SDK的性能做量化评估。本文就是来探讨影响SDK性能的指标并建立相应的性能模型的。
影响视频质量和大小的重要参数
在进行测试之前我们需要明确几个对视频质量和大小影响最大的参数：帧率、码率和分辨率。
1. 如何制定帧率
一帧就是一副静止的画面，连续的帧就形成动画，如电视图象等。我们通常说帧数，简单地说，就是在1秒钟时间里传输的图片的数，也可以理解为图形处理器每秒钟能够刷新几次，通常用fps（Frames Per Second）表示。每一帧都是静止的图象，快速连续地显示帧便形成了运动的假象。高的帧率可以得到更流畅、更逼真的动画。每秒钟帧数（fps）愈多，所显示的动作就会愈流畅。
2. 如何制定码率
我们首先看视频编码的目的，它是为了在有限的带宽中传输尽可能清晰的视频，我们以每秒25帧的图像举例，25帧图像中定义了GOP组，目前主要是有I，B，P帧三种帧格式。I帧是关键帧，你可以想象它就是一幅JPEG压缩图像，而B，P帧是依靠I帧存在的，如果丢失了I帧，B，P帧是看不到图像的，B，P帧描述的不是实际的图像像素内容，而是每个相关像素的变化量，他们相对于I帧信息量会很小。GOP组是指一个关键帧I帧所在的组的长度，每个GOP组只有1个I帧。
我们再来看，一组画面的码流大小跟什么有关？当视频编码的压缩方式都一样，清晰度要求都一样的时候，GOP组的长度格式决定了码流的大小，例如：每秒25帧画面，GOP组长度为5，那么帧格式为IBPBP,那么1秒钟有5个I帧，10个B帧，10个P帧，如果GOP组长度为15，帧格式就是IBBPBBPBBPBBPBB，那么1秒钟内会有2个I帧和16个B帧和7个P帧，那么5个I帧比2个I帧占用的数据信息量大，所以GOP组的长度格式也决定了码流的大小。
3. 如何指定分辨率
分辨率概念视频分辨率是指视频成像产品所成图像的大小或尺寸。常见的视像分辨率有640×480，1088×720，1920×1088。在成像的两组数字中，前者为图片长度，后者为图片的宽度，两者相乘得出的是图片的像素。
影响SDK性能的指标
有了上述的前置知识，我们可以开始准备测试SDK的性能了，我们首先分析一下都有哪些指标可以反映SDK的性能，分成Android和iOS两个平台：
Android
-
GC：可以通过GC日志记录，Mirror GC和Full GC的频次和时间，Full GC会造成比较明显的卡顿，需要评估
-
UI Loop就是VSync Loop：反映SDK对App流畅度的影响，理论上60 fps是最流畅的值。
-
Memory：反映SDK占用内存的大小
-
CPU Usage：反映SDK占用计算资源的大小
iOS
-
UI Loop：反映SDK对App流畅度的影响，理论上60 fps是最流畅的值。
-
Memory：反映SDK占用内存的大小
-
CPU Usage：反映SDK占用计算资源的大小
除了上面的一些系统级别的指标外，下面是直播SDK中特有的一些指标，这些指标可以反映出SDK的核心竞争力和一些主要的差异，涉及到视频的清晰度和流畅度，也是可以量化的。
1. 影响视频清晰度的指标
-
帧率
-
码率
-
分辨率
-
量化参数（压缩比）
2. 影响视频流畅度的指标
-
码率
-
帧率
3. 其他重要指标
直播是流量和性能的消耗大户，有一些指标，直接影响了用户的感受，也是我们需要重点关注的：
-
耗电量
-
发热（不好量化，大部分情况发热和耗电量正比，可以使用耗电量暂时替代）
测试计划
测试过程需要先固化一些测试条件，然后根据不同的测试条件得出测试结果，这里选择了两个现在最常见的条件，是我们通过回访大量客户得出的一些统计数字，可以反映大部分直播应用所处的场景。主要从分辨率、视频处理、码率和网络环境几个维度进行限制。
最后分为几个两种测试指标：客观和主观指标，前者反映了SDK对系统的消耗程度，但虽说是客观指标也并非对用户没有影响，只是说得出的结果用户感受不明显。主观指标则会直接影响最终用户体验，但在传统的测试中反而容易被忽略，因为不好量化，这里抛砖引玉地提出一些量化的方式，希望引起读者的思考。
测试条件A
-
分辨率480p
-
无水印，无美颜
-
码率1M
-
网络保证在0.5M~2M
这个条件，反映了大部分低速网络情况下的使用场景，也反映了SDK基本的性能情况，可以作为SDK基本推流和拉流情况下的基准测试，不引入太多的测试依赖。
测试条件B
-
分辨率720p
-
无水印，有美颜
-
码率1M
-
网络保证在0.5M~2M
这个条件，反映了大部分客户的使用场景，具有较高的分辨率和美颜视频处理，可以作为SDK竞品分析的重要依据，测试结果非常接近真实场景。
1. 客观指标测试计划
客观影响App稳定性和性能的指标：
-
Memory
-
测试10分钟，内存曲线
-
测试1小时，TP99，TP95，TP90，需要归档
-
测试1小时，内存增量，考察是否有内存泄露，需要归档
-
参考值：上次结果
-
CPU
-
测试10分钟，CPU Usage曲线
-
测试10分钟，TP99，TP95，TP90，需要归档
-
参考值：上次结果
-
码率
-
测试10分钟，TP99，TP95，TP90，重点说明，这里的码率控制需要分开来看，如果网络抖动造成码率降低，这样的点不计入进来，只测试SDK码率控制，需要归档
-
参考值：1M（大小都是偏差）
-
耗电量
-
测试一小时，记录进程总耗电量、屏幕显示耗电量、CPU耗电量，需要归档
-
参考值：上次结果
2. 主观指标测试计划
主观影响App使用者的指标：
-
UI Loop App本身可以达到的最大帧率，不同于视频帧率，统计他的原因是我们的SDK可能会影响整个App的流畅度，需要跟踪
-
测试10分钟，UI Loop曲线
-
测试10分钟，UI Loop TP99、TP95、TP90，需要归档反复比较
-
参考值：60fps
-
Android GC
-
测试1小时，记录Mirror GC和Full GC的频次，记录GC时长的TP99、TP95、TP90，需要归档反复比较
-
参考值：上次结果
-
帧率（fps）
-
测试10分钟，TP99，TP95，TP90，需要归档反复比较
-
参考值：30fps
-
PSNR比较视频清晰度的指标
-
测试10分钟，需要归档反复比较，这个指标可以使用固定视频作为输入。
-
参考值：上次结果
3. 结果显示
-
表格显示具体指标
-
曲线显示原始数据和时间轴的数据
-
热图显示和参考值的偏差
-
热图显示距离上次归档值是改善了还是恶化了
通过这种反复迭代的自动化、系统化的测试，我们以职人之心近乎偏执地反复打磨着SDK的性能，只为给最终用户带来最好的直播体验，帮助我们的客户通过次时代的媒体最大化自己的商业价值，希望在您披荆斩棘的路上我们始终相伴。
Ⅱ、点播
— 稍后补充完善
–参考博客
（一）采集 https://blog.csdn.net/qiansg123/article/details/80125045
（二）处理 https://blog.csdn.net/qiansg123/article/details/80125093
（三）编码和封装 https://blog.csdn.net/qiansg123/article/details/80125150
（四）推流和传输 https://blog.csdn.net/qiansg123/article/details/80125220
（五）现代播放器原理 https://blog.csdn.net/qiansg123/article/details/80125641
（六）延迟优化 https://blog.csdn.net/qiansg123/article/details/80125628
（七）SDK性能测试模型 https://blog.csdn.net/qiansg123/article/details/80125664
相关博文：https://blog.csdn.net/qiansg123/article/details/80127960
https://blog.csdn.net/qiansg123/article/details/80125107
https://blog.csdn.net/qiansg123/article/details/80124294
https://www.jianshu.com/p/59ee53e00b9f
https://www.jianshu.com/p/6b8a4337e129