直播相关知识之二采集、处理、编码和封装

野性酷女 2022-07-11 06:44 734阅读 0赞

# 直播相关知识之二 采集、处理、编码和封装       #

## 总体流程图 ##

![Center][]

## 一. 采集 ##

> 采集是整个视频推流过程中的第一个环节，它从系统的采集设备中获取原始视频数据，将其输出到下一个环节。视频的采集涉及两方面数据的采集：音频采集和图像采集，它们分别对应两种完全不同的输入源和数据格式。
> 
> ### 1.1 采集内容 ###
> 
> #### 1.1.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

> #### 1.1.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.2 采集源 ###
> 
>   
> 
> 
> #### 1.2.1.摄像头采集 ####
> 
>   
>

> > 对于视频内容的采集，目前摄像头采集是社交直播中最常见的采集方式，比如主播使用手机的前置和后置摄像头拍摄。在现场直播场景中，也有专业的摄影、摄像设备用来采集。安防监控场景中也有专业的摄像头进行监控采集。
> 
> >   
> > 
> 
> > 目前七牛提供的 SDK 对以上两类摄像头的采集都支持，对于手机，iOS 和 Android 分别支持前置后置摄像头的采集，只是 iOS 由于设备种类和系统版本不多，因此采集模块兼容性较好；而 Android 需要适配的硬件设备和系统则非常多，目前支持 Android 4.0.3 及以上的摄像头采集。对于专业摄像机或者摄像头，七牛云提供了兼容适合嵌入式系统的 C 语言采集模块的实现，欢迎参考使用：https://github.com/pili-engineering/ipcam\_sdk

> #### 1.2.2.屏幕录制 ####

> > 屏幕录制采集的方式在游戏直播场景中非常常见，目前我们在 Android SDK 中实现了屏幕录制的功能。而 iOS 则由于系统本身没有开放屏幕录制的权限而没法直接操作，但对于 iOS 9 以上的版本，是有个取巧的办法，可以通过模拟一个 AirPlay 镜像连接到（当前 App）自身，这样就可以在软件上捕获到屏幕上的任何操作，达到录制屏幕的效果。
> 
> > 在教育直播或者会场演讲场合，我们经常看见需要录制电脑桌面上 PPT 的场景，针对这种场景，目前市面上比较方便的方案是使用开源的桌面推流工具 OBS 来进行屏幕录制和推流：https://obsproject.com/

> #### 1.2.3.从视频文件推流 ####

> > 除了从硬件设备采集视频进行推流之外，我们也可能需要将一个视频或者音频文件以直播流的形式实时传输给观众，比如在线电台或者电视节目，它们的输入可能直接来自于一些已经录制剪辑好的视频内容。

> ### 1.3 开放式设计 ###
> 
>   
>

> > 以上从采集内容和采集源两个维度分别介绍了视频采集相关的知识，但对于采集源来说，市场上可见的采集源远远不止这三种，即便是摄像头也有很多分类。对于一个完整的覆盖推流、传输和播放三个环节的直播云服务来说，支持尽可能多的采集源和播放终端是一项既无法规避也很难完成的工作。
> 
> > 为了支持市场上所有采集源的接入，我们在 SDK 中采用了开放式的设计，只要采集源实现方遵循相应的接口，即可支持任意的采集源。
> 
> > ![Center 1][]
> 
> > 图中我们把采集的内容分为图像和音频，其中图像的采集源包含摄像头、屏幕录制或者本地的视频文件，甚至是其它需要重新定义和实现的采集源。而音频的采集源包含麦克风、系统声音或者本地音频文件，当然也可以为它定义别的输入源。
> 
> > 这样设计最大的好处在于，可以以轻量的设计方式支持丰富的采集源，而采集源的具体实现也可以交给使用者。
> 
> > 视频或者音频完成采集之后得到原始数据，为了增强一些现场效果或者加上一些额外的效果，我们一般会在将其编码压缩前进行处理，比如打上时间戳或者公司 Logo 的水印，祛斑美颜和声音混淆等处理。在主播和观众连麦场景中，主播需要和某个或者多个观众进行对话，并将对话结果实时分享给其他所有观众，连麦的处理也有部分工作在推流端完成。
> 
> >   
> > 
> 
> > 如上图所示，处理环节中分为音频和视频处理，音频处理中具体包含混音、降噪和声音特效等处理，视频处理中包含美颜、水印、以及各种自定义滤镜等处理。对于七牛这样的直播云服务来说，为了满足所有客户的需求，除了要提供这些「标准」处理功能之外，我们还需要将该模块设计成可自由接入自定义处理功能的方式。
> 
> >   
> > 
> 
> > iOS SDK 地址：https://github.com/pili-engineering/PLMediaStreamingKit
> 
> >   
> > 
> 
> > Android SDK 地址：https://github.com/pili-engineering/PLDroidMediaStreaming

####  ####

## 二. 常见视频处理功能 ##

> ![Center 2][]

> ### 2.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.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)，那么水印的位置将在大小为 1280x720 的采集画幅中位于 (200, 300) 的位置，大小为 (100, 100)。

> ##### 2）移除水印 #####

> > \-(void)clearWaterMark;

> ### 2.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

> ### 2.4. 连麦 ###
> 
> ![Center 3][]  
>

> > 连麦是互动直播中常见的需求，其流程如上图所示。主播和部分观众之间可以进行实时互动，然后将互动结果实时播放给其他观众观看。
> 
> > 基于以上业务需求，我们很容易想到基于单向直播原理，在主播端和连麦观众端进行双向推流和双向播流的方式互动，然后在服务端将两路推流合成一路推送给其他观众。但 RTMP 带来的延迟决定了这种方式无法做到用户可接受的互动直播。
> 
> > 实际上，互动直播的主要技术难点在于：
> 
> > 1）低延迟互动：保证主播和互动观众之间能够实时互动，两者之间就像电话沟通，因此必须保证两者能在秒级以内听到对方的声音，看到对方的视频；
> 
> > 2）音画同步：互动直播中对音画同步的需求和单向直播中类似，只不过互动直播中的延迟要求更高，必须保证在音视频秒级传输情况下的秒级同步。
> 
> > 3）音视频实时合成：其他观众需要实时观看到对话结果，因此需要在客户端或者服务端将画面和声音实时合成，然后以低成本高品质的方式传输观众端。
> 
> > 在视频和电话会议领域，目前比较成熟的方案是使用思科或者 WebEx 的方案，但这些商用的方案一不开源，二比较封闭，三成本比较高。对于互动人数比较少的互动直播，目前市场上比较成熟的方案是使用基于 WebRTC 的实时通讯方案。
> 
> > ![Center 4][]
> 
> > 上图是一个基于 WebRTC 协议实现多方实时通讯的示意图，本地用户（主播）和远程用户（连麦观众）之间的连接通过 RTCPeerConnection API 管理，这个 API 包装了底层流管理和信令控制相关的细节。基于该方案可以轻松实现多人（14 人以下）的多方实时通信，如下图所示：
> 
> > ![Center 5][]
> 
> > 当然，在通信人数少的情况下，其复杂度相对简单，如 2 人情况下。但人数增多至 4 人之后，其可选的网络结构就增多了，如上图所示，可以每个点之间形成自组织网络的方式通信，也可以以 1 人为中心形成星型通信网络，还可以让大家都通过一个集中式的服务端进行通信。
> 
> > ![Center 6][]
> 
> > 作为一个高性能、可伸缩的直播基础服务提供商，七牛直播云经过评估选择了以主播为中心形成星形通信网络，支持主播和多个观众之间的互动质量。同时，为了保证合成后的音视频实时传输到其他观众端，这里采用经过改造的 UDP 协议传输：
> 
> > 通过 UDP 降低传输延迟。
> 
> > 在 UDP 之上进行传输控制，保证用户互动体验 QoS。
> 
> > 如果把整个流媒体比喻成一个物流系统，那么编解码就是其中配货和装货的过程，这个过程非常重要，它的速度和压缩比对物流系统的意义非常大，影响物流系统的整体速度和成本。同样，对流媒体传输来说，编码也非常重要，它的编码性能、编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本。

## 三. 编码 ##

> ### 3.1 视频编码的意义 ###

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

> ### 3.2 基本原理 ###

> > 那为什么巨大的原始视频可以编码成很小的视频呢？这其中的技术是什么呢？
> 
> > 核心思想就是去除冗余信息：
> 
> > 空间冗余：图像相邻像素之间有较强的相关性
> 
> > 时间冗余：视频序列的相邻图像之间内容相似
> 
> > 编码冗余：不同像素值出现的概率不同
> 
> > 视觉冗余：人的视觉系统对某些细节不敏感
> 
> > 知识冗余：规律性的结构可由先验知识和背景知识得到
> 
> > 视频本质上讲是一系列图片连续快速的播放，最简单的压缩方式就是对每一帧图片进行压缩，例如比较古老的 MJPEG 编码就是这种编码方式，这种编码方式只有帧内编码，利用空间上的取样预测来编码。形象的比喻就是把每帧都作为一张图片，采用 JPEG 的编码格式对图片进行压缩，这种编码只考虑了一张图片内的冗余信息压缩，如图 1，绿色的部分就是当前待编码的区域，灰色就是尚未编码的区域，绿色区域可以根据已经编码的部分进行预测（绿色的左边，下边，左下等）。
> 
> > ![Center 7][]
> 
> >   
> > 
> 
> > 图1
> 
> > 但是帧和帧之间因为时间的相关性，后续开发出了一些比较高级的编码器可以采用帧间编码，简单点说就是通过搜索算法选定了帧上的某些区域，然后通过计算当前帧和前后参考帧的向量差进行编码的一种形式，通过下面两个图 2 连续帧我们可以看到，滑雪的同学是向前位移的，但实际上是雪景在向后位移，P 帧通过参考帧（I 或其他 P 帧）就可以进行编码了，编码之后的大小非常小，压缩比非常高。
> 
> > ![Center 8][]
> 
> > 图 2
> 
> > 可能有同学对这两张图片怎么来的感兴趣，这里用了 FFmpeg 的两行命令来实现，具体 FFmpeg 的更多内容请看后续章节：
> 
> >   
> > 
> 
> > 第一行生成带有移动矢量的视频
> 
> > 第二行把每一帧都输出成图片
> 
> > ffmpeg  -flags2 +export\_mvs -i tutu.mp4 -vf codecview=mv=pf+bf+bb tutudebug2.mp4
> 
> >   
> > 
> 
> > ffmpeg -i tutudebug2.mp4 'tutunormal-%03d.bmp'
> 
> > 除了空间冗余和时间冗余的压缩，主要还有编码压缩和视觉压缩，下面是一个编码器主要的流程图：
> 
> > ![Center 9][]
> 
> >   
> > 
> 
> > 图 3

> ![Center 10][]

> > 图 4
> 
> > 图 3、图 4 两个流程，图 3 是帧内编码，图 4 是帧间编码，从图上看到的主要区别就是第一步不相同，其实这两个流程也是结合在一起的，我们通常说的 I 帧和 P 帧就是分别采用了帧内编码和帧间编码。

> ### 3.3 编码器的选择 ###

> > 前面梳理了一下编码器的原理和基本流程，编码器经历了数十年的发展，已经从开始的只支持帧内编码演进到现如今的 H.265 和 VP9 为代表的新一代编码器，就目前一些常见的编码器进行分析，带大家探索一下编码器的世界。
> 
> > #### 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 x264是一个采用GPL授权的视频编码自由软件。x264 的主要功能在于进行 H.264/MPEG-4 AVC 的视频编码，而不是作为解码器（decoder）之用。
> 
> > 除去费用问题比较来看：
> 
> > openh264 CPU 的占用相对 x264低很多
> 
> > openh264 只支持 baseline profile，x264 支持更多 profile
> 
> > 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 网络。
> 
> > 专利许可
> 
> > HEVC Advance 要求所有包括苹果、YouTube、Netflix、Facebook、亚马逊等使用 H.265 技术的内容制造商上缴内容收入的 0.5%作为技术使用费，而整个流媒体市场每年达到约 1000 亿美元的规模，且不断增长中，征收 0.5%绝对是一笔庞大的费用。而且他们还没有放过设备制造商，其中电视厂商需要支付每台 1.5 美元、移动设备厂商每台 0.8 美元的专利费。他们甚至没有放过蓝光设备播放器、游戏机、录像机这样的厂商，这些厂商必须支付每台 1.1 美元的费用。最无法令人接受的是，HEVC Advance 的专利使用权追溯到了厂商的「」”，意思是之前已经发售的产品依然要追缴费用。
> 
> > x265 是由 MulticoreWare 开发，并开源。采用 GPL 协议，但是资助这个项目的几个公司组成了联盟可以在非 GPL 协议下使用这个软件。
> 
> > #### 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 非常宽松可以自由使用。
> 
> > #### 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 比较
> 
> > Codec HEVC x264 vp9
> 
> > HEVC \-42.2% 32.6%
> 
> > x264 75.8% 18.5%
> 
> > vp9 48.3% \-14.6%   
> > 
> 
> > Codec HEVC vs. VP9(in %) VP9 vs. x264 (in %)
> 
> > Total Average 612 39399
> 
> > 引用 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 的平均比特率减低值为：
> 
> > 分辨率 480P 720P 1080P 4K UHD
> 
> > HEVC 52% 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。
> 
> > 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 下载地址是 : FFmpeg Download
> 
> > 可以浏览器输入下载，目前支持 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 80x60  tutu.gif
> 
> > \#\# -ss 指从 10s 开始转码,-t 指转换 10s 的视频 -s
> 
> > FFmpeg 录制屏幕并直播
> 
> > 可以继续扩展例子1，直播当前屏幕的内容，向大家介绍一下怎么通过几行命令搭建一个测试用的直播服务：
> 
> > Step 1：首先安装 docker：
> 
> > 访问 Docker Download ，按操作系统下载安装。
> 
> > 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 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 协议。

\--- end ---

[Center]: /images/20220711/48f8aeb04f344ba3bc4bbd343b8c8923.png
[Center 1]: /images/20220711/1d3d3a0135d64a6cb9e4c2f1adfc202d.png
[Center 2]: /images/20220711/43a4600f7149456aa6397a58731ebf6d.png
[Center 3]: /images/20220711/7f68cb10c2a0492981fdb8de24753363.png
[Center 4]: /images/20220711/83979fac4f9a43c992024ab80ead153e.png
[Center 5]: /images/20220711/487addabef4e4f748231a61518dd5fd8.png
[Center 6]: /images/20220711/830353a6855140b199be3a997021ddc7.png
[Center 7]: /images/20220711/6ca91afe278049d6892ccda1703c94ff.png
[Center 8]: /images/20220711/8291554443e647c8aa16de87d2314ecb.png
[Center 9]: /images/20220711/39fc03ecdb0a49f9a1e15aae98bbc788.png
[Center 10]: /images/20220711/b863b2b94ac14ea89b186433d8729369.png