随便说说

视频直播从16年大爆发，好多应用飞出来

主流app

主流几个app

• 斗鱼
• YY
• 虎牙
• 熊猫
• 冲顶大会
• 企鹅电竞
• now直播

归纳为3大类

• 真人秀直播
• 游戏直播
• 答题直播

交互场景

• 真人秀---> 主播，摄像头直播，主播唱歌跳舞啥的--用户操作 点赞 送礼 评论
• 游戏直播 --> 主播 主画面是主播游戏界面（游戏第一视角），小窗口主播实时头像--用户操作 评论 送礼 点赞 分享
• 答题---> 主画面 主持人巴拉巴拉和念题目 严格时间控制，在视频里主持人念完题目后app显示题目内容和答题选项，并在规定时间内给出答题结果--用户操作 规定时间答题 分享得复活机会 奖金平分

技术浅析 与实现方案

视频直播技术图

需要了解的技术有

• 摄像头采集；
• 音视频编解码；
• 流媒体协议；
• 音视频流推送到流媒体服务器；
• 流媒体网络分发；
• 用户播放器；
• 音视频同步；
• 网络延迟自适应；
• 需要录制，多种视频文件的格式和封装；
• 语言：C、C++、html、php、mysql......
• 开发环境：嵌入式，Linux，Windows，Web......

高度简单化过程（字体特别大）

视频/音频 采集
|
|
|
美颜、滤镜、降噪
|
|
|
封装 编码传输
|
|
|
云平台实时截图，做一些额外处理（转码 加密 鉴权 鉴黄 录制 统计等 ）
|
|
|
用户端播放

视频/音频 采集

• 1摄像头采集

对于视频内容的采集，目前摄像头采集是社交直播中最常见的采集方式，比如主播使用手机的前置和后置摄像头拍摄。在现场直播场景中，也有专业的摄影、摄像设备用来采集。安防监控场景中也有专业的摄像头进行监控采集。

这里有一个七牛提供的 SDK，对以上两类摄像头的采集都支持，对于手机，iOS 和 Android 分别支持前置后置摄像头的采集，只是 iOS 由于设备种类和系统版本不多，因此采集模块兼容性较好；而 Android 需要适配的硬件设备和系统则非常多，目前支持 Android 4.0.3 及以上的摄像头采集。对于专业摄像机或者摄像头，此SDK提供了兼容适合嵌入式系统的 C 语言采集模块的实现，仅供参考：https://github.com/pili-engineering/ipcam_sdk

• 2屏幕录制
  屏幕录制采集的方式在游戏直播场景中非常常见
  安卓 使用Android系统提供的录屏API进行画面采集，并由RTMP SDK底层模块负责编码和RTMP推流
  ios iOS 10.0 系统以后开始支持，基于iOS系统的扩展方式实现，即游戏直播开始时，iOS系统会唤起支持录屏直播的系统扩展（由直播App负责安装），并将屏幕图像传给这个系统扩展并由它完成编码和直播推流。

在教育直播或者会场演讲场合，我们经常看见需要录制电脑桌面上 PPT 的场景，针对这种场景，目前市面上比较方便的方案是使用开源的桌面推流工具 OBS 来进行屏幕录制和推流：https://obsproject.com/

• 3 音频采集
  音频主要通过麦克风采集

音频跟视频采集的时候会带上时间戳，用来两者进行匹配对应，这是音视频同步的首要关键，这边采集源要是时间戳就不对应，后面的怎么处理都不会同步

视频处理

美颜

都说「80% 的主播没有美颜根本没法看」，美颜是直播产品中最常见的功能之一。美颜的主要原理是通过「磨皮+美白」来达到整体美颜的效果。磨皮的技术术语是「去噪」，也即对图像中的噪点进行去除或者模糊化处理，常见的去噪算法有均值模糊、高斯模糊和中值滤波等。当然， 由于脸部的每个部位不尽相同，脸上的雀斑可能呈现出眼睛黑点的样子，对整张图像进行「去噪」处理的时候不需要将眼睛也去掉，因此这个环节中也涉及到人脸和皮肤检测技术。一般使用大厂的api，不然就得自己研究相关的视频图像算法，这也是一个很大的技术门槛。

视频水印

视频水印包括播放器水印和视频内嵌水印两种方式可供选择，对于播放器水印来说，如果没有有效的防盗措施，对于没有播放鉴权的推流，客户端拿到直播流之后可以在任何一个不带水印的播放器里面播放，因此也就失去了视频保护的能力。综合考虑云端录制对于水印的需求，一般来说会选择「视频内嵌水印」的方式打水印。

滤镜

为了实现丰富的滤镜效果，在 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。

视频编码

原始视频数据存储空间大：一个 1080P 的 7 s 视频需要 817 MB；
原始视频数据传输占用带宽大：10 Mbps 的带宽传输上述 7 s 视频需要 11 分钟。
而经过 H.264 编码压缩之后，视频大小只有 708 k 、10 Mbps 的带宽仅仅需要 500 ms ，可以满足实时传输的需求，所以从视频采集传感器采集来的原始视频势必要经过视频编码

基本原理

那为什么巨大的原始视频可以编码成很小的视频呢？这其中的技术是什么呢？

核心思想就是去除冗余信息：

空间冗余：图像相邻像素之间有较强的相关性；
时间冗余：视频序列的相邻图像之间内容相似；
编码冗余：不同像素值出现的概率不同；
视觉冗余：人的视觉系统对某些细节不敏感；
知识冗余：规律性的结构可由先验知识和背景知识得到。

• 视频本质上讲是一系列图片连续快速的播放，最简单的压缩方式就是对每一帧图片进行压缩
• 但是帧和帧之间因为时间的相关性，后续开发出了一些比较高级的编码器可以采用帧间编码，简单点说就是通过搜索算法选定了帧上的某些区域，然后通过计算当前帧和前后参考帧的向量差进行编码的一种形式

使用编码器

简单看一个编码的结构吧

flv视频编码结构

封装

封装可以理解为采用哪种货车去运输，也就是媒体的容器。
所谓容器，就是把编码器生成的多媒体内容（视频，音频，字幕，章节信息等）混合封装在一起的标准。容器使得不同多媒体内容同步播放变得很简单，而容器的另一个作用就是为多媒体内容提供索引，也就是说如果没有容器存在的话一部影片你只能从一开始看到最后，不能拖动进度条（当然这种情况下有的播放器会话比较长的时间临时创建索引），而且如果你不自己去手动另外载入音频就没有声音。

推流协议

RTMP（主流协议）

RTMP是Real Time Messaging Protocol（实时消息传输协议）的缩写，是Adobe公司为Flash/AIR平台和服务器之间音、视频及数据传输开发的实时消息传送协议。RTMP协议基于TCP，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP协议中，视频必须是H264编码，音频必须是AAC或MP3编码，且多以flv格式封包。RTMP是目前最主流的流媒体传输协议，对CDN支持良好，实现难度较低，是大多数的直播平台的选择。不过RTMP有着一个最大的不足——不支持浏览器，且Adobe已不再更新。因此直播服务要支持浏览器的话，需要另外的推送协议支持。

HLS

Http Live Streaming是由Apple公司定义的基于HTTP的流媒体实时传输协议。它的原理是将整个流分为多个小的文件来下载，每次只下载若干个。服务器端会将最新的直播数据生成新的小文件，客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。基本上，HLS是以点播的技术实现了直播的体验。因为每个小文件的时长很短，客户端可以很快地切换码率，以适应不同带宽条件下的播放。分段推送的技术特点，决定了HLS的延迟一般会高于普通的流媒体直播协议。传输内容包括两部分：一是M3U8描述文件，二是TS媒体文件。TS媒体文件中的视频必须是H264编码，音频必须是AAC或MP3编码。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，不过HLS的

推流拉流示意图

传输

我们推送出去的流媒体需要传输到观众，整个链路就是传输网络，类比货运物流就是从出发地到目的地见的所有路程了，如果道路的容量不够，会引发堵车也就是网络拥塞，这时我们会改变路程也就是所谓的智能调度，但是传输网络会站在全局的角度进行调度，所以会比原子世界的调度有更好的效果，可以想象有一个上帝在天空中俯视出发地和目的地间的所有的路况信息，而且还是实时的，然后给出你一条明路，何等的神奇。

相比于传统网络，直播的传输有几个要求
对 Cache 的要求没有以前那么高；
对实时性的要求非常高；
对节点运维的要求高，要更智能，尽量减少人工干预；
对扩容这种运维事件响应度要求非常高。

CDN

互联网起源于美国军方的一个内部网络，Tim Berners-Lee 是互联网发明者之一，他很早就预见到在不久的将来网络拥塞将成为互联网发展的最大障碍，于是他提出了一个学术难题，要发明一种全新的、从根本上解决问题的方法来实现互联网内容的无拥塞分发，这项学术难题最终催生出一种革新性的互联网服务——CDN

传统树状网络拓扑结构

上图是一个典型的 CDN 系统的三级部署示意图，节点是 CDN 系统中的最基本部署单元，分为三级部署，中心节点、区域节点和边缘节点，最上面一级是中心节点，中间一级是区域节点，边缘节点地理位置分散，为用户提供就近的内容访问服务。

用户在某一区域内，则 GSLB （通常在边缘节点这一层是 Smart DNS）会把用户路由到该区域内的某个边缘节点，上一层又会路由到某个区域节点（这里的 GSLB 通常是内部的负载均衡器），最后又回溯到中心节点，中心节点会链接源站。

我们看看树状网络拓扑，用户的链路选择数量是有限的，如上图，用户在某一个区域内可选择的链路数是：2 * 5 = 10
这里的假设是：

用户能访问的最快节点一定是该区域内的边缘节点，如果该区域没有边缘节点则最快的一定是逻辑相邻的区域内的边缘节点。

边缘节点能访问的最快节点一定是该区域内的区域节点，一定不会是其他区域的节点。

区域节点到中心节点一定是最快的，这个链路的速度和带宽都是最优的。

但实际真的如此么？引入了如此多的假设真的正确么？

实际上就算理论上我们可以证明以上假设有效，但是节点规划和区域配置大都依赖于人的设计和规划，我们知道人多是不靠谱的，而且就算当时区域规划正确，谁能保证这些静态的网络规划不会因为铺设了一条光纤或者因为某些 IDC 压力过大而发生了改变呢？所以我们可以跳出树状网络拓扑结构的桎梏，探索新的适合直播加速的网络拓扑结构。
随着 Live 时代的到来，直播成为当前 CDN 厂商的又一个主要的战场，那么 Live 时代 CDN 需要支持什么样的服务呢？

流媒体协议的支持，包括 RTMP，HLS ，HTTP-FLV 等。

首屏秒开，从用户点击到播放控制在秒级以内

1~3 延迟控制，从推流端到播放端，延迟控制在 1~3 秒之间

全球全网智能路由，可以利用整个 CDN 网络内的所有节点为某一单一用户服务，不受地域限制。随着全球一体化进程不断推进，跨区域、跨国家、跨洲的直播正变为常态，很可能主播在欧美，而用户在亚洲。

天级别的节点按需增加，中国公司出海已成大势，CDN 需要更多的海外节点，如今比拼的更多的是海外节点可以快速部署，从提出节点增加需求到节点入网提供服务，需要达到一天之内，对 CDN 运维和规划提出非常高的要求。原有的月级别规划和入网满足不了先进的要求。

为了摆脱有限的链路路由线路限制，激活整理网络的能力，我们可以把上述的节点变成网状网络拓扑结构：

网状网络拓扑结构

我们看到一旦我们把网络结构改成了网状结构，则用户的可选择链路变为：无向图的指定两点间的所有路径，学过图论的同学都知道，数量惊人。

系统可以通过智能路由选择任何一个最快的链路而不用依赖于系统部署时过时的人工规划，无论是某些链路间增加了光纤或者某个 IDC 压力过大都可以实时的反映到整理网络中，帮助用户实时推倒出最优链路。这时我们可以去掉前面的一些假设，通过机器而不是人类来时实时规划网络的链路路由，这种实时大规模的计算任务天生就不是人类的强项，我们应该交给更适合的物种。
推流一般依赖cdn厂商，一般企业没有实力到处假设服务器机房，也就没有上面所说的边缘节点，所以以上这些都只能依赖专业搞cdn开发的厂家

解码

解封装

demuxing（分离）：从视频流、音频流，字幕流合成的文件(容器格式（FLV，TS）)中， 分解出视频、音频或字幕，各自进行解码。

音频编码框架

fdk_aac：音频编码解码框架，PCM音频数据和AAC音频数据互转

解码介绍

硬解码：用GPU来解码，减少CPU运算　优点：播放流畅、低功耗，解码速度快，　 缺点：兼容不好

软解码：用CPU来解码优点：兼容好　　 缺点：加大CPU负担，耗电增加、没有硬解码流畅，解码速度相对慢

播放

ijkplayer：一个基于FFmpeg的开源Android/iOS视频播放器API易于集成；
编译配置可裁剪，方便控制安装包大小；
支持硬件加速解码，更加省电
简单易用，指定拉流URL，自动解码播放.

直播答题

最后说一下直播答题，他跟直播有点不同的是首先直播，然后答题
有一个很大的特点 高并发

• 海量并发派题
• 海量并发收题
• 视频和答题同步

高并发答题和收题

业务流程
主持人发出派题指令；
题目信息通过实时通信网络和实时分发网络送达给用户；
VIP 用户从实时通信网络拉取题目信息；
普通用户从实时分发网络拉取题目信息；
如题目信息包含完整内容，则下一步，如果只有题目 ID，则到业务服务器查询题目内容；
用户把题目答案提交给答题统计分析服务器，同时得到标准答案反馈；答题统计分析服务器是分布式的集群，统计答题结果，反馈给主持人。

• 实时通信网络：
  为实时传输而设计的网络，能实时传输海量数据，不只是语音视频。它比实时分发网络（比如 CDN）的延迟更低，具有动态回源和对抗弱网等特点；
• 实时分发网络：
  为实时分发海量内容而设计的网络，优点是能支撑海量并发，成本相对也比较低，缺点是延迟相对于实时通信网络要高一些；
• 答题统计服务：
  为统计用户提交的题目答案而在视频直播架构外设计的服务，能反馈标准答案，并且统计所有题目答案，最后反馈给主持人。该服务要能承受海量并发压力；
• 业务服务器：
  如果派题信息包含完整题目内容，用户不需要再查询题目内容；如果派题信息只有题目 ID, 那么用户要到业务服务器查询题目内容。该服务也要承受海量并发压力。

海量并发派题

派题的指令必须是主持人端发出，然后服务器会担负起启动向海量用户群发题目的任务。 题目是优先级最高的消息，不能像处理 IM 消息那样采取低优先级消息抛弃，或者用户分桶等应对海量并发的策略，必须要确保消息内容实时到达每个用户的终端，这是实打实的实时海量并发。
那么海量并发派题要依仗内容分发网络的能力。内容分发可以通过实时低延迟网络或者 CDN 来完成，考虑到 CDN 有成本的优势，因此 VIP 用户的派题由实时网络完成，其它用户的派题要由 CDN 来完成。

海量并发收题

收题的环节由用户触发，每个用户答题的时间窗口不尽相同，因此每个用户提交题目的时间有秒级的差别。

然而，海量用户在数秒之内提交答案，题目答案属于重要消息，不能做抛弃处理，服务器的压力也是巨大的。

为了减少服务器压力，用户的答题将会被就近提交到边缘节点并且获得正确答案反馈，整体的答题统计结果将会由分布式的服务器集群来完成，最后传达到主持人端，使得主持人可以近乎实时地宣布统计的结果。

视频和题目同步

视频直播要低延迟，题目派送同样也要低延迟，而且要和视频画面同步。 通过 IM 的能力来派题是很难做到视频和派题同步的，因为语音视频传输通道和 IM 的通道是相互独立的。一般的做法是通过实时语音视频的扩展数据通道来附带传输题目信息，让视频和题目天然就同步。

题目内容安全性

直播答题悬赏巨额奖金，各种黑产活跃到其中，题目内容的安全性十分重要。题目内容缓存在用户终端是万万不可的，必须实时地送达用户终端，否则黑产从用户终端可以提前获得题目内容。

针对题目派送的方式，目前市面上有两种第三方直播答题方案：

第一种方案，技术方案通过实时语音视频通道派送题目的全部内容，该方案的优势是完全负责了派题的安全性和并发压力，开发者不需要投入开发成本；
第二种方案，技术方案通过实时语音视频通道只派送题目 ID，用户终端获得题目 ID 后，到开发者的业务服务器查询题目内容。该方案的优势是开发者完全把控题目内容的私密性。

以即构 ZEGO 的直播答题方案为例：

如果题目内容小于 1000 字节，也就是 500 个中文字符，可以通过实时语音视频通道传输所有题目内容；
如果超过 1000 字节，通过实时语音视频信道传输题目 ID, 然后由用户终端以题目 ID 从就近服务器拉取题目内容。

如果第三方直播答题方案只派送题目 ID，开发者可以把题目内容缓存在就近服务器，通过题目 ID 获取题目内容，增加的延迟很小，不会影响用户体验。然而，开发者要承担查询题目的海量并发压力，还要实现题目内容的安全保护机制，比如说拉取题目要鉴权，题目传输要加密，和题目时效窗口的控制等，开发成本也就水涨船高。

移动端实现技术与三方方案

主播拍视频和美颜滤镜

视频采集

• 七牛提供的sdkhttps://github.com/pili-engineering/ipcam_sdk
• 屏幕录制
  开源的桌面推流工具 OBS https://obsproject.com/
• 美颜 和 滤镜
  GPUImage
  https://blog.csdn.net/Ch97CKd/article/details/79168469
  google 开源的框架 https://github.com/google/grafika。

封装和协议推流

编码 FFMpeg+x264/openh264
协议推流也有三方云平台处理

云平台鉴权 鉴黄加密

三方云平台处理

客户端拉流 解码 播放

• FFmpeg解码播放
• MediaCodec解码播放
• ios AVFoundation
• ijkplayer

直播答题类先不搞了

给钱就搞的大厂

目前第三方付费支持直播的解决方案有（没错你猜对了，就是那几家，什么东西都想搞，因为没给广告费，所以不给全称）

阿*云

官方图

计费方式

计费方式

腾*云
--->直播LVB
价格

• 基础计费
• 其他计费
• 增值计费
  录制
  截图
  鉴黄

• 百*云

  
  
  官网示意图

计费方式

计费方式

阿里跟腾讯的收费方式差不多 百度按流量收费，前两者多了增值服务收费