iOS直播实战篇——主要概念（一）iOS直播实战篇——主要概念（一）前面的零百家号直播可谓风生水起, 热火朝天, 借此也对音视频进行一次深入学习, 希望有需要的大家一块学习.第一步对直播的大概流程概括如下:1.直播人设备端:从摄像头获取视频流,然后使用rtmp服务提交到服务器2.服务器端:接收直播人提交的rtmp视频流,并为观看者提供rtmp源3.观看者:用播放器播放rtmp源的视频.技术流程图如下:第一: 音视频传输的常见协议1.1 RTMP协议Real Time Messaging Protocol 是Adobe公司为Flash播放器和服务器之间音、视频及数据传输开发的实时消息传送协议。协议中，视频必须是H264编码，音频必须是AAC或MP3编码，且多以flv格式封包。1.2 HLS协议Http Live Streaming 是由Apple公司定义的基于HTTP的流媒体实时传输协议。它的原理是将整个流分为一个一个小的文件来下载，每次只下载若干个。传输内容包括两部分：一是M3U8描述文件，二是TS媒体文件。TS媒体文件中的视频必须是H264编码,音频必须是AAC或MP3编码。第二: 客户端需要操作的步骤1. 音视频的采集；2. 对视频进行H264编码，对音频进行AAC编码；3. 对编码后的音、视频数据进行FLV封包；4. 建立RTMP连接并上推到服务端。第三: 实现方式---第三方(一)很多第三方都提供SDK，七牛云、金山云、乐视云、腾讯云、百度云、斗鱼直播伴侣推流端等等，功能几乎都是一样的，不同的是整个直播平台服务差异和接入的简易性。后端现在 RTMP/HTTP-FLV 清一色，App挂个源站直接接入云厂商或CDN就OK。摘录自JIAAIR.建议了解一下其中的原理再使用第三方, 所谓: 知其然知其所以然 +_-第四: 实现方式---知其然知其所以然(二)4.1 软编软解与硬编解码的概念1. 软编软解: 利用CPU做视频的编码和解码; 占用CPU资源，编解码效率不高;2. 硬编解码: 利用GPU或者专用处理器来对视频流进行编解码，也就是硬件编码和解码.在iOS 8.0后，苹果将该Video ToolBox(之前在Mac系统中使用)框架引入iOS系统。4.2 视频编码的两种方案1. 利用第三方库FFmpeg 进行编码，FFmpeg因其跨平台及功能丰富等诸多优势，被广泛使用。---软编软解;2. 利用iOS自身的 AVAssetWriter 或VideoToolBox.framework 的VTCompressionSession进行编码。 ---硬编解码2.1 使用AVAssetWriter编码需要将视频写入本地文件，然后通过实时监听文件内容的改变，读取文件并处理封包。2.2 从iOS8开始，VideoToolBox提供了硬件编码支持，可以使用VTCompressionSession进行编码。4.3 音频AAC是神马?AAC（Advanced Audio Coding），中文名：高级音频编码，出现于1997年，基于MPEG-2的音频编码技术。由Fraunhofer IIS、杜比实验室、AT&T、Sony等公司共同开发，目的是取代MP3格式。2000年，MPEG-4标准出现后，AAC重新集成了其特性，加入了SBR技术和PS技术，为了区别于传统的MPEG-2 AAC又称为MPEG-4 AAC。4.4 视频编码H264总的来说 H264结构H264的码流由NALU单元组成;NALU单元包含视频图像数据和H264的参数信息;视频图像数据就是CMBlockBH264的参数信息包含SPS（Sequence Parameter Set）和PPS（Picture Parameter Set）.H264码流的结构如下图:更详细内容(NALU数据格式)详见---RTMP中FLV流到标准h264、aac的转换4.5 编码解码的总的流程从iOS8开始开发者可以调用Video Toolbox框架提供的接口，来对视频进行硬件编解码的工作，为VOIP视频通话，视频流播放等应用的视频编解码。Video Toolbox结构1. CVPixelBuffer：编码前和解码后的图像数据结构;2. CMTime、CMClock和CMTimebase：时间戳相关。时间以64-bit/32-bit的形式出现;3. CMBlockBuffer：编码后，结果图像的数据结构;4. CMVideoFormatDescription：图像存储方式，编解码器等格式描述;5. CMSampleBuffer：存放编解码前后的视频图像的容器数据结构。编码解码的总的流程如图所示1. 编解码前后的视频图像均封装在CMSampleBuffer中;2. 编码后的图像，以 CMBlockBuffer 方式存储；3. 解码后的图像，以 CVPixelBuffer 方式存储。4. CMSampleBuffer里面还有另外的 时间信息CMTime 和 视频描述信息CMVideoFormatDesc 。第五: FLV文件5.1 FLV是什么?flv是一种视频格式.FLV是一个二进制文件，简单来说，其是由一个文件头（FLV header）和很多tag组成（FLV body）。tag又可以分成三类:audio,video,script，分别代表音频流，视频流，脚本流，而每个tag又由tag header和tag data组成。注:封包的时候要特别注意一下包头里面的时间戳，因为这个控制着播放的速度，如果不填，全是0的话，播放会相当快，一般按视频帧率来设置。我这个h264流是8帧的，所以我每个tag的时间间隔是125ms左右。更多精彩内容请关注“IT实战联盟”哦~~~~本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。前面的零百家号最近更新：简介:引领科技潮流，让生活更精彩作者最新文章相关文章[发明专利]一种在直播中实现双屏推流的方法及系统在审
申请/专利权人：
公开/公告号：CNA
发明/设计人：;;
公开/公告日：
主分类号：
分类号：;;;;;
搜索关键词：
该专利技术资料仅供研究查看技术是否侵权等信息，商用须获得专利权人授权。该专利全部权利属于武汉斗鱼网络科技有限公司，未经武汉斗鱼网络科技有限公司许可，擅自商用是侵权行为。如果您想购买此专利、获得商业授权和技术合作，请联系【】
【说明书】：
技术领域本发明涉及直播应用技术领域，具体来讲是一种在直播中实现双屏推流的方法及系统。背景技术在线视频直播是指利用互联网网络资源进行的现场视频直播服务，通过现场的视频拍摄同步发布到网络上，用户可以同一时间在网络上看到实时的现场情况。随着直播行业的快速发展，直播内容也越来越丰富。随着直播内容质量越来越高，如何在现有直播环节中，增加其它植入内容也越来越紧急。目前，大多数直播的传播方式比较单一，简单通过视频截取的软件(即直播软件)对直播的内容进行推流(推流是指将已经封包的视频信息传输至用户的播放页面)。但是，实际使用中，现有的直播传播方式已经不能满足用户的需求了；同时，主播也希望可以通过其它方式进行更多信息的推送，以丰富主播的直播内容，更好的为主播吸引更多的粉丝和用户的关注。因此，如何设计出一种新的推流方式，以丰富主播的直播内容，更好的为主播吸引更多用户，是直播领域亟待解决的问题。发明内容本发明的目的是为了克服上述背景技术的不足，提供一种在直播中实现双屏推流的方法及系统，能通过双屏推流的新方式为用户提供更多的直播内容，不但能为主播更好的吸引粉丝，而且能让用户更好、更全面的接收到主播的信息，用户体验佳。为达到以上目的，本发明提供一种在直播中实现双屏推流的方法，该方法包括以下步骤：S1、当主播登录直播平台进入直播间时，启动直播软件与直播平台连接；S2、根据主播选择的需要推流的指定码率，为推流接口添加相应的推流码率的标识；S3、获取当前直播信息；S4、根据主播在直播软件中设置的双屏推流设置，判断主播是否开启双屏推流功能，若是，转入步骤S5；否则，结束操作；S5、当主播进行双屏输入端口的选择时，实时获取主播所选择的双屏输入的端口；S6、根据主播所选择的双屏输入的端口，启用对应的本地硬件接口；利用启用的硬件接口，按照添加的推流码率的标识将信息流推送给直播平台的信息流接收服务器，该信息流中包括有当前直播信息和其他需要推送的信息。在上述技术方案的基础上，步骤S1具体包括以下流程：S101、主播登录直播平台并进入直播间；S102、通过直播平台的后台服务器获取当前主播的登录信息，并将该登录信息保存在本地的Cookie中；S103、启动直播软件，利用直播软件读取本地的Cookie实现直播软件登录；在登录成功之后，通过内置的API连接直播平台的后台服务器。在上述技术方案的基础上，步骤S3具体包括以下流程：S301、利用直播软件获取当前推流接口所在的硬件平台标识；S302、利用直播软件获取当前推流接口所对应的操作系统信息；S303、根据获取的硬件平台标识和操作系统信息，调用对应的硬件平台的接口获取当前直播信息。在上述技术方案的基础上，步骤S5具体包括以下流程：S501、向主播弹出选择双屏输入端口的窗口；S502、通过监听事件，对弹出的窗口的选择项的点击值进行实时监听，获取主播所选择的双屏输入的端口。在上述技术方案的基础上，步骤S6之后还包括双屏推流功能的有效性检查操作：判断双屏推流是否失败，若是，返回步骤S6，重新进行双屏推流；若否，则由直播平台的信息流接收服务器将所述信息流推送至CDN服务器。本发明同时还提供一种在直播中实现双屏推流的系统，该系统包括登录连接模块、码率选择模块、直播信息获取模块、双屏推流功能判断模块、双屏输入端口选择模块和双屏推流处理模块；所述登录连接模块用于：当主播登录直播平台进入直播间时，启动直播软件与直播平台连接；向码率选择模块发送码率选择信号；所述码率选择模块用于：收到码率选择信号后，根据主播选择的需要推流的指定码率，为推流接口添加相应的推流码率的标识；并向直播信息获取模块发送信息获取信号；所述直播信息获取模块用于：收到信息获取信号后，获取当前直播信息；并向双屏推流功能判断模块发送功能判断信号；所述双屏推流功能判断模块用于：收到功能判断信号后，根据主播在直播软件中设置的双屏推流设置，判断主播是否开启双屏推流功能，若是，向双屏输入端口选择模块发送端口选择信号；否则，结束操作；所述双屏输入端口选择模块用于：收到端口选择信号后，当主播进行双屏输入端口的选择时，实时获取主播所选择的双屏输入的端口；并向双屏推流处理模块发送推流处理信号；所述双屏推流处理模块用于：收到推流处理信号后，根据主播所选择的双屏输入的端口，启用对应的本地硬件接口；利用启用的硬件接口，按照添加的推流码率的标识将信息流推送给直播平台的信息流接收服务器，该信息流中包括有当前直播信息和其他需要推送的信息。在上述技术方案的基础上，所述登录连接模块进行登录和连接操作的具体流程为：当主播登录直播平台并进入直播间时，通过直播平台的后台服务器获取当前主播的登录信息，并将该登录信息保存在本地的Cookie中；启动直播软件，利用直播软件读取本地的Cookie实现直播软件登录；在登录成功之后，通过内置的API连接直播平台的后台服务器。在上述技术方案的基础上，所述直播信息获取模块获取当前直播信息的具体流程为：利用直播软件获取当前推流接口所在的硬件平台标识；利用直播软件获取当前推流接口所对应的操作系统信息；根据获取的硬件平台标识和操作系统信息，调用对应的硬件平台的接口获取当前直播信息。在上述技术方案的基础上，所述双屏输入端口选择模块实时获取主播所选择的双屏输入的端口的具体流程为：向主播弹出选择双屏输入端口的窗口；通过监听事件，对弹出的窗口的选择项的点击值进行实时监听，获取主播所选择的双屏输入的端口。在上述技术方案的基础上，该系统还包括双屏推流功能检查模块，该双屏推流功能检查模块用于对双屏推流功能的有效性进行检查：判断双屏推流是否失败，若是，向双屏推流处理模块发送推流处理信号，重新进行双屏推流；若否，则由直播平台的信息流接收服务器将所述信息流推送至CDN服务器。本发明的有益效果在于：(1)本发明采用双屏推流的方式，在主播推送直播主内容的同时，也可以通过另外一个信息输入端(另外一个屏)，将其它需要推送的辅助信息录入进来。与现有技术的单一传播方式相比，本发明通过双屏推流的方式可将直播内容或者主播动态及时的向用户进行展示，为用户提供更多的直播信息，丰富主播直播内容。对主播来说，可有效增强粉丝的粘性，更好的为主播吸引更多的粉丝和用户的关注；对用户来说，可得到更好更多元化的直播内容，用户体验佳。(2)本发明中，设计有双屏推流功能的有效性检查操作，该操作能更好地执行双屏推流功能，确保双屏推流的有效性，有效提高了双屏推流的实现质量，可靠性强。附图说明图1为本发明实施例中在直播中实现双屏推流的方法的流程图；图2为本发明实施例中在直播中实现双屏推流的系统结构框图。具体实施方式本发明提供一种在直播中实现双屏推流的方法及系统。其中，所述的双屏是指：两个视频输入入口，通常情况是指一个直播信息入口，一个其他需要推送的信息入口。同时，双屏也包括音频的输入，使用户既可以看到直播的画面，也可以与主播进行面对面的交流和互动。下面结合附图及具体实施例对本发明作进一步的详细描述。参见图1所示，本发明实施例提供一种在直播中实现双屏推流的方法，该方法包括以下步骤：S1、当主播登录直播平台进入直播间时，并启动直播软件与直播平台连接，转入步骤S2。实际操作中，步骤S1具体可包括以下流程：S101、主播登录直播平台(如斗鱼直播平台)，并进入直播间。S102、通过直播平台的后台服务器获取当前主播的登录信息，并将该登录信息保存在本地的Cookie中。举例来说，获取当前主播的登录信息时，可使用以下代码实现：logoidlogid＝new WebUserServers.Client.Land()；另外，将该登录信息保存在本地的Cookie中时，可使用以下代码实现：Localservice.Cookie.Internet(logid,Password)。S103、启动直播软件(如直播伴侣或OBS)，利用直播软件读取本地的Cookie实现直播软件登录；在登录成功之后，通过内置的API(Application Programming Interface,应用程序编程接口)连接直播平台的后台服务器(如斗鱼直播平台的后台服务器)。举例来说，通过内置的API连接直播平台的后台服务器时，可使用以下代码实现：Partner Plog＝new WebDouYuServer.Foreign.Interface(logid)。
专利文献下载
1、专利原文基于中国国家知识产权局专利说明书；
2、支持发明专利 、实用新型专利、外观设计专利（升级中）；
3、专利数据每周两次同步更新，支持Adobe PDF格式；
4、内容包括专利技术的结构示意图、流程工艺图或技术构造图；
5、已全新升级为极速版,下载速度显著提升！欢迎使用！
该文献正飞奔而来，请耐心等候...20
友情链接：交换友情链接需要网站权重大于3，网站收录10W以上，如符合条件，请联系QQ：。
行业网站：相关推荐：
400-周一至周五 9:00-18:00
服务热线：400-投诉建议：022-
扫一扫，微信关注高智网
高智&让创新无法想象2000万件&专利数据直播 | 我爱互联网
作者：七牛云
链接：https://zhuanlan.zhihu.com/p/
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
关于直播的技术文章不少，成体系的不多。我们将用七篇文章，更系统化地介绍当下大热的视频直播各环节的关键技术，帮助视频直播创业者们更全面、深入地了解视频直播技术，更好地技术选型。
本篇是《视频直播技术详解》系列的最后一篇直播云 SDK 性能测试模型，SDK 的性能对最终 App 的影响非常大。SDK 版本迭代快速，每次发布前都要进行系统的测试，测试要有比较一致的行为，要有性能模型作为理论基础，对 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，，。在成像的两组数字中，前者为图片长度，后者为图片的宽度，两者相乘得出的是图片的像素。
影响 SDK 性能的指标
有了上述的前置知识，我们可以开始准备测试 SDK 的性能了，我们首先分析一下都有哪些指标可以反映 SDK 的性能，分成 Android 和 iOS 两个平台：
GC ：可以通过 GC 日志记录，Mirror GC 和 Full GC 的频次和时间，Full GC 会造成比较明显的卡顿，需要评估
UI Loop 就是 VSync Loop ：反映 SDK 对 App 流畅度的影响，理论上 60 fps 是最流畅的值。
Memory ：反映 SDK 占用内存的大小
CPU Usage ：反映 SDK 占用计算资源的大小
UI Loop ：反映 SDK 对 App 流畅度的影响，理论上 60 fps 是最流畅的值。
Memory ：反映 SDK 占用内存的大小
CPU Usage ：反映 SDK 占用计算资源的大小
除了上面的一些系统级别的指标外，下面是直播 SDK 中特有的一些指标，这些指标可以反映出 SDK 的核心竞争力和一些主要的差异，涉及到视频的清晰度和流畅度，也是可以量化的。
1)影响视频清晰度的指标
量化参数（压缩比）
2）影响视频流畅度的指标
3）其他重要指标
直播是流量和性能的消耗大户，有一些指标，直接影响了用户的感受，也是我们需要重点关注的：
发热（不好量化，大部分情况发热和耗电量正比，可以使用耗电量暂时替代）
测试过程需要先固化一些测试条件，然后根据不同的测试条件得出测试结果，这里选择了两个现在最常见的条件，是我们通过回访大量的客户得出的一些统计数字，可以反映大部分直播应用所处的场景。主要从分辨率、视频处理、码率和网络环境几个维度进行限制。
最后分为几个两种测试指标：客观和主观指标，前者反映了 SDK 对系统的消耗程度，但虽说是客观指标并不是说对用户没有影响、只是说得出的结果用户感受不明显。主观指标则会直接影响最终用户体验，但在传统的测试中反而容易被忽略，因为不好量化，这里拍砖引玉的提出一些量化的方式，希望引起读者的思考。
测试条件 A
分辨率 480p
无水印，无美颜
网络保证在 0.5 M ~ 2 M
这个条件，反映了大部分低速网络情况下的使用场景，也反映了 SDK 基本的性能情况，可以作为 SDK 基本推流和拉流情况下的基准测试，不引入太多的测试依赖。
测试条件 B
分辨率 720p
无水印，有美颜
网络保证在 0.5 M ~ 2 M
这个条件，反映了大部分客户的使用场景，具有较高的分辨率和美颜视频处理，可以作为 SDK 竞品分析的重要依据，测试结果非常接近真实场景。
1）客观指标测试计划
客观影响 App 稳定性和性能的指标：
测试 10 分钟，内存曲线
测试 1 小时，TP99，TP95，TP90，需要归档
测试 1 小时，内存增量，考察是否有内存泄露，需要归档
参考值：上次结果
测试 10 分钟，CPU Usage 曲线
测试 10 分钟，TP99，TP95，TP90，需要归档
参考值：上次结果
测试 10 分钟，TP99，TP95，TP90，重点说明，这里的码率控制需要分开来看，如果网络抖动造成码率降低，这样的点不计入进来，只测试 SDK 码率控制，需要归档
参考值：1 M（大小都是偏差）
测试一小时，记录进程总耗电量、屏幕显示耗电量、CPU 耗电量，需要归档
参考值：上次结果
2）主观指标测试计划
主观影响 App 使用者的指标：
UI Loop App 本身可以达到的最大帧率，不同于视频帧率，统计他的原因是我们的 SDK 可能会影响整个 App 的流畅度，需要跟踪
测试 10 分钟，UI Loop 曲线
测试 10 分钟，UI Loop TP99，TP95，TP90，需要归档反复比较
参考值：60 fps
Android GC
测试 1 小时，记录 Mirror GC 和 Full GC 的频次，记录 GC 时长的 TP99，TP95，TP90，需要归档反复比较
参考值：上次结果
帧率（fps）
测试 10 分钟，TP99，TP95，TP90，需要归档反复比较
参考值：30 fps
PSNR 比较视频清晰度的指标
测试 10 分钟，需要归档反复比较，这个指标可以使用固定视频作为输入。
参考值：上次结果
3）结果显示
表格显示具体指标
曲线显示原始数据和时间轴的数据
热图显示和参考值的偏差
热图显示距离上次归档值是改善了还是恶化了
通过这种反复迭代的自动化的、系统化的测试，我们以职人之心近乎偏执地反复打磨着 SDK 的性能，只为给最终用户带来最好的直播体验，帮助我们的客户通过次时代的媒体最大化自己的商业价值，我们希望在您披荆斩棘的路上我们始终相伴。
七牛云机构号将实时分享云计算领域的技术洞见以及行业讯息，为你的创新加速。
欢迎提问&求关注 ( ? ▽ ` )?
作者：七牛云
链接：https://zhuanlan.zhihu.com/p/
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
关于直播的技术文章不少，成体系的不多。我们将用七篇文章，更系统化地介绍当下大热的视频直播各环节的关键技术，帮助视频直播创业者们更全面、深入地了解视频直播技术，更好地技术选型。
本系列文章大纲如下：
（六）现代播放器原理
（七）SDK 性能测试模型
在上一篇延迟优化中，我们分享了不少简单实用的调优技巧。本篇是《视频直播技术详解》系列之六：现代播放器原理。
近年来，多平台适配需求的增长导致了流媒体自适应码率播放的兴起，这迫使 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 部分主要包含三大组件：
皮肤是对播放器视觉相关部分的统称：进度控制条、按钮和动画图标等等，如图 2 所示。和大部分设计类的组件一样，这部分组件也是使用 CSS 来实现的，设计师或者开发者可以很方便的拿来集成（即便你使用的是 JW Player 和 Bitdash 这种整套解决方案）。
图 2. 播放器皮肤
2. UI 逻辑
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 工作流程图
解码器处理最底层播放相关的逻辑。它将不同封装格式的视频进行解包，并将其内容解码，然后将解码后的视频帧交给操作系统进行渲染，最终让终端用户看到。
由于视频压缩算法变得越来越复杂，解码过程是一个需要密集计算的过程，并且为了保证解码性能和流畅的播放体验，解码过程需要强依赖于操作系统和硬件。现在的大部分解码都依赖于 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 来作为其底层多媒体处理引擎。我们也将持续投入更多的力量去支持这些标准。
本文由七牛云布道师何李石翻译自
七牛云机构号将实时分享云计算领域的技术洞见以及行业讯息，为你的创新加速。
欢迎提问&求关注 ( ? ▽ ` )?
作者：七牛云
链接：https://zhuanlan.zhihu.com/p/
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
关于直播的技术文章不少，成体系的不多。我们将用七篇文章，更系统化地介绍当下大热的视频直播各环节的关键技术，帮助视频直播创业者们更全面、深入地了解视频直播技术，更好地技术选型。
本系列文章大纲如下：
（五）延迟优化
（六）现代播放器原理
（七）SDK 性能测试模型
在上一篇推流和传输中，关于「直播的第一公里」的关键因素我们展开了详细的介绍。本篇是《解密视频直播技术》系列之五：延迟优化。
我们在很多线上和线下场合分享了如何优化直播体验，详细讲解了各部分造成低延迟和卡顿的原因和相应的优化原理。实际上，音视频的直播系统是一个复杂的工程系统，要做到非常低延迟的直播，需要复杂的系统工程优化和对各组件非常熟悉的掌握。这里面我们再分享几个简单而常用的调优技巧。
1. 确保 Codec 开启了最低延迟的设置。Codec 一般都会有低延迟优化的开关，对于 H.264 来说其效果尤其明显。很多人可能不知道 H.264 的解码器正常情况下会在显示之前缓存一定的视频帧，对于 QCIF 分辨率大小的视频（176 × 144）一般会缓存 16 帧，对于 720P 的视频则缓存 5 帧。对于第一帧的读取来说，这是一个很大的延迟。如果你的视频不是使用 H.264 来编码压缩的，确保没有使用到 B 帧，它对延迟也会有较大的影响，因为视频中 B 帧的解码依赖于前后的视频帧，会增加延迟。
2. 编码器一般都会有码控造成的延迟，一般也叫做初始化延迟或者视频缓存检验器 VBV 的缓存大小，把它当成编码器和解码器比特流之间的缓存，在不影响视频质量的情况下可以将其设置得尽可能小也可以降低延迟。
3. 如果是仅仅优化首开延迟，可以在视频帧间插入较多的关键帧，这样客户端收到视频流之后可以尽快解码。但如果需要优化传输过程中的累计延迟，尽可能少使用关键帧也就是 I 帧（GOP 变大），在保证同等视频质量的情况下，I 帧越多，码率越大，传输所需的网络带宽越多，也就意味着累计延迟可能越大。这个优化效果可能在秒级延迟的系统中不是很明显，但是在 100 ms 甚至更低延迟的系统中就会非常明显。同时，尽量使用 AAC-LC Codec 来编码音频，HE-AAC 或者 HE-AAC V2 虽然编码效率高，但是编码所需时间更长，而产生更大体积的音频造成的传输延迟对于视频流的传输来说影响更小。
4. 不要使用视频 MJPEG 的视频压缩格式，至少使用不带 B 帧的 MPEG4 视频压缩格式（Simple profile），甚至最好使用 H.264 baseline profile（X264 还有一个「-tune zerolatency」的优化开关）。这样一个简单的优化可以降低延迟，因为它能够以更低的码率编码全帧率视频。
5. 如果使用了 FFmpeg，降低「-probesize 」和「 -analyze duration」参数的值，这两个值用于视频帧信息监测和用于监测的时长，这两个值越大对编码延迟的影响越大，在直播场景下对于视频流来说 analyzeduration 参数甚至没有必要设定。
6. 固定码率编码 CBR 可以一定程度上消除网络抖动影响，如果能够使用可变码率编码 VBR 可以节省一些不必要的网络带宽，降低一定的延迟。因此建议尽量使用 VBR 进行编码。
传输协议优化
1. 在服务端节点和节点之间尽量使用 RTMP 而非基于 HTTP 的 HLS 协议进行传输，这样可以降低整体的传输延迟。这个主要针对终端用户使用 HLS 进行播放的情况。
2. 如果终端用户使用 RTMP 来播放，尽量在靠近推流端的收流节点进行转码，这样传输的视频流比原始视频流更小。
3. 如果有必要，可以使用定制的 UDP 协议来替换 TCP 协议，省去弱网环节下的丢包重传可以降低延迟。它的主要缺点在于，基于 UDP 协议进行定制的协议的视频流的传输和分发不够通用，CDN 厂商支持的是标准的传输协议。另一个缺点在于可能出现丢包导致的花屏或者模糊（缺少关键帧的解码参考），这就要求协议定制方在 UDP 基础之上做好丢包控制。
传输网络优化
1. 我们曾经介绍过，它是一种新型的节点自组织的网状传输网络，既适合国内多运营商网络条件下的传输优化，也适合众多海外直播的需求。
2. 在服务端节点中缓存当前 GOP，配合播放器端优化视频首开时间。
3. 服务端实时记录每个视频流流向每个环节时的秒级帧率和码率，实时监控码率和帧率的波动。
4. 客户端（推流和播放）通过查询服务端准实时获取当前最优节点（5 秒一次），准实时下线当前故障节点和线路。
推流、播放优化
1. 考察发送端系统自带的网络 buffer 大小，系统可能在发送数据之前缓存数据，这个参数的调优也需要找到一个平衡点。
2. 播放端缓存控制对于视频的首开延迟也有较大影响，如果仅优化首开延迟，可以在 0 缓存情况下在数据到达的时候立即解码。但如果在弱网环境下为了消除网络抖动造成的影响，设置一定的缓存也有必要，因此需要在直播的稳定性和首开延迟优化上找到平衡，调整优化缓冲区大小这个值。
3. 播放端动态 buffer 策略，这是上面播放端缓存控制的改进版本。如果只是做 0 缓存和固定大小的缓存之间进行选择找到平衡，最终还是会选择一个固定大小的缓存，这对亿级的移动互联网终端用户来说并不公平，他们不同的网络状况决定了这个固定大小的缓存并不完全合适。因此，我们可以考虑一种「动态 buffer 策略」，在播放器开启的时候采用非常小甚至 0 缓存的策略，通过对下载首片视频的耗时来决定下一个时间片的缓存大小，同时在播放过程中实时监测当前网络，实时调整播放过程中缓存的大小。这样即可做到极低的首开时间，又可能够尽量消除网络抖动造成的影响。
4. 动态码率播放策略。除了动态调整 buffer 大小的策略之外，也可以利用实时监测的网络信息来动态调整播放过程中的码率，在网络带宽不足的情况下降低码率进行播放，减少延迟。
以上，是我们在低延迟优化方面的部分技巧。实际上我们优化低延迟的时候并不是只关注「低延迟」，而是在保证其它条件不影响用户体验的情况下尽量做到低延迟，因此它的内容涉及到更多广泛的话题。而视频直播的优化也包含方方面面，这里只分享了其中经过我们实践的部分。随着实践的积累，我们接下来会在线上和线下分享更多关于视频直播甚至点播的优化技巧。
作者：七牛云
链接：https://zhuanlan.zhihu.com/p/
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
关于直播的技术文章不少，成体系的不多。我们将用七篇文章，更系统化地介绍当下大热的视频直播各环节的关键技术，帮助视频直播创业者们更全面、深入地了解视频直播技术，更好地技术选型。
在上一期中，我们介绍了讲解。 本篇是《解密视频直播技术》系列之四：推流和传输。推流是直播的第一公里，直播的推流对这个直播链路影响非常大，如果推流的网络不稳定，无论我们如何做优化，观众的体验都会很糟糕。所以也是我们排查问题的第一步，如何系统地解决这类问题需要我们对相关理论有基础的认识。
本系列文章大纲如下：
（四）推流和传输
（五）延迟优化
（六）现代播放器原理
（七）SDK 性能测试模型
下面就先介绍一下都有哪些推送协议，他们在直播领域的现状和优缺点。
基于 UDP 的私有协议
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，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。它于 2011 年 6 月 1 日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。
目前主要应用于视频会议和连麦中，协议分层如下：
W3C 标准，主流浏览器支持程度高
Google 在背后支撑，并在各平台有参考实现
底层基于 SRTP 和 UDP，弱网情况优化空间大
可以实现点对点通信，通信双方延时低
ICE,STUN,TURN 传统 CDN 没有类似的服务提供
3. 基于 UDP 的私有协议
有些直播应用会使用 UDP 做为底层协议开发自己的私有协议，因为 UDP 在弱网环境下的优势通过一些定制化的调优可以达到比较好的弱网优化效果，但同样因为是私有协议也势必有现实问题：
更多空间进行定制化优化
开发成本高
CDN 不友好，需要自建 CDN 或者和 CDN 达成协议
独立作战，无法和社区一起演进
我们推送出去的流媒体需要传输到观众，整个链路就是传输网络，类比货运物流就是从出发地到目的地见的所有路程了，如果道路的容量不够，会引发堵车也就是网络拥塞，这时我们会改变路程也就是所谓的智能调度，但是传输网络会站在全局的角度进行调度，所以会比原子世界的调度有更好的效果，可以想象有一个上帝在天空中俯视出发地和目的地间的所有的路况信息，而且还是实时的，然后给出你一条明路，何等的神奇，但这些我们在 LiveNet 中都已经实现了。
这里先回顾一下传统的内容分发网络。
1. 为什么要有内容分发网络，内容分发网络的由来
互联网起源于美国军方的一个内部网络，Tim Berners-Lee 是互联网发明者之一，他很早就预见到在不久的将来网络拥塞将成为互联网发展的最大障碍，于是他提出了一个学术难题，要发明一种全新的、从根本上解决问题的方法来实现互联网内容的无拥塞分发，这项学术难题最终催生出一种革新性的互联网服务——CDN 。当时 Berners-Lee 博士隔壁是 Tom Leighton 教授的办公室，一位麻省理工学院应用数学教授，他被 Berners-Lee 的挑战激起了兴趣。Letghton 最终解决了这个难题并开始自己的商业计划，成立了 Akamai 公司，成为世界上第一家 CDN 公司。
2. 传统 CDN 的架构
上图是一个典型的 CDN 系统的三级部署示意图，节点是 CDN 系统中的最基本部署单元，分为三级部署，中心节点、区域节点和边缘节点，最上面一级是中心节点，中间一级是区域节点，边缘节点地理位置分散，为用户提供就近的内容访问服务。
下面介绍一下 CDN 节点的分类，主要分成两大类，骨干节点和 POP 节点，骨干节点又分为中心节点和区域节点。
骨干节点：中心节点，区域节点
POP节点：边缘节点
逻辑上来讲，骨干节点主要负责内容分发和边缘节点未命中时进行回源，POP 节点主要负责提供给用户就近的内容访问服务。但如果 CDN 网络规模较大，边缘节点直接向中心节点回源会给中间层的核心设备造成的压力过大，在物理上引入区域节点，负责一个地理区域的管理，保存部分热点数据。
3. 直播传输网络有别于传统 CDN 的痛点
随着 Live 时代的到来，直播成为当前 CDN 厂商的又一个主要的战场，那么 Live 时代 CDN 需要支持什么样的服务呢？
流媒体协议的支持，包括 RTMP，HLS ，HTTP-FLV 等。
首屏秒开，从用户点击到播放控制在秒级以内
1~3 延迟控制，从推流端到播放端，延迟控制在 1~3 秒之间
全球全网智能路由，可以利用整个 CDN 网络内的所有节点为某一单一用户服务，不受地域限制。随着全球一体化进程不断推进，跨区域、跨国家、跨洲的直播正变为常态，很可能主播在欧美，而用户在亚洲。
天级别的节点按需增加，中国公司出海已成大势，CDN 需要更多的海外节点，如今比拼的更多的是海外节点可以快速部署，从提出节点增加需求到节点入网提供服务，需要达到一天之内，对 CDN 运维和规划提出非常高的要求。原有的月级别规划和入网满足不了先进的要求。
4. 传统 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 压力过大都可以实时的反映到整理网络中，帮助用户实时推倒出最优链路。这时我们可以去掉前面的一些假设，通过机器而不是人类来时实时规划网络的链路路由，这种实时大规模的计算任务天生就不是人类的强项，我们应该交给更适合的物种。
5. CDN 的扩容
前面提到中国公司的出海已成大势，CDN 海外节点的需求越来越大，遇到这种情况需要 CDN 厂商在新的区域部署新的骨干网和边缘节点，需要做详细的网络规划。时代发生变化，原来 CDN 用户都是企业级用户，本身业务线的迭代周期较长，有较长时间的规划，留给 CDN 厂商的时间也比较多。而互联网公司讲究的是速度，双周迭代已成常态，这里面涉及到成本和响应速度的矛盾，如果提前部署节点可以更好的为这些互联网公司服务，但是有较高的成本压力，反之则无法响应这些快速发展的互联网公司。
理想情况是，用户提出需求，CDN 厂商内部评估，当天给出反馈，当天部署，客户当天就可以测试新区域的新节点。怎么解决？
答案是基于网状拓扑结构的对等网络，在网状拓扑结构中每个节点都是 Peer ，逻辑上每个节点提供的服务对等，不需要按区域设计复杂的网络拓扑结构，节点上线后不需要复杂的开局过程，直接上线注册节点信息，就可以对用户提供服务了,结合虚拟化技术前后时间理论上可以控制在一天之内。
6. 回归本质：LiveNet
我们知道最早的互联网就是网状拓扑结构，后来才慢慢加入了骨干网来解决各种各样的问题，我们是时候该回归本质，拥抱下一代 Live 分发网络：LiveNet 。总结前面的讨论，我们发现 Live 时代我们需要的内容分发网络是：
对 Cache 的要求没有以前那么高
对实时性的要求非常高
对节点运维的要求高，要更智能，尽量减少人工干预
对扩容这种运维事件响应度要求非常高
要做到如上几点，我们需要：
去中心化，网状拓扑
全球全网调度
节点无状态，节点对等
以上这些就是 LiveNet 设计时候的斟酌，让运维更自动化，系统运行高度自治，依赖机器计算而不是人工判断，下面分别介绍一下。
1）去中心，网状拓扑
网状拓扑结构是设计的根本和基础，只有看清了我们对 Cache 需求的降低，网状拓扑结构才更有优势。
2）全球全网调度
基于全球一张网，不在受限于区域网络调度，将调度的范围从区域网络扩展到全球，全网内的节点都可以响应用户的请求，参与链路路由，不再先由人工假设选定一部分节点进行路由，去掉人工干预，让整个系统更智能。
3）节点无状态，节点对等
LiveNet 节点无状态和节点对等都方便了运维，去掉了区域概念后的全球一张网让整个拓扑结构变的异常复杂，如果各个节点间有先后依赖关系，势必让运维成为噩梦，需要专有的服务编排系统，同时也给扩容带来困难，需要运维人员设计复杂的扩容方案，需要预演多次才敢在复杂的网络拓扑中扩容。当时如果节点本身对等且无状态，则运维和扩容都变的容易很多。
但整个系统在运行过程中还是会一些状态和数据需要保持，比如某些 Live 内容需要落地回放的需求，这些通过久经考验的七牛云存储来存储。
4）智能运维
智能运维建立在以上的「网状拓扑结构的对等网络」的基础上会变的容易的多。可以方便的下线有问题的节点而不影响整个 LiveNet 网络，可以方便快速的上线新节点，提升系统容量。通过节点的数据分析可以更好的了解整个网络的整体状态。
下面列举部分 LiveNet 采用的智能运维方案，让内容分发网络再次升级，以符合 Live 时代的要求。
监控节点健康状况，实时下线有问题的节点
Failover 机制，保证服务一直可用
7.LiveNet VS P2P
最后我们和 P2P 网络做一个对比：
我们发现 P2P 方案，节点的可控性和链路的稳定性上还有很大提升空间，比较适合在实时性要求不高的场景使用、适合长尾需求，在 Live 的场景下面多是对实时性要求比较高的重度用户，无法忍受频繁的 FailOver 和节点质量参差不齐带来的网络抖动，但是如果是文件分发就比较适合用这种混合方案，可以有效降低 CDN 厂商成本，利用共享经济提高资源利用率。
这篇介绍了推送和传输网络部分，我们已经把流媒体送到了观众的终端中，下一步就是把它展现在屏幕上了，想了解这部分内容请继续关注我们的下一篇内容。
七牛云机构号将实时分享云计算领域的技术洞见以及行业讯息，为你的创新加速。
欢迎提问&求关注 ( ? ▽ ` )?
作者：七牛云
链接：https://zhuanlan.zhihu.com/p/
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
关于直播的技术文章不少，成体系的不多。我们将用七篇文章，更系统化地介绍当下大热的视频直播各环节的关键技术，帮助视频直播创业者们更全面、深入地了解视频直播技术，更好地技术选型。
视频编码是视频直播技术系列文章的第三篇，是本系列一个非常重要的部分，是移动开发必修的基础课程，本篇文章从理论到实践一网打尽主流编码器。
如果把整个流媒体比喻成一个物流系统，那么编解码就是其中配货和装货的过程，这个过程非常重要，它的速度和压缩比对物流系统的意义非常大，影响物流系统的整体速度和成本。同样，对流媒体传输来说，编码也非常重要，它的编码性能、编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本。
本系列文章大纲如下，想复习之前文章的直接点击直达链接：
（三）编码和封装
（四）推流和传输
（五）延迟优化
（六）现代播放器原理
（七）SDK 性能测试模型
视频编码的意义
原始视频数据存储空间大，一个 1080P 的 7 s 视频需要 817 MB
原始视频数据传输占用带宽大，10 Mbps 的带宽传输上述 7 s 视频需要 11 分钟
而经过 H.264 编码压缩之后，视频大小只有 708 k ,10 Mbps 的带宽仅仅需要 500 ms ，可以满足实时传输的需求，所以从视频采集传感器采集来的原始视频势必要经过视频编码。
那为什么巨大的原始视频可以编码成很小的视频呢？这其中的技术是什么呢？
核心思想就是去除冗余信息：
空间冗余：图像相邻像素之间有较强的相关性
时间冗余：视频序列的相邻图像之间内容相似
编码冗余：不同像素值出现的概率不同
视觉冗余：人的视觉系统对某些细节不敏感
知识冗余：规律性的结构可由先验知识和背景知识得到
视频本质上讲是一系列图片连续快速的播放，最简单的压缩方式就是对每一帧图片进行压缩，例如比较古老的 MJPEG 编码就是这种编码方式，这种编码方式只有帧内编码，利用空间上的取样预测来编码。形象的比喻就是把每帧都作为一张图片，采用 JPEG 的编码格式对图片进行压缩，这种编码只考虑了一张图片内的冗余信息压缩，如图 1，绿色的部分就是当前待编码的区域，灰色就是尚未编码的区域，绿色区域可以根据已经编码的部分进行预测（绿色的左边，下边，左下等）。
但是帧和帧之间因为时间的相关性，后续开发出了一些比较高级的编码器可以采用帧间编码，简单点说就是通过搜索算法选定了帧上的某些区域，然后通过计算当前帧和前后参考帧的向量差进行编码的一种形式，通过下面两个图 2 连续帧我们可以看到，滑雪的同学是向前位移的，但实际上是雪景在向后位移，P 帧通过参考帧（I 或其他 P 帧）就可以进行编码了，编码之后的大小非常小，压缩比非常高。
可能有同学对这两张图片怎么来的感兴趣，这里用了 FFmpeg 的两行命令来实现，具体 FFmpeg 的更多内容请看后续章节：
第一行生成带有移动矢量的视频
第二行把每一帧都输出成图片
-flags2 +export_mvs -i tutu.mp4 -vf codecview=mv=pf+bf+bb tutudebug2.mp4
ffmpeg -i tutudebug2.mp4 'tutunormal-%03d.bmp'
除了空间冗余和时间冗余的压缩，主要还有编码压缩和视觉压缩，下面是一个编码器主要的流程图：
图 3、图 4 两个流程，图 3 是帧内编码，图 4 是帧间编码，从图上看到的主要区别就是第一步不相同，其实这两个流程也是结合在一起的，我们通常说的 I 帧和 P 帧就是分别采用了帧内编码和帧间编码。
编码器的选择
前面梳理了一下编码器的原理和基本流程，编码器经历了数十年的发展，已经从开始的只支持帧内编码演进到现如今的 H.265 和 VP9 为代表的新一代编码器，就目前一些常见的编码器进行分析，带大家探索一下编码器的世界。
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 的开源实现
是思科实现的开源 H.264 编码，虽然 H.264 需要交纳不菲的专利费用，但是专利费有一个年度上限，思科把 OpenH264 实现的年度专利费交满后，OpenH264 事实上就可以免费自由的使用了。
x264是一个采用GPL授权的视频编码自由软件。x264 的主要功能在于进行 H.264/MPEG-4 AVC 的视频编码，而不是作为解码器（decoder）之用。
除去费用问题比较来看：
openh264 CPU 的占用相对 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），最高分辨率可达到 （8K分辨率）。
H.265 的开源实现
HEVC 由 struktur 公司以开源许可证 GNU LesserGeneral Public License (LGPL) 提供，观众可以较慢的网速下欣赏到最高品质的影像。跟以前基于H.264标准的解码器相比，libde265 HEVC 解码器可以将您的全高清内容带给多达两倍的受众，或者，减少 50% 流媒体播放所需要的带宽。高清或者 4K/8K 超高清流媒体播放，低延迟/低带宽视频会议，以及完整的移动设备覆盖。具有「拥塞感知」视频编码的稳定性，十分适合应用在 3/4G 和 LTE 网络。
HEVC Advance 要求所有包括苹果、YouTube、Netflix、Facebook、亚马逊等使用 H.265 技术的内容制造商上缴内容收入的 0.5%作为技术使用费，而整个流媒体市场每年达到约 1000 亿美元的规模，且不断增长中，征收 0.5%绝对是一笔庞大的费用。而且他们还没有放过设备制造商，其中电视厂商需要支付每台 1.5 美元、移动设备厂商每台 0.8 美元的专利费。他们甚至没有放过蓝光设备播放器、游戏机、录像机这样的厂商，这些厂商必须支付每台 1.1 美元的费用。最无法令人接受的是，HEVC Advance 的专利使用权追溯到了厂商的「」”，意思是之前已经发售的产品依然要追缴费用。
是由 MulticoreWare 开发，并开源。采用 GPL 协议，但是资助这个项目的几个公司组成了联盟可以在非 GPL 协议下使用这个软件。
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 的开源实现
是 VP8 的唯一开源实现，由 On2 Technologies 开发，Google 收购后将其开放源码，License 非常宽松可以自由使用。
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 的开源实现
是 VP9 的唯一开源实现，由 Google 开发维护，里面有部分代码是 VP8 和 VP9 公用的，其余分别是 VP8 和 VP9 的编解码实现。
VP9 和 H.264 和 HEVC 比较
CodecHEVCx264vp9HEVC-42.2%32.6%x.5%vp948.3%-14.6%CodecHEVC vs. VP9(in %)VP9 vs. x264 (in %)Total Average引用 Comparative Assessment of H.265/MPEG-HEVC, VP9, and
H.264/MPEG-AVC Encoders for Low-Delay Video Applications 这篇比较新的论文对，低延迟视频进行编码的测试结果。
HEVC 和 H.264 在不同分辨率下的比较
跟 H.264/MPEG-4 相比，HEVC 的平均比特率减低值为：
分辨率480P720P1080P4K UHDHEVC52%56%62%64%可见码率下降了 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 倍
谈到视频编码相关内容就不得不提一个伟大的软件包 — 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 下载地址是 :
可以浏览器输入下载，目前支持 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
ffmpeg -r 30 -f avfoundation -i 1 -vcodec h264 screen.mp4
然后用 ffplay 播放就可以了
ffplay screen.mp4
ffplay screen2.webp
FFmpeg 视频转换成 gif
有一个特别有用的需求，在网上发现了一个特别有趣的视频想把它转换成一个动态表情，作为一个 IT 从业者，我第一个想到的不是下载一个转码器，也不是去找一个在线转换网站，直接利用手边的工具 FFmpeg，瞬间就完成了转码：
ffmpeg -ss 10 -t 10
-i tutu.mp4
## -ss 指从 10s 开始转码,-t 指转换 10s 的视频 -s
FFmpeg 录制屏幕并直播
可以继续扩展例子1，直播当前屏幕的内容，向大家介绍一下怎么通过几行命令搭建一个测试用的直播服务：
Step 1：首先安装 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
-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 480x320 -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 是个优秀的工具，可以通过它完成很多日常的工作和实验，但是距离提供真正可用的流媒体服务、直播服务还有非常多的工作要做，这方面可以参考七牛云发布的
介绍完了视频编码后，再来介绍一些封装。沿用前面的比喻，封装可以理解为采用哪种货车去运输，也就是媒体的容器。
所谓容器，就是把编码器生成的多媒体内容（视频，音频，字幕，章节信息等）混合封装在一起的标准。容器使得不同多媒体内容同步播放变得很简单，而容器的另一个作用就是为多媒体内容提供索引，也就是说如果没有容器存在的话一部影片你只能从一开始看到最后，不能拖动进度条（当然这种情况下有的播放器会话比较长的时间临时创建索引），而且如果你不自己去手动另外载入音频就没有声音，下面介绍几种常见的封装格式和优缺点：
AVI 格式（后缀为 .AVI）: 它的英文全称为 Audio Video Interleaved ，即音频视频交错格式。它于 1992 年被 Microsoft 公司推出。
这种视频格式的优点是图像质量好。由于无损AVI可以保存 alpha 通道，经常被我们使用。缺点太多，体积过于庞大，而且更加糟糕的是压缩标准不统一，最普遍的现象就是高版本 Windows 媒体播放器播放不了采用早期编码编辑的AVI格式视频，而低版本 Windows 媒体播放器又播放不了采用最新编码编辑的AVI格式视频，所以我们在进行一些AVI格式的视频播放时常会出现由于视频编码问题而造成的视频不能播放或即使能够播放，但存在不能调节播放进度和播放时只有声音没有图像等一些莫名其妙的问题。
DV-AVI 格式（后缀为 .AVI）: DV的英文全称是 Digital Video Format ，是由索尼、松下、JVC 等多家厂商联合提出的一种家用数字视频格式。
数字摄像机就是使用这种格式记录视频数据的。它可以通过电脑的 IEEE 1394 端口传输视频数据到电脑，也可以将电脑中编辑好的的视频数据回录到数码摄像机中。这种视频格式的文件扩展名也是 avi。电视台采用录像带记录模拟信号，通过 EDIUS 由IEEE 1394端口采集卡从录像带中采集出来的视频就是这种格式。
QuickTime File Format 格式（后缀为 .MOV）: 美国Apple公司开发的一种视频格式，默认的播放器是苹果的QuickTime。
具有较高的压缩比率和较完美的视频清晰度等特点，并可以保存alpha通道。
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画质的小体积视频文件。
WMV 格式（后缀为.WMV .ASF）: 它的英文全称为Windows Media Video，也是微软推出的一种采用独立编码方式并且可以直接在网上实时观看视频节目的文件压缩格式。
WMV格式的主要优点包括：本地或网络回放,丰富的流间关系以及扩展性等。WMV 格式需要在网站上播放，需要安装 Windows Media Player（ 简称 WMP ），很不方便，现在已经几乎没有网站采用了。
Real Video 格式（后缀为 .RM .RMVB）: Real Networks 公司所制定的音频视频压缩规范称为Real Media。
用户可以使用 RealPlayer 根据不同的网络传输速率制定出不同的压缩比率，从而实现在低速率的网络上进行影像数据实时传送和播放。RMVB 格式：这是一种由RM视频格式升级延伸出的新视频格式，当然性能上有很大的提升。RMVB 视频也是有着较明显的优势，一部大小为700MB左右的 DVD 影片，如果将其转录成同样品质的 RMVB 格式，其个头最多也就 400MB 左右。大家可能注意到了，以前在网络上下载电影和视频的时候，经常接触到 RMVB 格式，但是随着时代的发展这种格式被越来越多的更优秀的格式替代，著名的人人影视字幕组在2013年已经宣布不再压制 RMVB 格式视频。
Flash Video 格式（后缀为 .FLV）:由 Adobe Flash 延伸出来的的一种流行网络视频封装格式。随着视频网站的丰富，这个格式已经非常普及。
Matroska 格式（后缀为 .MKV）:是一种新的多媒体封装格式，这个封装格式可把多种不同编码的视频及16条或以上不同格式的音频和语言不同的字幕封装到一个 Matroska Media 档内。它也是其中一种开放源代码的多媒体封装格式。Matroska 同时还可以提供非常好的交互功能，而且比 MPEG 的方便、强大。
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 协议。
下一期我们将系统讲解视频直播的推流和传输，敬请期待~
作者：七牛云
链接：https://zhuanlan.zhihu.com/p/
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
七牛云于 6 月底发布了一个针对视频直播的实时流网络 LiveNet 和完整的直播云解决方案，很多开发者对这个网络和解决方案的细节和使用场景非常感兴趣。
我们将用七篇文章，更系统化地介绍当下大热的视频直播各环节的关键技术，帮助视频直播创业者们更全面、深入地了解视频直播技术，更好地技术选型。
本系列文章大纲如下，想复习之前文章的直接点击直达链接：
（二）处理
（三）编码和封装
（四）推流和传输
（五）延迟优化
（六）现代播放器原理
（七）SDK 性能测试模型
在上期中，我们介绍了视频采集针对音频采集和图像采集以及它们分别对应两种完全不同的输入源和数据格式。 本篇是《解密视频直播技术》系列之二：处理。我们将讲解常见视频处理功能如美颜、视频水印、滤镜、连麦等。
视频或者音频完成采集之后得到原始数据，为了增强一些现场效果或者加上一些额外的效果，我们一般会在将其编码压缩前进行处理，比如打上时间戳或者公司 Logo 的水印，祛斑美颜和声音混淆等处理。在主播和观众连麦场景中，主播需要和某个或者多个观众进行对话，并将对话结果实时分享给其他所有观众，连麦的处理也有部分工作在推流端完成。
开放式设计
如上图所示，处理环节中分为音频和视频处理，音频处理中具体包含混音、降噪和声音特效等处理，视频处理中包含美颜、水印、以及各种自定义滤镜等处理。对于七牛这样的直播云服务来说，为了满足所有客户的需求，除了要提供这些「标准」处理功能之外，我们还需要将该模块设计成可自由接入自定义处理功能的方式。
iOS SDK 地址：
Android SDK 地址：
常见视频处理功能
都说「80% 的主播没有美颜根本没法看」，美颜是直播产品中最常见的功能之一。最近准备在香港上市的美图公司的主打产品就是美颜相机和美拍，有媒体戏称其会冲击化妆品行业，其实就是美颜的效果的功劳，让美女主播们不化妆也可以自信的直播，而美颜相机的用户则可以拍出「更好的自己」。
美颜的主要原理是通过「磨皮+美白」来达到整体美颜的效果。磨皮的技术术语是「去噪」，也即对图像中的噪点进行去除或者模糊化处理，常见的去噪算法有均值模糊、高斯模糊和中值滤波等。当然， 由于脸部的每个部位不尽相同，脸上的雀斑可能呈现出眼睛黑点的样子，对整张图像进行「去噪」处理的时候不需要将眼睛也去掉，因此这个环节中也涉及到人脸和皮肤检测技术。
在我们的直播系统中提供的 iOS 和 Android 推流 SDK 中内置了美颜功能，你可以根据自己的需要选择开关美颜功能，并且能够自由调节包括美颜，美白，红润等在内的参数。其中 iOS 端 SDK PLCameraStreamingKit 的参数设置如下：
1）按照默认参数开启或关闭美颜：
-(void)setBeautifyModeOn:(BOOL)beautifyModeOn;
2）设置美颜程度，范围为 0 ~ 1：
-(void)setBeautify:(CGFloat)
3）设置美白程度，范围为 0 ~ 1
-(void)setWhiten:(CGFloat)
4）设置红润程度，范围为 0 ~ 1
-(void)setRedden:(CGFloat)
2.视频水印
水印是图片和视频内容中常见的功能之一，它可用于简单是版权保护，或者进行广告设置。处于监管的需求，国家相关部门也规定视频直播过程中必须打上水印，同时直播的视频必须录制存储下来保存一定的时间，并在录制的视频上打上水印。
视频水印包括播放器水印和视频内嵌水印两种方式可供选择，对于播放器水印来说，如果没有有效的防盗措施，对于没有播放鉴权的推流，客户端拿到直播流之后可以在任何一个不带水印的播放器里面播放，因此也就失去了视频保护的能力。综合考虑云端录制对于水印的需求，我们一般会选择「视频内嵌水印」的方式打水印。
在我们的直播系统中提供的 iOS 和 Android 推流 SDK 中也内置了水印功能，你可以根据自己的需要添加水印或移除水印，并且能够自由设置水印的大小和位置。其中 iOS 端 SDK PLCameraStreamingKit 的参数设置如下：
1）添加水印
-(void)setWaterMarkWithImage:(UIImage *)wateMarkImage position:(CGPoint)
该方法将为直播流添加一个水印，水印的大小由 wateMarkImage 的大小决定，位置由 position 决定，需要注意的是这些值都是以采集数据的像素点为单位的。例如我们使用AVCaptureSessionPreset 进行采集，同时 wateMarkImage.size 为 (100, 100) 对应的origin 为 (200, 300)，那么水印的位置将在大小为 0 的采集画幅中位于 (200, 300) 的位置，大小为 (100, 100)。
2）移除水印
-(void)clearWaterM
除了上面提到的美颜和水印之外，视频中还有很多其它的处理效果也在这个环节完成。七牛直播云提供的 SDK 在开放性设计基础之上，通过数据源回调接口，可以支持各种自定义滤镜的接入。
为了实现丰富的滤镜效果，在 iOS 端可以考虑使用 GPUImage 这个库，这是一个开源的基于GPU的图片或视频的处理框架，内置了多达120多种常见的滤镜效果。有了它，添加实时的滤镜只需要简单地添加几行代码，还可以基于这个库自己写算法实现更丰富端效果。GPUImage 地址：
除了 iOS 端之外，Android 也有 GPUImage 这个库的移植：同时，Google 官方也开源了一个伟大的库，覆盖了 Android 上面很多多媒体和图形图像相关的处理：
连麦是互动直播中常见的需求，其流程如上图所示。主播和部分观众之间可以进行实时互动，然后将互动结果实时播放给其他观众观看。
基于以上业务需求，我们很容易想到基于单向直播原理，在主播端和连麦观众端进行双向推流和双向播流的方式互动，然后在服务端将两路推流合成一路推送给其他观众。但 RTMP 带来的延迟决定了这种方式无法做到用户可接受的互动直播。
实际上，互动直播的主要技术难点在于：
1）低延迟互动：保证主播和互动观众之间能够实时互动，两者之间就像电话沟通，因此必须保证两者能在秒级以内听到对方的声音，看到对方的视频；
2）音画同步：互动直播中对音画同步的需求和单向直播中类似，只不过互动直播中的延迟要求更高，必须保证在音视频秒级传输情况下的秒级同步。
3）音视频实时合成：其他观众需要实时观看到对话结果，因此需要在客户端或者服务端将画面和声音实时合成，然后以低成本高品质的方式传输观众端。
在视频和电话会议领域，目前比较成熟的方案是使用思科或者 WebEx 的方案，但这些商用的方案一不开源，二比较封闭，三成本比较高。对于互动人数比较少的互动直播，目前市场上比较成熟的方案是使用基于 WebRTC 的实时通讯方案。
上图是一个基于 WebRTC 协议实现多方实时通讯的示意图，本地用户（主播）和远程用户（连麦观众）之间的连接通过 RTCPeerConnection API 管理，这个 API 包装了底层流管理和信令控制相关的细节。基于该方案可以轻松实现多人（14 人以下）的多方实时通信，如下图所示：
当然，在通信人数少的情况下，其复杂度相对简单，如 2 人情况下。但人数增多至 4 人之后，其可选的网络结构就增多了，如上图所示，可以每个点之间形成自组织网络的方式通信，也可以以 1 人为中心形成星型通信网络，还可以让大家都通过一个集中式的服务端进行通信。
作为一个高性能、可伸缩的直播基础服务提供商，七牛直播云经过评估选择了以主播为中心形成星形通信网络，支持主播和多个观众之间的互动质量。同时，为了保证合成后的音视频实时传输到其他观众端，这里采用经过改造的 UDP 协议传输：
通过 UDP 降低传输延迟。
在 UDP 之上进行传输控制，保证用户互动体验 QoS。
在下一篇连载中，我们将详细介绍编码和封装。
敬请期待！
七牛云机构号将实时分享云计算领域的技术洞见以及行业讯息，为你的创新加速。
欢迎提问&求关注 ( ? ▽ ` )?
作者：七牛云
链接：https://zhuanlan.zhihu.com/p/
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商}