程序员必备的图像视角

作者: __Adan__ | 来源:发表于2018-03-16 17:36 被阅读346次


##0 从一个Bug说起

##1 视频基础知识

###1.1图像与视频

###1.2 每一个像素需要多少比特位?

####1.2.1 Bit-Depth

####1.2.2 高Bit-Depth的好处

###1.3肉眼对世界感知的特性-人类视觉系统[Human Visual System](http://blog.csdn.net/tianzhaixing2013/article/details/42174801)

####1.4颜色空间

#####1.4.1 巧用人眼的生物特性

 #####1.4.2 常用的采样格式 

##2.编解码基础知识

###2.1为什么要进行编解码

###2.2怎么样做编解码

###2.3怎么样衡量一个压缩,看什么技术指标

####2.3.1图像熵与平均码长

####2.3.2编码效率

####2.3.3压缩比

####2.3.4客观评价信噪比SNR(signal-to-noise ratio)

####2.3.5主观评价

####2.3.6算法的适用范围和复杂度

###2.4那实际中编码系统是怎么样构成的

##3 都有哪些重要的编解码标准 

###3.1 编码的演进历史

###3.2 编码标准的在历史长河中的使命

###4 为什么会有这一系列的标准,这些标准背后到底隐藏了什么东西

####4.1 巨头之间的战争

####4.2 巨头们的核武器-专利

####4.3 未来谁为王者?

0.从一个Bug说起

有次出现录制视频失败,恰逢苹果新机器上市.

iPhone8,iPhoneX上市之后,新增加了一种视频编码格式-H265,而且强推H265,直接把推荐编码类型设置为H265.

而我们需要录制视频,在压制视频的时候选择的Profile配置类型却是H264的.....俩者不match这直接导致了录制失败.

解决这个问题,其实也不难,把视频编码格式设置回H264就好了.或者Profile选择为H265的Profile就搞定了.

等等,苹果怎么这个时候力推H265,这货到底是啥? 对未来有什么影响?

本文主要是基于之前组内的分享,梳理之后形成.如果内容有补充,或者更正,欢迎留言指正.

为了弄明白H265,首先你必须知道编解码的基础知识,相信不少同学已经掌握了这一技能,你也可以快速扫一下,这花不了多少时间.

1.视频基础知识

1.1图像与视频

图像: 是人对视觉感知的物质再现.每一张图像的背后,都是数字化的像素点.

image.png

视频: 连续的图像

数字视频是对自然场景空间和时间的数字采样表示,在空间上我们关注于分辨率,时间上我们关注帧率

1.2 每一个像素需要多少比特位?

1.2.1 Bit-Depth

在代码里,相信很多人经常看到255这样的敏感数字,也就是说一个颜色的分量使用的8bit(一个颜色通道chanel使用的是8bit来表示,那如果这个颜色空间是RGB,3通道来着,一个颜色就是用24个bit来表示). 8bcp（bit per channel）基本上意味着你可以捕获256种颜色/亮度值（0-255）在每个RGB通道(关于channel的解释,请见Channel (digital image))，一个像素能够表达的颜色就是 256x256x256 = 16million +颜色.

当前的主流是8bit,但是随着硬件的更新换代,相信10bit普及的时代也不远了.

1.2.2 高Bit-Depth的好处

很多文章举了不少例子来说明高bit-depth的好处,可以参考understanding-8bit-vs-10bit,我个人觉得主要有俩点

1.2.2.1 颜色range更大

bit位越多,意味这颜色的range越大,能够表达的色彩越细腻.但是也会使得图像的大小几何倍数递增.

下面五张图分别是 1bit per channel, 2 bit per channel, 4 bit per channel,8 bit per channel, 32 bit per channel 的效果.

image.png

1.2.2.2 10bit相比较8bit 在同等图像质量下更加节省带宽

这个地方主要涉及到抖动和色带. 下图是一张天空中带有色带的图像.

image.png

我们通过抖动来欺骗肉眼,让人的视觉产生连续性, 而不是断层.做法就是在边界处,采用一定算法,让这些像素交融渗透. 其实并没有增加颜色的种类.

image.png

仔细看在过渡区,是有一个个小颗粒,这就是噪点.

image.png

为了解决low-bit这个问题,我们其实引入了噪点,掺杂了其他信息到图像里,使得图像的信噪比下降.

1.3肉眼对世界感知的特性-人类视觉系统Human Visual System

为什么我们需要了解这部分内容,因为说到底,视频和图像最终是要给人看的,视频和图像如果能切合肉眼感知世界的特性,那对于我们理解如何构造图像与视频是极有利的.

人类对光的感知是依靠视网膜(retina)细胞。cones(圆锥细胞)负责感知光度(较强光)和色彩, rods(杆状细胞)仅能感知光度，不能感知颜色，但其对光的敏感度是cones的一万倍。因此我们不能在暗环境中分辨颜色。但是却能看清楚物理的轮廓,并分辨出来.

得出的结论是:人类对亮度信号较敏感，对色度信号较不敏感。

1.4颜色空间

讲述了一个像素点中对应的颜色是如何表达.常见的表达形式有RGB,YUV,CMYK等.

绝大部分人对于RGB颜色空间的表达在这几种类型里应该是最清楚的,也是最熟悉的.

下图是红绿蓝(RGB)叠加显示:

image.png

1.4.1 巧用人眼的生物特性

正如上面提到的人类视觉系统,视觉专家研究出来的结论是人眼对亮度的敏感度高于对色彩的敏感度。

于是我们将视频信号会分解为亮度(Luma)和色度(Chroma)，这两个是组成色彩的元素，这类似于图像可以分解为红、绿、蓝三个元素。

亮度和色度元素被称为YUV（模拟信号）或YCbCr（数字信号）而不是RGB。

YCbCr 则是在世界数字组织视频标准研制过程中作为ITU - R BT.601 建议的一部分，其实是YUV经过缩放和偏移的翻版。其中Y与YUV 中的Y含义一致,Cb,Cr 同样都指色彩，Cb指蓝色色度分量，而Cr指红色色度分量,只是在表示方法上不同而已。一般人们所讲的YUV大多是指YCbCr。

image

这意味着亮度(Luma)信息,对于我们人眼价值更高,如果我们让相邻元素共享同一个色度(Chroma)信息,让有限的带宽来传递更多高价值信息(亮度信息).

1.4.2 常用的采样格式

由于通过对色度分量进行子采样来减少色度分量后，肉眼将察觉不到的图像质量的变化,有限的数据量中,填入了更多对人眼敏感的信息。在实际操作中,主要有如下几种子采样格式有 YCbCr 4:2:0、YCbCr 4:2:2 和 YCbCr 4:4:4。

在这里就不展开了,主要的核心是每俩个像素或者四个像素,他们是如何共享同样的色度信息,从而减少信息量(毕竟肉眼对色度信息不敏感).

如果你想详细了技术细节,请参考

什么是4:4:4、4:2:2、4:2:0？了解图像压缩取样的方式

百度百科YCbCr

2.编解码基础知识

2.1为什么要进行编解码

节省空间!

我们都知道视频流是一帧帧图像组成,可能是60fps,也可能是30fps,意思就是一秒多少帧.

如果以fps是30帧的速率来看,一个640*480分辨率的视频流,每个像素2个Byte(YUV格式).

一秒钟的数据量会是 3064048028bit ,也就是说如果不压缩,那么码率已经到达 14.4MB/s,更别说720P或者1080P.

每一张图的数据大小:Channels x Bit Depth x Chroma Subsampling Percentage x Resolution

码率:Data rate = Size of one frame x number of frames per second

2.2怎么样做编解码

那为什么做压缩存在可能性?我们要从哪几方面入手才能做到高压缩比

空间冗余：图像相邻像素之间有较强的相关性,特别是一片大白墙,这就是帧内压缩.

采用的是用相邻像素间的差异来描绘编码---预测编码

时间冗余：视频序列的相邻图像之间内容相似,帧间压缩靠得就是它.
编码冗余：不同像素值出现的概率不同,这个其实也不难理解,和可变长度字符编码有点像,理论依据是

概率相等,且统计独立时,图像具有最大熵.但是实际上,并不是均等概率.

image.png

注:code1是常规思路的编码,code2是优化之后的编码形式,你可以看到大概率的占据的位数变少.

常用的编码有:哈夫曼编码,香农编码,费诺编码,这类一般都是无损压缩.

视觉冗余：人的视觉系统对某些细节不敏感,人眼对视觉信息感受的灵敏度不同.去除不敏感信息不会明显降低图片质量.

消除心里视觉冗余会导致一定量的数据丢失,这一过程通常被称为量化.结果导致了数据的有损压缩.

人类视觉系统的一般分辨能力估计为26个灰度等级，而一般图像量化采用的是28个灰度等级.

量化等级越多，所得图像层次越丰富，灰度分辨率高，图像质量好，但数据量大；量化等级越少，图像层次欠丰富，灰度分辨率低，会出现假轮廓现象，图像质量变差，但数据量小.

2.3怎么样衡量一个压缩编码方法,看什么技术指标

2.3.1图像熵与平均码长

图像熵指该图像的平均信息量，即表示图像中各个灰度级比特数的统计平均值，等概率事件的熵最大。下图P中就是对应事件的概率.

image.png

那如果我们使用了某一种编码,针对这种编码,我们可以计算出来编码的平均码长.

image.png

对于有计算机信息论背景知识的同学,熵值是平均码长的下限,我们无法找到一种平均码长小于熵指的编码方式.

信息量类似于水量,小的桶子肯定装不小这么多信息.

所以

平均码长 >> H(X) :说明有冗余,不是最佳
平均码长 < H(X) : 不可能
平均码长约等于 H(X) : 最佳编码

比如说下面这个例子:

image.png

图像的熵 H = 1.6614 比特/像素；

采用编码1方案，平均码长是 8比特；采用编码2方案，平均码长是 0.25×2+0.47×1+0.25×3+0.03×3=1.81比特；

2.3.2编码效率

根据前面对于图像熵以及编码平均码长这俩个概念的理解.我们可以定义出来编码效率.

编码效率=H(x)/编码平均码长, 如果编码效率接近于1则说明编码效率高.

2.3.3压缩比

压缩比= 压缩前平均码长/压缩后的平均码长

2.3.4客观评价信噪比SNR(signal-to-noise ratio)

压缩既然可能存在信息丢失(有损压缩),那我们就需要评价信息损失的测度,来描述解码图像相对于原始图像的偏离程度.

这就是保真度准则,这种情况下我们一般构造一个损失函数来衡量,如下,x,y表示是对应的坐标位置f(x,y)代表编码前的某一个点

对应的真实数值,f'(x,y)表示的是解码后对应这个点的值.那么对每一个点的信息,经过编解码之后的误差就是.

image.png

我们把这张图上每个点的误差,都加起来就形成了整张图的误差量

image.png

那这张图的均方根误差就是

image.png

从而我们可以得到对应的均放信噪比

image.png

根据信息论,噪音越大,意味着,我们在有损压缩过程损失了过多的原始真实信息,带了噪音.这会导致信噪比比较低.

2.3.5主观评价

这个主要是观察者肉眼的自我感觉,感性成分比较多.

2.3.6算法的适用范围和复杂度

适用范围:有一些编码算法的适用范围比较窄,比如像分形编码就主要用于自相似性高的图像.
算法的复杂度: 算法的复杂度指完成图像压缩和解压缩所需的运算量和硬件实现该算法的难易程度。优秀的压缩算法要求有较高的压缩比，压缩和解压缩快，算法简单，易于硬件实现，还要求解压缩后的图像质量较好。

2.4那实际中编解码系统是怎么样构成的

image

看到这张图是不是有点懵,其实很思路很简单

我们先重点看这张图的上半部分,编码部分

image

说白了,

预测阶段做的事情是时空压缩:举个简单的例子，因为像素的灰度是连续的，所以在一片区域中，相邻像素之间灰度值的差别可能很小。如果我们只记录第一个像素的灰度，其它像素的灰度都用它与前一个像素灰度之差来表示，就能起到压缩的目的。如248，2，1，0，1，3，实际上这6个像素的灰度是248，250，251，251，252，255。表示250需要8个比特，而表示2只需要两个比特，这样就实现了压缩。
变换阶段

这里你需要稍微了解一下"空间域"和"频率域".

科学家通过研究,发现图像的频谱函数统计特性：图像的大部分能量集中在低，中频，高频部分的分量很弱，仅仅体现了图像的某些细节。

这意味着我们在量化的过程中,多给比特到低频信息,少给到高频,能够大大提升效率.

频域（频率域）——自变量是频率,即横轴是频率,纵轴是该频率信号的幅度,也就是通常说的频谱图。频谱图描述了信号的频率结构及频率与该频率信号幅度的关系。

空间域又称图像空间(image space)。由图像像元组成的空间。在图像空间中以长度(距离)为自变量直接对像元值进行处理称为空间域处理。

知乎有个解释很形象:


假如不从灰阶和色彩上下刀, 那在空间域你只能通过裁切图片来进行压缩.
这显然不符合现在的要求,你总不能说一张图边界部分没什么用就切掉100像素.

而转换为频域后,信息变成了低频高频(整体和细节).
这时就可以使用心理学模型,省略掉一些不易察觉的细节.或者降低细节部分的颜色/灰阶的位深度.

https://www.zhihu.com/question/39689253

在做变换的时候分成俩大类,

一类是空间域直接对图像进行处理

另一类是"变化域处理",把图像中各个像素从空间域变换到频率域.

一般情况下,我们做这些变换的目的是:编码压缩,图像修复,图像增强等等.

常用的变换有:傅里叶变换,离散余弦变换DCT等

具体怎么做就不展开了,可以参考refer里对应变换的资料.我们只是换了一个角度来看待图像,通过频率域的角度,利用人眼对高低频感知差异来巧妙处理数据.

量化阶段做的去除视觉冗余;
熵编码阶段做去除编码冗余.

而解码阶段,要干的事情却是相反的.

3 都有哪些重要的编解码标准

就如同以前的编解码一样,先来了个ANSI,各搞各的,因为文化差异最终大家无法交流,到了最后出现了Unicode才逐渐统一.

视频编解码一样,设想一下,各自有一套标准,没有形成主流统一的标准,那么最后解码就是个大问题.

于是乎开始出现一些国际标准来标准化视频的编解码,让大家按照规范来办事.

不仅想起<<人类简史>>(ps强烈推荐此书)中提到的,人类的发展史重要的一点就是产生共同的信仰,让更多人对自己族群的信仰达成一致.虽然这个信仰可能在融合其他文明的过程中产生了新的变种.我们看一下编码的演化历史,你更能感受到这种变化.

3.1 编码的演进历史

image.png

不同的国际组织推行了自己的视频编解码标准,除了自家推行的标准不断演化升级, 与此同时又在借鉴其他标准融合升级出新的标准.

每一代算法都有自己的时代局限,一方面是算法复杂度以及算力对于系统的要求,另一个重要就是应用领域的变迁.

随着硬件的提升,新标准通过新的复杂算法来提高自身的编解码能力,使得压缩比更高.

而硬件在发展的又催生了高清视频等超大文件,更加吃带宽.急需更高的压缩.

另一方面,互联网以及移动互联网的发展又对编解码标准产生了新的要求,无论是网络时延还是容错等等具体的技术指标都亟待提升.

而编解码标准就好像一个个人类的族群,在快速成长壮大的同时,吞并了其他文明,吸收了他们的长处,继续前进.

3.2 编码标准的在历史长河中的使命

在这里,我们不对具体的每一个标准进行展开描述,我们关注于现在热门的H264,H265进行讲述,更加具有代表性.

先说一下这俩协议的名字,其实在上图里,你仔细看,也能看出来

HEVC(High Efficiency Video Coding) 是 AVC(Advanced Video Coding) 演进版本，当然你也可能听过它们一些不同的名字，不过是不同标准化组织的标准编号差异罢了，具体可以看下表：

| - | ITU-T (国际电信联盟电信标准化部门) | ISO (国际标准化组织) |

| :--: | :-------------------: | :--------------------------------------: |

| AVC | H.264 | ISO/IEC: 14496 MPEG-4 Part 10 |

| HEVC | H.265 | ISO/IEC: 23008 MPEG-H Part 2 |

在描述一套标准的时候,有俩个关键词离不开,一个是Profile,一个是Level

Profile是对视频压缩特性的描述
Level则是对视频本身特性的描述(码率,分辨率,fps)

基本上每一套标准从低到高划分了很多Profile和Level,而如果设备说他支持这套标准,那么开发者或者用户一看标准里的Profile和Level就能知道大概.

Profile越高，就说明采用了越高级的压缩特性。Level越高，视频的码率、分辨率、fps越高。

profile主要是定义了编码工具的集合，不同的profile，包含了不同的编码技术；

而level主要是对码流的关键参数的取值范围作了限定，与解码器的处理能力和存储能力相关联

简表（profile）与级别（level）规定了对比特流的限制，因此也限制了比特流解码所需的能力。

3.2.1关于H264

H264相比较H263的算法更加复杂，程序实现烦琐，运行它需要更多的处理器和内存资源。因此，运行H264对系统要求是比较高的。
H264是ITU-T的VCEG (Video Coding Experts Group)和ISO/IEC的MPEG(Motion Picture Experts Group)联合成立的“联合视频组”(JVT:Joint Video Team)共同制定的新建议，它等同于ISO的MPEG-4的Part10

H264是H263的发展和延续，同时吸收了MPEG的一些优点。它的码流结构网络适应性强，增加了差错恢复能力，能够很好地适应IP和无线网络的应用.

具体的H264可以到wiki上面查看

H264并不是一个一成不变,固定的版本,我们可以看到H264是有很多Version,也就是说这家伙在第一个版本发布之后,还一直在前进演变.

image.png

3.2.1.1 H264的Profile

对于这些Profile,我们可以看到他们支持的功能特征点, CBP,BP,XP,MP 这一行代表一系列的Profile,纵列是功能特征点

image.png

BP不可以使用双向预测就是图中的(B Slice)，MP可以使用双向预测。双向预测使得是同质量情况下码流的减少，省下不少带宽。

那么既然有Main这么好的东西，凭什么还留着Base，一步到位不就行了？时间与空间永远是一对矛盾，省了时间，就占多点空间；省点空间，就费点时间。
h.264是一种为求省点空间无所不用其极的技术，从Base级一直到High级，一级比一级复杂，计算量更大。而厂家唯求节省硬件成本，未必要求极致，所以各个级别皆有其应用场合。总之，一分钱一分货，用High级的硬件肯定是最贵的。当然，实现起来也是最复杂的。

3.2.1.2 H264的Level

对于Level, Wiki上面是这么说的,

As the term is used in the standard, a "level" is a specified set of constraints that indicate a degree of required decoder performance for a profile. For example, a level of support within a profile specifies the maximum picture resolution, frame rate, and bit rate that a decoder may use. A decoder that conforms to a given level must be able to decode all bitstreams encoded for that level and all lower levels.

level 数值是对处理当前码流(比特流)所需的解码器的要求. 这个数值越大, 需要解码器的能力(一般是处理能力及buffer)越大.

我们可以看到

image.png

相同的级别定义集合用于所有的简表，但单独的应用对所支持的简表可能支持不同的级别。

一般来说，对于特定的一个简表，不同的级别对应于解码器的不同处理过程的负载和消耗的存储容量

3.2.1.3 H264的中关于3D视频的内容

随着3D技术的发展,H264也针对3D视频的特性进行压缩,我们可以看到有几个Profile就是专门针对3D视频.


*   Version 18 (Edition 8): (April 13, 2013) Amendment to specify the coding of depth map data for 3D stereoscopic video, including a Multiview Depth High profile.<sup>[[18]](https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#cite_note-AVC8June2013ITURecommendations-18)</sup>

As a result of the [Multiview Video Coding](https://en.wikipedia.org/wiki/Multiview_Video_Coding "Multiview Video Coding") (MVC) extension, the standard contains two *multiview profiles*:

<dt style="font-weight: bold; margin-bottom: 0.1em; color: rgb(34, 34, 34); font-family: sans-serif; font-size: 0.933rem; font-style: normal; text-align: start; text-indent: 0px; background-color: rgb(255, 255, 255);">Stereo High Profile (128)</dt>

<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px; color: rgb(34, 34, 34); font-family: sans-serif; font-size: 0.933rem; font-style: normal; font-weight: 400; text-align: start; text-indent: 0px; background-color: rgb(255, 255, 255);">This profile targets two-view [stereoscopic](https://en.wikipedia.org/wiki/Stereoscopic "Stereoscopic") 3D video and combines the tools of the High profile with the inter-view prediction capabilities of the MVC extension.</dd>

<dt style="font-weight: bold; margin-bottom: 0.1em; color: rgb(34, 34, 34); font-family: sans-serif; font-size: 0.933rem; font-style: normal; text-align: start; text-indent: 0px; background-color: rgb(255, 255, 255);">Multiview High Profile (118)</dt>

<dd style="margin-left: 1.6em; margin-bottom: 0.1em; margin-right: 0px; color: rgb(34, 34, 34); font-family: sans-serif; font-size: 0.933rem; font-style: normal; font-weight: 400; text-align: start; text-indent: 0px; background-color: rgb(255, 255, 255);">This profile supports two or more views using both inter-picture (temporal) and MVC inter-view prediction, but does not support field pictures and macroblock-adaptive frame-field coding.</dd>

<dt style="font-weight: bold; margin-bottom: 0.1em; color: rgb(34, 34, 34); font-family: sans-serif; font-size: 0.933rem; font-style: normal; text-align: start; text-indent: 0px; background-color: rgb(255, 255, 255);">Multiview Depth High Profile (138)</dt>

3.2.2关于H265

H264基本延续了H264的套路,对于他的了解,也一样可以从Profile和Level入手.

这里我们就不详细介绍了,只说一些核心点.

和H264相比较,H265在同等画质下,压缩能力提高了一倍,而且它支持8192×4320的分辨率.

image.png

这也就是为什么苹果在iOS11之后,宣称A9芯片的机器(iPhone6s之后的机器)能够更加节省空间,因为你拍出来的视频已经使用H265进行了编码,压缩比更高.也为什么老机器会越来越卡,😢.....牺牲了时间,来换取空间.

4 为什么会有这一系列的标准,这些标准背后到底隐藏了什么东西

接下来,我们开始讲一些稍微轻松一点的内容.我们重新来看这张图

image.png

这张图只是罗列了视频编码历史上其中的俩三条分支脉络,还有大量的编码标准被我们忽略了.

下面这张图列举了当前世界上主流的编解码标准,组织之多,协议之多,够你看晕眼

image.png

4.1 巨头之间的战争

从上面那张图,我们就可以闻到浓浓的火药味了....

90年代少不了微软,wmv结尾的视频你肯定不少看到.

WMV不是仅仅基于微软公司的自有技术开发的。从第七版（WMV1）开始，微软公司开始使用它自己非标准MPEG- 4 Part 2。但是，由于WMV第九版已经是SMPTE的一个独立标准（421M，也称为VC- 1），WMV的发展已经不像之前那样是一个它自己专有的编解码技术。现在VC-1专利共享的企业有16家（2006年4月），微软公司也是 MPEG-4 AVC/H.264专利共享企业中的一家。

各家公司都推出自己的方案,包括了苹果等等巨头.

我们之前说过一个统一的标准不是凭空出来的,他是一个不断吸收演化变异的过程,很多公司都已经抢占注册了专利.这也极大阻碍了技术普及使用.

假如你是一家初创公司,用了某套标准,今天A上门说,老兄,你用了我的专利,得交钱了.明天B的律师信也来了,罗列了侵犯了他家的专利.这还怎么搞....

不仅仅费用昂贵,而且是交钱无门啊,涉及到的专利权利人太多了.

这个时候专利池的概念就被提出来了,说白了就是薄利多销,促进行业发展,同时专利池的权利人组成了一个联盟,可以互相使用彼此的专利.

专利许可原则。在专利池内部通常遵循平等原则，专利池成员无论专利数量多少其地位一律平等，每一项必要专利无论其作用大小，也平等对待，这是因为专利池中任何一项专利都是技术实施中必不可少的专利。成员间一般相互交叉许可，对外许可收入则主要根据各成员所拥有的专利数量按比例分配。

MPEG－LA这个组织的成立 https://zh.wikipedia.org/wiki/MPEG_LA 直接促进了H264在业界的广泛使用.

由于中国起步时间晚,在专利上我们是比较吃亏.但是随着我们加入了WTO,没办法,知识产权肯定要尊重.这个时候我们国家就开始捣鼓起来了自己的音视频标准AVS.


中国已掌握基于自主AVS标准和芯片的整机开发和系统集成技术，建成完整的数字音视频产业链，从2007年开始相继在浙江、上海、河北、山西、陕西、新疆、山东、湖南、四川等地进行规模化应用，并应用于老挝、斯里兰卡、吉尔吉斯斯坦等。目前，全世界20多家企业开发、销售符合AVS标准的芯片，全球范围内采用AVS标准播出的数字电视频道已有800多套 

中国AVS采用主流的混合编码方案，技术方案简洁，在编码效率与同期国际标准相当的条件下，编码复杂度只有国际标准的30%，解码复杂度只有国际标准的70%。已形成50多项专利构成专利群的AVS在中国还率先建立“专利池”管理机制，为进入国家标准的专利技术设置一站式、低成本专利授权原则和管理细则，每台终端产品只收1元人民币专利费，不对内容提供商和运营商收费，从而大幅降低标准实施的专利成本。

注: 中国AVS十年创新发展促数字视听产业“由大变强”

且不论,AVS做得好不好,如果我们用了国外的专利,那我们就要向他们交保护费.严重阻碍了中华民族的复兴!

所以我们国家撸起袖子做自己的标准,自己的操作系统是有原因的,用别人的,永远跟在别人后面交保护费.这也从另一个角度解释了为什么我们要自主创新.

不禁想起这句话:一流企业定标准、二流企业做品牌、三流企业做产品...

后起之秀的Google在巨头面前也是不甘示弱.H.264和H.265由ITU-T视频编码专家组（VCEG）和MPEG组织共同发起，专利池由诸多企业和组织共同贡献.Google成立是在98年,youtube则是2005年,Google之前的重点一直不在视频领域,当然在这些利益组织(拥有专利的老大哥组成的联盟)面前就是小弟,要是用了这些技术,岂不是要跟着人家走,定期交保护费.

于是Google开始自己做VPX系列算法的,当然了,Google也不是重新发明轮子,财大气粗的Google买下了On2公司,以类似 BSD 授权的形式放出来.Google 也开放了 On2 关于 VP8 的所有专利，将它们作为免版税的。

虽然HEVC/H.265在2013年正式发布成为国际标准，但由于其复杂专利结构导致的较高许可费用，创立之初也未充分考虑到网页播放的友好性，更致命的是复杂的算法让解码端异常吃力，这些原因给了谷歌VP9有机可乘的便利。

于是2015年9月，一个名叫Alliance for Open Media（AOM）的组织成立，目标是替代谷歌VP9以及与HEVC/H.265搏命。

这个组织的创始企业包括Amazon、Cisco、Google、Intel、Microsoft、Mozilla、Netflix7个巨头,后续又拉了十几家重量级公司加入.哦对了,Adobe在这个里头.

伟大的Apple缺席选择了支持H265,当然不跟他们一路.

如果你曾经为了看wwdc的视频,用了chrome浏览器,你会发现,请用Safari打开观看.....原因很简单...苹果是H254/H265阵营, Google对则SayNo

image.png

我们用chrome看youtube,会发现他使用的是webm这个容器, 容器你可以理解就是一个贴牌的瓶子,瓶子外面的标签说明了里边装的是什么葡萄酒(采用的是哪种编解码标准).

image.png

如果用safari,由于safari不支持Google的协议,没办法Google只能用mp4了.....

image.png

这意味着,这份视频,在Google那边的存储是需要俩份的.... 要多花钱买存储.Google为了培育自己的标准,也是不遗余力.

4.2 巨头们的核武器-专利

上一节,讲到科技巨头的圈地收费,这一切都离不开专利.

那专利到底是什么东西,作为一个开发,我们要注意什么东西?

4.2.1 专利的核心注意点

专利是一种针对"商用"权利的保护.我们看看国家对于专利侵权的定义


第十一条 发明和实用新型专利权被授予后，除本法另有规定的以外，任何单位或者个人未经专利权人许可，都不得实施其专利，即不得为生产经营目的制造、使用、许诺销售、销售、进口其专利产品，或者使用其专利方法以及使用、许诺销售、销售、进口依照该专利方法直接获得的产品。

也就是说如果是为了学术研究,纯粹个人兴趣,这种行为对于权利人的经济收益影响是微乎其微,即使在没有权利人同意的情况下,你还是能够使用的.这种权利人一般也懒得告你的.


第六十九条 有下列情形之一的，不视为侵犯专利权：

（二）在专利申请日前已经制造相同产品、使用相同方法或者已经作好制造、使用的必要准备，并且仅在原有范围内继续制造、使用的； 

（四）专为科学研究和实验而使用有关专利的；

4.2.2 开源软件进入商业领域踩中专利雷区

开源软件是在大家自愿开发的基础上,不以商业利用为目的,而是以不收取授权金,自由发布源码供他人使用.在开发流程上是非常自由和多元化,这种海纳百川也容易引入他人专利技术,埋下了炸弹.

这个地方主要问题是,国内版权专利意识起步晚,制度不健全,我们很多人也刚刚从学校毕业踏入职场.学校实验室的思路(ctrl + C & ctrl +V).还没有完全转变过来.

由于,在学校里,我们的目标是学术研究,或者个人爱好,这完全是没有问题的.但是当我们把开源的东西引入到商业领域,这个时候问题就来了.

很典型的一个例子是FFMpeg在其官网关于对于专利的说辞

在视频处理领域里,很多算法是被专利所保护的,FFmpeg也无法避免,经常有人邮件团队询问专利问题,搞得人家不得不专门挂了个页面来说明.

大体意思就是,

首先,关于是否使用专利算法.我们不知道我们自己用了别人的专利了没,因为我们在开发的过程中,并没有去看别人的专利.存在一些迹象表明,我们可能使用了别人的算法.
其次,用了这些专利算法是否无后顾之忧.我们认为要看所在地的司法机构.
最后,我到底要不要因为用了FFmpeg而担心受怕啊.这个要看你的用途,如果是个人,基本上不用担心.如果是商业,是的,已经有这样被起诉的案例... MPEG LA 偶尔会出来对商业公司进行搞事.

看来..... 程序员出来卖艺讨口饭吃还不容易啊...到了山头,记得交保护费.

那我们来看一个典型的案例,Google是怎么使用FFMpeg的.Chromium是Google的开源浏览器,Chrome是没有开源出去的浏览器.

在Chromium上Google是上了FFMpeg支持H264,mp3等解码,但是在chrome上,虽然Google曾经也引入了FFMpeg,却是进行了裁剪,去掉了这些存在雷区的模块.这个事情主要是几方面造成的,