直播中的各个环节：
1.采集
采集是播放环节中的第一环，iOS 系统因为软硬件种类不多，硬件适配性较好，所以比较简单。Android 则不同，市面上硬件机型非常多，难以做到一个库适配所有硬件。PC 端的采集也跟各种摄像头驱动有关，推荐使用目前市面上最好用的 PC 端开源免费软件 OBS。
2.处理
「80% 的主播没有美颜根本没法看。」不光是美颜，很多其它的视频处理如模糊效果、水印等也都是在这个环节做。目前 iOS 端比较知名的是 GPUImage 这个库，提供了丰富端预处理效果，还可以基于这个库自己写算法实现更丰富端效果。Android 也有 GPUImage 这个库的移植，叫做 android-gpuimage。同时，Google 官方开源了一个伟大的库，覆盖了 Android 上面很多多媒体和图形图像相关的处理。
3.编码
编码主要难点有两个：1. 处理硬件兼容性问题。2. 在高 fps、低 bitrate 和音质画质之间找到平衡。iOS 端硬件兼容性较好，可以直接采用硬编。而 Android 的硬编的支持则难得多，需要支持各种硬件机型，推荐使用软编。
4.推流和传输
传输涉及到很多端：从主播端到服务端，从收流服务端到边缘节点，以及再从边缘节点到观众端。
推流端和分发端理论上需要支持的并发用户数应该都是亿级的，不过毕竟产生内容的推流端在少数，和消费内容端播放端不是一个量级，但是他们对推流稳定性和速度的要求比播放端高很多，这涉及到所有播放端能否看到直播，以及直播端质量如何。
很多人吐槽现在的 CDN 不靠谱，我也承认传统的 CDN 在新时代显得心有余力不足。你能够借助 CDN 快速实现大规模的流分发，但是稳定高速的推流上传可能还需要自己做很多工作。因此，我们七牛打造了一个直播专属的实时流网络，接下来我们会重点介绍这个网络和传统 CDN 的差别。
5.转码
为了让主播推上来的流适配各个平台端各种不同协议，需要在服务端做一些流处理工作，比如转码成不同格式支持不同协议如 RTMP、HLS 和 FLV，一路转多路流来适配各种不同的网络状况和不同分辨率的终端设备。
同时，为了配合一些运营需求，比如一些监管部门的要求，我们在服务端也提供了内容识别如鉴黄的功能。
6.解码和渲染
解码和渲染，也即音视频的播放，目前 iOS 端的播放兼容性较好，在延迟可接受的情况下使用 HLS 协议是最好的选择，我们也提供了能够播放 RTMP 和 HLS 的播放器 SDK。Android 的硬件解码和编码一样也存在兼容性问题，目前比较好的开源播放器是基于 ffplay 的 ijkplayer，我们也基于此实现了一个更好的 Android SDK。
除了 SDK 的介绍之外，我们将重点介绍播放器的原理，以及现代视频播放器的基本架构。
7.直播场景化解决方案
除了整个直播流程的介绍之外，我们将围绕当下最火的直播场景如社交直播和游戏直播，介绍它背后的技术方案。这些技术方案不仅涉及到七牛这样的直播基础服务，还可能涉及到和场景相关的其它技术，如社交直播下的聊天、点赞和弹幕的支持。
采集内容
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 的水印，祛斑美颜和声音混淆等处理。在主播和观众连麦场景中，主播需要和某个或者多个观众进行对话，并将对话结果实时分享给其他所有观众，连麦的处理也有部分工作在推流端完成。
开放式设计
如上图所示，处理环节中分为音频和视频处理，音频处理中具体包含混音、降噪和声音特效等处理，视频处理中包含美颜、水印、以及各种自定义滤镜等处理。对于七牛这样的直播云服务来说，为了满足所有客户的需求，除了要提供这些「标准」处理功能之外，我们还需要将该模块设计成可自由接入自定义处理功能的方式。
iOS SDK 地址：https://github.com/pili-engineering/PLMediaStreamingKit
Android SDK 地址：https://github.com/pili-engineering/PLDroidMediaStreaming
常见视频处理功能
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 带来的延迟决定了这种方式无法做到用户可接受的互动直播。
实际上，互动直播的主要技术难点在于：
低延迟互动：保证主播和互动观众之间能够实时互动，两者之间就像电话沟通，因此必须保证两者能在秒级以内听到对方的声音，看到对方的视频；
音画同步：互动直播中对音画同步的需求和单向直播中类似，只不过互动直播中的延迟要求更高，必须保证在音视频秒级传输情况下的秒级同步。
音视频实时合成：其他观众需要实时观看到对话结果，因此需要在客户端或者服务端将画面和声音实时合成，然后以低成本高品质的方式传输观众端。
在视频和电话会议领域，目前比较成熟的方案是使用思科或者 WebEx 的方案，但这些商用的方案一不开源，二比较封闭，三成本比较高。对于互动人数比较少的互动直播，目前市场上比较成熟的方案是使用基于 WebRTC 的实时通讯方案。
上图是一个基于 WebRTC 协议实现多方实时通讯的示意图，本地用户（主播）和远程用户（连麦观众）之间的连接通过 RTCPeerConnection API 管理，这个 API 包装了底层流管理和信令控制相关的细节。基于该方案可以轻松实现多人（14 人以下）的多方实时通信，如下图所示：
当然，在通信人数少的情况下，其复杂度相对简单，如 2 人情况下。但人数增多至 4 人之后，其可选的网络结构就增多了，如上图所示，可以每个点之间形成自组织网络的方式通信，也可以以 1 人为中心形成星型通信网络，还可以让大家都通过一个集中式的服务端进行通信。
作为一个高性能、可伸缩的直播基础服务提供商，七牛直播云经过评估选择了以主播为中心形成星形通信网络，支持主播和多个观众之间的互动质量。同时，为了保证合成后的音视频实时传输到其他观众端，这里采用经过改造的 UDP 协议传输：
通过 UDP 降低传输延迟。
在 UDP 之上进行传输控制，保证用户互动体验 QoS。
