数字视频编码的发展历程

大家久等了,这是多媒体文件格式系列课堂文章的第三篇,前面已经讲过了容器与音频编码,现在我们要看到最为复杂的视频编码了,人们一直在想尽办法提高视频编码的效率,让它在尽可能小的体积内提供最好的画面质量,从而满足人们对于视频传输、存储的需求。和前两篇文章中介绍的容器与音频编码不同的是,视频编码有一条较为清晰的发展脉络,比种类繁多且不统一的音频编码要容易理顺,目前国际通行的视频编码标准基本上都是由MPEG(动态图像专家组)和ITU-T(国际电信联盟电信标准化部门)等组织牵头开发的,另外还有一些零星的编码,它们可能在一段短暂的时间内占据主流地位,不过最终还是让位于国际通行标准。

国际上主要通行的编码标准为ITU-T组织的H.26x系列视频编码和MPEG组织制定的部分编码标准,有一点需要说明的是,同样的一个标准在不同组织那儿可能会叫成不同名字,比如最典型的就是AVC(高级视频编码),大家可能更熟悉它的另一个名字——H.264,AVC是MPEG组织在标准中给它起的名字,MPEG组织从属于国际标准化组织(ISO)和国际电工委员会(IEC),所以在ISO标准中,它的正式名字是“MPEG-4 Part 10, Advanced Video Coding”。这种情况多见于H.26x系列编码,下文会注出。

而在这条主要脉络中,基本上囊括了接近半个世纪以来,视频编码的技术发展,我们将主要沿着H.26x以及MPEG这条主要脉络,为各位读者简单梳理出一条视频编码的发展历程。

为什么我们需要对视频进行压缩编码?

很简单,就是为了减小视频占用的容量大小。

数字视频实质上就是一帧帧连续的图像,虽然一帧图像的大小并不大,但每秒至少得有24帧图像(一般情况),它们累计起来就会占据非常大的空间,我们没有那么多的地方存储原始数据,那么只有一条路可以走,对它进行压缩。而视频的编码过程就是这个压缩过程,但与音频一样,在传统数据压缩算法来看视频文件里面基本上是没有什么冗余信息的,所以人们就有必要去开发针对视频的压缩算法,把实际存在的冗余信息给去掉,从而减少它的数据量,达到减小占用容量的目的。因此,目前的视频编码基本上都是有损的,意味着编码过后的视频在画面质量上会有损失。

前蓝光时代的视频编码发展之路

让我们首先沿着国际标准,按时间顺序来看看视频编码是怎么一步一步“现代化”的。

在模拟电视和胶片电影时代,我们看到的内容都是模拟信号还原出来的。但随着人们的需求不断提高,和计算机、网络的蓬勃发展,我们需要新的、能够承载视频内容的数字编码,用来支持视频内容在互联网上的传输,或是将其存储在数字化的存储设备中。

在上世纪七十年代末八十年代初的时候,人们已经研究出了不少新的针对图像等多媒体内容的压缩算法,此时开发数字视频编码的条件已经基本成熟,而第一个开发出实际编码的,就是后来在数字视频编码领域中起领头作用的视频编码专家组(Video Coding Experts Group),他们是当时名字还是“国际电报和电话咨询委员会(CCITT)”的ITU-T(国际电信联盟电信标准化部门)组织下面的专家组。这个编码被命名为H.120,它诞生于1984年,是一种偏向于实验性质的早期编码,主要基于差分PCM编码,用来保存电视内容,但是它并没有大规模的实际运用。

H.261:引入各种特性,奠定现代视频编码基础

在制定完H.120过后几年,VCEG并没有停止他们在视频编码上面的研究。此时很多跨国公司已经使用网络进行视频会议的需求了,在互联网带宽尚不充裕的年代里,人们需要新的视频编码来实现流畅而优质的实时视频通信,H.261就应运而生了。

H.261与首个数字视频编码标准H.120并没有直接的继承关系,它可以说是完全另起炉灶的一种编码。在针对图像的压缩算法上,H.261使用了我们现在比较熟悉的离散余弦变换(DCT)算法, 它在后来的JPEG编码中起主要作用。但不止于此,它引入了一系列针对视频的特性,奠定了现代视频编码的基础,其中主要有宏块(Macroblock)和基于宏块的运动补偿(Motion Compensation)。

宏块与基于运动补偿的帧间预测

我们知道,视频是由一帧一帧的图像组成的组合,一般情况下一秒钟的视频中会包含24、25、30、60或更多张图片,它们按照一定的时间间隔播放出来,基于视觉残留原理形成了流畅、会动的画面。在连续的几帧之间,实际上存在着大量重复的画面,比如说下面这个例子:

一个白色台球在绿色桌面上面运动


用小球运动的方向和距离来描述图像的变化

如果是以传统的思路对每一帧图像做压缩的话,显然整个视频在压缩过后仍存在大量的冗余。那么怎么办呢?H.261标准引入了宏块的思维,它将整个画面切分为许多小块,然后再引入基于运动补偿的帧间预测——画面的大部分都是不动的,那么我们将不动部分的区块沿用之前的压缩结果,动的部分用运动方向加距离这样一个矢量来描述不就可以节省出大量的存储空间了吗?

DCT算法

将8x8个像素分成一个块

DCT算法起源于上世纪70年代,到了80年代中后期,有研究者开始将其用于图像压缩。这种算法可以将图像从空间域转换到频率域,然后做量化——减少人眼敏感程度较低的高频信息,保留绝大部分低频信息,从而减少图像的体积。最后再用高效的数据编码方式将处理过后的数据进一步压缩,这里使用了Zig-Zag扫描和可变长编码。

注:图像的高频部分存有很多细节信息,而低频部分则存有轮廓等覆盖范围较大的信息。

亮度通道做DCT变换后的图像,可以看到上方颜色连续部分非常平坦,而下方则拥有诸多细节

在H.261及之后基于H.261框架的视频编码中,DCT算法主要针对的是关键帧的压缩,所谓关键帧,就是在运动补偿中作为基准参考的一帧。打个比方,就像Flash动画中的关键帧一样,它定义了一个起点,后续的几帧都是基于这个关键帧演算出来的。因为它只做帧内压缩,不涉及其他帧,又被称为Intra-frame(帧内编码帧),简称I帧。

小结:创立混合编码框架,有里程碑意义

H.261设计的目标是编码出比特率在64~2048kbps范围内的视频,以用于实时的视频电话等应用。它首次确立了帧内预测与帧间预测同时使用的编码框架,在消除每一帧本身存有的冗余外,消除了帧与帧之间的冗余信息,从而大幅度降低了码率,成为了实际可用性相当高的一种视频编码。而它的编码框架也影响到了之后几乎所有的视频编码,尤其是H.26x和MPEG家族。

需要说明的是,H.261只是规定了该如何解码,只需要编码器最终产生的视频流可以被所有H.261解码器顺利解码即可。至于你前面怎么编码的,具体用的算法如何不同都没有关系,这点适用于之后几乎所有的视频编码。

MPEG-1 Part 2:引入帧类型概念,成为VCD标准

几乎在H.261开发的同时间,1988年,ISO和IEC两大国际标准化组织建立了MPEG(动态图像专家组,Moving Picture Experts Group)以开发国际标准化的音视频压缩编码。他们在1992年11月份完成了MPEG-1整套标准的制定,其中的第二部分标准化了一个新的视频压缩编码,它受到H.261的深刻影响,继承和发展了分块、运动补偿、DCT算法等思想,并做出了自己的改进,比如引入新的双向预测帧、亚像素精度的运动补偿等新技术。

引入双向预测帧(B帧)

H.261引入基于运动补偿的帧间预测算法之后,视频中的帧其实就已经分成两类了,一类是完整的,称为关键帧(Intra-frame),它就是一张完整的静态图像,可以直接被解码出来。另外的帧则是通过运动补偿算法在关键帧之上计算得到的。

MPEG-1 Part 2引入了帧类别的概念,原来的关键帧被称为“I帧”,基于帧间预测计算得到的帧为P帧。在这两种H.261已有的帧类型外,它引入了一种新的帧:双向预测帧,也叫作B帧。

原本的P帧只能够前向预测,也就是说,它只能够基于前一帧计算得到。双向预测,顾名思义,它可以用前面的一帧作为自己的参考,也可以用后面那帧来进行预测。由于参考了更多的信息,B帧自身就可以包含更少的信息量,其压缩比自然就要比只能做单向预测的P帧还要高了。但是,B帧的引入带来了一个新的问题,即编解码难度上升了。

引入帧序列(Group of Pictures)

帧序列是一些按顺序排列的图像帧的组合,简称为GOP。一个GOP的头部是一个I帧,也只会有一个I帧,它包含了该GOP的基准参考图像信息,其后是数个P帧、B帧,它们都是以开头的I帧为基础,经过计算得到的。

上面的图片就描述了一个完整的GOP,可以看到一个I和P帧之间隔了三个B帧。实际应用中,B帧确实是数量最多的帧类型。

亚像素精度的运动补偿

H.261中引入的帧间预测精度为像素级的,对很多分块的运动瞄准是不精确的,这点在MPEG-1上得到了有效改进。他们引入了亚像素级别的运动补偿,可以以1/2像素级别描述像素块的运动。

小结:成功接棒

MPEG-1成功地继承了H.261的技术框架,并对其进行了有效的补充,从而达成了不错的压缩比。在那个人们普遍还在用VHS录像带的年代里,MPEG-1已经能够以1~2Mbps的码率提供类似于VHS录像带的画质了。这也使得它被选用为VCD的标准,在世界范围,尤其是在我国风行十余年。

不过MPEG-1主要面向低码率应用,但实际上它在高码率下的表现也不差,于是,MPEG很快推出了它的升级版本,也就是MPEG-2。

MPEG-2 Part 2/H.262:DVD与(前)数字电视标准

1994年推出的MPEG-2中标准化了一种新的视频编码,它在1995年被ITU-T接纳为H.262,在这里我们简单称它为MPEG-2。相对于1993年推出的MPEG-1,它并没有太大的改动,主要是针对DVD应用和数字时代进行了改良。

支持隔行扫描

隔行扫描放在今天也并不是过时的概念,在九十年代初期,这种扫描方式有效降低了视频传输所需的数据带宽。平常我们看到的视频画面大部分都是逐行扫描(Progressive scan)的,比如说视频的垂直分辨率为1080像素,那么每帧画面的垂直分辨率就是1080像素。

而隔行扫描,顾名思义就是隔一行扫一次,它将每一帧画面拆分成两个场,每个场保留原有帧一半的信息。这种扫描方式在保证画面流畅度的同时降低了对传输带宽的需求,被各国的电视广播系统采纳使用。MPEG-2在制定时充分考虑到了数字电视系统的需求,加入了对隔行扫描的支持。

面向高码率和标清、高清晰度

从上世纪90年代开始,数字电视系统逐渐开始普及,它带来了更大的传输带宽。同时,DVD标准也快要尘埃落定,它提供了比CD大几倍的容量,能够承载更为清晰的画面。因此,MPEG-2提升了自己的目标码率范围,从MPEG-1时代的12Mbps实际豪爽地倍增到610Mbps,甚至在高清时代,它能够用20Mbps左右的码率传输高清画面。

小结:曾经最为通用的视频编码

MPEG-2虽然没有加入太多新的特性,在压缩率方面实际没有太大的提升,但由于它被选中成为DVD-Video、数字电视、DV等等一系列应用的标准编码,顺利地成为了世界范围内通行的视频编码格式,时至今日,它仍然被大量地应用在数字电视等系统中。

H.263:FLV与3GP的好搭档

原先的H.261和MPEG-1都是偏向于低码率应用的,随着互联网和通讯技术的飞速发展,人们对网络视频的需求在提高,在低码率下追求更高质量的视频成为了新的目标,而作为通信业的一大标准制定者,ITU-T在1995年推出了H.261的直接继承者——H.263。

H.263有多个版本,在1995年推出的初版中,它主要引入了在MPEG-1上开始应用的亚像素精度运动补偿,同样支持到1/2像素的精度。另外它改进了使用的DCT算法,加入了新的运动向量中值预测法,在编码效率上相比H.261有较为明显的提升。

需要注意的是,以上特性仅仅是它的基础部分,只需要实现这些新东西就算是支持H.263了,但它还给出了一系列额外的、用于增强压缩率的特性,比如说,在MPEG-1中新增的B帧,到了H.263中成了额外的PB帧。

H.263是一个被不断升级的编码,在初版之后还存在H.263+和H.263++两个官方升级版。在H.263+中,它着重提升了压缩率,相对初版有15~25%的总体提升。同时在2001年的修订中,它还引入了“Profile”的概念,将各种特性分成几个级别,完整支持某一级别的特性即为支持此Profile,比如说,初版H.263的基础部分是它的“Baseline”Profile。

H.263在互联网和通信业中得到了广泛的应用,它一度活跃在各种视频网站上面,和Flash播放器一起撑起了互联网在线视频的一片天,而在通信业中,被3GPP组织采纳成为多种通信标准中的标准视频编码,比如说MMS——也就是彩信。

另外它还被MPEG组织参考,作为MPEG-4 Part 2的基础。

MPEG-4 Part 2:特性很多,实现很多

在MPEG-2之后,MPEG组织有了新的目标——开发一套压缩率更高的编码框架,但同时保留对低复杂性的支持。1998年,MPEG-4标准正式诞生,其中第二部分定义了一套新的视觉编码体系,是的,它并不是仅仅针对于视频应用,而是广泛意义上的视觉(Visual),故也被称为MPEG-4 “Visual”。

它的核心设计实际上与H.263趋同,但是包含了更多关于编码效率的增强。它定义了复杂度不同的多种Profile,从最基本的Simple Profile到非常复杂的Simple Studio Profile,前者不支持B帧,而后者甚至支持到4K分辨率和12-bit、4:4:4采样的编码。

尽管MPEG-4 Visual是一个野心勃勃的编码,但它遭到了业界的冷待和批评。一个是它的压缩率相比起MPEG-2并没有重大提升,而因为授权和专利费用问题,很多厂商选择自己去实现一套兼容MP EG-4 Visual的编码,而不是直接采用标准,这其中就有经典的DivX和Xvid两兄弟,微软也拿它作为Windows Media Video的基础,一点点升级到WMV9。

其他编码

时间已经来到二十一世纪,高清视频和高清电视开始普及,新的应用带来了更高的需求,迫使业界开始研究新的更高效的视频编码,我们熟知的AVC即将登场,不过在介绍它之前,我们先来看看其他几个有较多应用的视频编码。

MJPEG

JPEG想必大家都很熟悉,这个MJPEG跟JPEG之间有着千丝万缕的关系。视频不是一帧一帧的吗?那每一帧都用JPEG进行压缩,然后组合起来不就行了吗?是的,MJPEG就是一个JPEG图像组合,每一帧包含了完整的图像信息,正因为如此,它的压缩率并不高,但是实现起来简单的特点让很多数码相机厂商将它作为相机的视频编码,实际上它得到了相当广泛的利用。

RealMedia

对于国人来说,RealMedia绝对是一个带有情怀的词语。他们家的RM系列编码在十多年前在国内网络上曾有相当的覆盖度。实际上它的实现基本上都是参考同时期的国际标准而来的,比如说清晰度和压缩比都很高,压过同时期DivX一头的rv40是参考了H.264而形成的。

RM最大的问题还是支持范围不广,在浏览器中播放RM需要插件,基于Flash播放器的视频网站的兴起也让它的用途逐渐变得狭隘,最终在正版H.264的冲击下,RM慢慢的销声匿迹了。

WMV

微软有自己的客厅梦想,除了Xbox以外,他们想让PC走进客厅,当然这都与Windows Media Video无关。微软基于MPEG-4 Part 2创造出了一系列新的编码,起初它们都被称为Microsoft MPEG-4或是Microsoft ISO MPEG-4,但很快,微软将其归入了Windows Media家族,首个版本是WMV7。

接下来微软在WMV7的基础上面不断加入自家的东西,使得它能够适应更高分辨率的视频,最后,他们在WMV9中加入了新的Profile,产生了新的VC-1编码。

蓝光时代标准之争

在DVD普及之后,高清视频的时代很快就到来了。人们很快发现,就算是双层DVD,其容量对1080p视频来说,也是完全不够用的。很快,大公司开发出了两种新的以蓝光为激光束的光盘,一种是以DVD论坛为首开发的HD DVD,另一种是Sony牵头另起炉灶的Blu-ray。两种光盘格式的战争我们按下不表,这里要讲的是,伴随着新光盘制式一起出现的全新视频编码标准——VC-1和H.264。

AVC/H.264:集大成者一统江湖

HD DVD和Blu-ray的标准里一共支持了三种视频编码,其一是古老的MPEG-2,其二是微软主推的VC-1,最后一种就是全新的AVC。别看它的名字很简单,其实它大有来头,是MPEG和ITU-T两个组织联合推出的新一代国际标准,在MPEG那儿被规范为MPEG-4 Part 10 Advanced Video Codec,在ITU-R那儿它又被标准化为H.264。

对于H.264这个名字,我想大家应该都不会耳熟。但就是这个现在我们每天都能够接触到的视频编码格式,曾在十多年前引发了一场软解危机,将当时很多主流CPU挑落马下,也使得ANI三家都在自己的产品中加入了辅助解码的硬件加速单元,不过这与我们的主题没什么关系,暂且按下不表。这里要讲的,还是H.264的厉害之处,究竟它用了什么手段能够在编码质量上面实现飞跃,从而独占市场十余年时间还没呈现衰退迹象。

总结下来主要有如下的几点:更灵活的宏块划分方法、数量更多的参考帧、更先进的帧内预测和压缩比更高的数据压缩算法。

更灵活的宏块划分方法

之前的标准中,宏块的划分方法是固定的,以16x16个像素为一个宏块。不过在新时代,这种粗放的划分方法不够灵活,于是H.264同时允许16x8、8x16、8x8、8x4、4x8和4x4这些精细度更高的划分方式。同时H.264将亚像素精度的运动补偿描述从1/2像素精度细化到了1/4的程度。这样一来,在帧间预测中新的编码拥有更高的精准度,但实际的数据量并不会增加太多,提高了压缩率。

数量更多的参考帧

在以前的标准中,每个B或P帧可参考的帧数是有限且数量过少的,H.264一举将限制放松到了16帧的程度,在大部分应用场景中,每帧的可参考帧数量至少都有4~5个,而在之前的标准中,P帧仅能参考1帧,B帧则是2。这一特性可以提高大多数场景的画面质量,或是降低体积。

更先进的帧内压缩

每个宏块包含的预测模式信息

对于I帧,H.264也引入了新的压缩方式。一般来说,对于图像中的某一像素点,它与附近相邻的像素的颜色是差距不大的,所以我们就可以利用这个特性进一步缩小单帧图像的大小,怎么利用呢?H.264将单个宏块内的像素颜色变化规律规范成了公式,编码时只要写此处应用哪个公式就行了。当然这里我表述的较为简单,完整的帧内预测还是非常复杂的,H.264对4x4的宏块规定了9种预测模式,对16x16的亮度平面宏块规定了4种可用模式。大大减少了单帧图像的数据量,同时保持了很高的图像质量。

差分图像加上预测信息可以还原出原始图像

CABAC

在编码的最后阶段,对数据进行无损压缩时,H.264除了支持在H.261中就存在的VLC编码外,新增加了两种无损数据压缩编码,一种是VLC的升级版——CAVLC,另一种是复杂程度更高的CABAC(前文参考之适应性二元算术编码,Context-based Adaptive Binary Arithmetic Coding)。

CABAC也是一种熵编码,主要原理也是用长编码替换掉出现频率少的数据,而用短编码替换出现频率高的数据,但它引入了更多统计学优化,并且具有动态适应能力。虽然在解码时需要更多计算,但它能够比CAVLC节省更多的数据量,通常能有10%。

小结:巨大的改变带来的是巨大的成功

除了以上介绍的几点外,H.264还有非常多的新特性,与MPEG-4 Visual不同的是,这些新特性有效地帮助H.264在节省容量方面取得了重大进展。这里我举一个有强烈对比的例子,DVD Video标准的视频,采用的是MPEG-2编码,码率约在9Mbps左右,但它的分辨率仅为720x480,而且在某些场景下我们可以很明显看到有损压缩产生的破坏;而同样的码率,放在H.264上面,已经可以承载起1080p的视频,并且拥有良好的质量。

除了在编码效率上有重大提升外,H.264针对网络传输的特性对编码组织方式进行了优化,让它更能够抗丢包,抗干扰。在种种手段之下,它成为了近十年来统治视频领域的编码,并且可以说它已经成为了HTML 5中的事实标准,现在你很难看到一件不支持H.264编码的设备,从手机到摄像机,从流视频到蓝光光盘,它的应用范围广,效能强,即使在新编码已经出现的当下,它仍然有很强的生命力和不可替代性,可以预见的是,H.264将在未来一段时间内继续统治视频编码领域。

VC-1:失败的挑战者

进入高清时代后,微软也顺应潮流,为WMV9进行了升级,加入了针对高清视频的新特性,让它能够胜任1080p级别的高清视频,新的编码即为VC-1。与H.264相比,VC-1总体的复杂程度要低一些,也因此在软解上对CPU更加友好。实际上VC-1也通过了国际组织SMPTE的标准化。

VC-1与HD DVD有一定的捆绑关系,在蓝光大战初期也通过这种方式得到了一定的推广。然而,随着HD DVD阵营的认输,VC-1也随之销声匿迹,很难再看到了。

UHD与流媒体时代,新的编码兴起

H.264很强大,但是它在超清时代有点不够用了。随着视频分辨率的跨越式提升,H.264表现出了疲态,它在应对4K视频时已经没有办法提供很好的压缩比了。很明显,人们需要新的编码来继承它的位置,而它的直接继承者——HEVC,在经过多年研究之后,终于在2013年被通过了。

HEVC/H.265/MPEG-H Part 2:视频编码王位继任者

HEVC,全称高效视频编码(High Efficiency Video Coding),同样的,它也是由MPEG和ITU-T联合制定的国际标准编码。被包含在MPEG-H规范中,是为第二部分(Part 2),在ITU-T那儿,它是H.26x家族的新成员,为H.265。

HEVC主要是针对高清及超清分辨率视频而开发的,相比起前代AVC,它在低码率时拥有更好的画质表现,同时在面对高分辨率视频时,也能提供超高的压缩比,帮助4K视频塞入蓝光光盘。

代替宏块的编码树单元

HEVC引入了新的编码树单元(Coding Tree Units)概念,取代掉了存在于视频编码中多年的宏块概念,它的单块面积大了许多,达到了64x64,但仍然保留了可变大小和可分割特性,最小单元为16x16。单个编码树中包含了小的编码单元,它们可以由四分树形式呈现,并很快地可以确定下其中的单元是否可被再分割,内部编码单元最小可以被分割为8x8大小,精细程度仍然是非常高的。

单个编码单元也可以继续被切割、分类,可以成为预测单元(Prediction Units),后者可以指示该单元的预测形式,是画面内预测还是画面间预测或者甚至是根本没有变化、可以被跳过的单元;也可以成为转换单元(Transform Units),它可以做DCT转换或是量化。

编码树单元的引入让HEVC既可以用大面积单元来提高编码效率,也可在需要的时候细化,保留更精细的细节。所谓该粗略的地方就粗略,该精细的地方就精细,HEVC在它的帮助下让码流的效率更高。

更高效的DCT

既然分块的最大面积大了,那么DCT算法也需要跟上才行,HEVC将DCT算法的最大尺寸扩大到了32x32的地步,对于图像中变化较为平坦的部分,它有着更高的压缩率。

33种帧内预测方向

还记得上面写到H.264为4x4宏块引入了9种帧内预测方向吗?HEVC直接把这个数字提升到了33种,在静态图像的压制上不仅实现了更高的效率,也实现了更高的精度,这也是它成功杀入静态图像编码市场的一大利器。虽然编码难度变高了,但只要用硬件编码器就没有那么多问题。

小结:高效编码,但受困于高额专利费用

相较于AVC,HEVC在高分辨率下的编码效率又有非常大的提升,举个实例,同样一段4K视频,使用H.264编码的大小可能会比使用HEVC大出个一倍。这种巨大的进步幅度也使得Blu-ray直接用它作为标准编码,推出了UHD BD,而它在单帧图像压缩上面的改进也让它拥有胜过JPEG的能力,于是我们看到在移动端,越来越多的设备选择将其作为默认的视频、照片输出编码。

但是相比起AVC,HEVC的推广速度慢了很多,一个是它的编解码难度比H.264高了太多,但这点通过各路硬件编码器和软件优化逐渐化解掉了,目前常见的设备基本上支持HEVC的硬件编解码;第二个就是HEVC高昂的专利费用问题,它并不是一个免费的编码格式,虽然个人使用它完全没有问题,但对于想要兼容它的厂商来说,这笔高昂的专利费用足以让他们却步,尤其是崇尚自由开放的互联网市场。于是,我们看到众多厂商选择了免费开放的VPx系列编码,以及系列的后继者——AV1。

VPx系列与AV1:以免费为卖点

VPx系列编码实际上已经有很长的历史了。它的前身是On2 Technologies公司的TrueMotion系列视频编码,在开发TrueMotion VP8编码时,公司被Google收购了。在Google的介入下,VP8从原本的专有技术变成了开放技术,在BSD许可证下面进行开源。

从技术角度来说,VP8采用的技术是类似于H.264的。虽然在我们看到的宣传中,VP8拥有比H.264更佳的压缩效率,但在实际应用中,由于它在设计上有一定的瑕疵,表现并不如H.264,最终它虽然进入了Web标准,但也没见有人用它,反而是由它的帧内压缩技术提取而成的WebP受到了欢迎。

VP8的表现并不理想,Google很快就推出了它的继任者——VP9。这次,他们参考的是HEVC,设计目标同样是高分辨率下的高效编码。VP9中的一些设计是受到了HEVC的影响的,比如说同样最大为64x64的超级块(Super Block)。最终VP9达成的结果是提供了比VP8高达50%的效率提升。看起来它能够和HEVC比肩了,但是它也遇到了和VP8相似的问题,推广不开。VP9的应用范围实际也局限在Google自家的Youtube中,只能说是缺少实际应用场景。

但很快,一些厂商认识到HEVC高昂专利费用带来的弊端,他们决定创立一个开放联盟,推广开放、免费的媒体编码标准。这个联盟就是开放媒体联盟(Alliance for Open Media),创始成员有Amazon、Cisco、Google、Intel、Microsoft、Mozilla和Netflix这些我们熟悉的大公司,而后加入的还有苹果、ARM、三星、NVIDIA、AMD这些同样耳熟能详的公司。

Google将他们还在开发中的VP10贡献了出来作为联盟新编码的基础,很快,名为AV1的编码诞生了。在Facebook的测试中,它分别比VP9和H.264强上34%、46.2%,这次看上去是真的达到HEVC的级别了。

在这两年中,AV1也确实开始得到厂商们的重视,比如说最近Netflix已经确定了要使用AV1作为主力编码,而Intel也推出了开源免费的SVT-AV1编码器,充分利用自家的AVX-512指令集。但是这种联盟还是相当松散的,比如说联盟成员之一的苹果,目前对AV1根本是无动于衷,旗下设备中全部转向HEVC。

不过从Netflix决定使用AV1作为主力编码这种态度来看,AV1免费、开放的特性还是具有相当的吸引力的。但目前在硬件方面是缺乏对它的支持的,不仅是PC端没有针对AV1做硬件解码,数量更多的移动设备也没有适配,前不久刚有一款宣传是首个加入对AV1硬件解码的SoC才发布。对比起硬件支持较为齐全的HEVC,这将是AV1推广之路上的一道槛。

未来编码:VVC

目前MPEG和VCEG已经开始研究HEVC的继任者了,目前我们知道的信息是,它暂时被命名为Versatile Video Coding(多才多艺视频编码),并将会成为H.266。它是面向于未来视频的编码,将会支持从4K到16K分辨率的视频压缩,并且支持360°视频,它的目标是在HEVC的基础上将编码效能提升一倍。

未来它可能加入的新特性有:更为复杂的编码单元结构;更大、更细致的区块划分;全局帧参考;更多的帧内预测模式(目前已经有65种)……在复杂度上面,相比HEVC,VVC将会直接高出一个维度。但是国际标准目前面对着以AV1为代表的开放标准的挑战,很难说他们会不会取消掉部分特性,从而将它正式发布的时间给提前。

总结:与时俱进

显示器、电视的分辨率越来越高,网络带宽越来越大,设备对于多媒体内容的处理能力越来越强,视频编码也一直随着时代的变化而不断进步着,但是它的框架从H.261开始就未曾有过重大的变化,只不过每个新编码都在这个既定框架下利用半导体性能的成长而加入新的更为高效的算法。比起进步并不明显的音频编码,新视频编码在带宽与容量上面提供的节约效果要明显得多了,甚至更新的编码在画质表现上也更有优势。在不远的未来,10-bit色深和HDR将会普及,在根本上取代掉还是上世纪标准的SDR内容,为我们带来更为精彩的视觉体验。诸如HEVC这样的编码实际早已做好了准备,在未来,它们的应用场景甚至将突破视频领域,就以新的苹果设备为例,HEVC实际已经成为它的标准编码格式,通行于图像和视频领域中。

另外,根据最新的报告,当前互联网流量中占大头的就是视频流量,随着流媒体继续深入日常生活,用于视频传输的流量只会更大,而互联网的总体带宽并不是可以无限提升的,对于内容提供方来说,流量费用也是相当一部分开销,压缩效率更好的编码自然也会受到他们的青睐。实际上,编码不断升级这件事情是双赢的,用户和内容提供方都可以从中获利。

由于时间与作者个人能力限制,本篇文章也存在诸多的不足,但我仍然想通过对这些编码的概述让更多人了解到正确的编码知识,如果能够起到抛砖引玉的作用,让更多人对编码产生兴趣,开始自己的研究,那是最好不过的事情了。

如何在资讯大爆炸时代获得最及时最准确的新闻,以科技和游戏新闻为例

这是一个资讯大爆炸的时代,在移动互联网大潮的推动下,我们每天接触到各种资讯的渠道从电视、报纸和电脑上网等变成了从手机上面的一个个 App 中获取,哦不对,是被推送“塞入”大量的资讯,这其中有的是新闻,有的是本地实用资讯,甚至还有各路八卦消息。

这是时代的潮流,我们躲不过去。然而笔者相信机核的很多读者并不想要诸如娱乐圈八卦这样的杂七杂八的新闻,只想看游戏相关的资讯;或者是嫌弃各路媒体速度还不够快,自己想成为最快的资讯大佬;抑或者是想要绕过媒体这层中介去获取最原始的消息。那么该怎么做呢?本文就以科技、游戏新闻为例,简单介绍一种方法和三种常见的误导手段,帮助大家获得更高质量的新闻。

很大比例的新闻都是通过官方网站向外发布的

媒体的消息源头是怎么来的呢?一些是提前发送给媒体的新闻稿,这些一般人是搞不到的,因为绝大多数提前发送给媒体的新闻稿会带上 NDA,但以这种形式出现的新闻只是少数,因为也只有比较大的公司才会有较为全面的媒体覆盖。另外很大比例的新闻其实是来自于第一时间发布在公司官方网站上的新闻稿,这种做法较为通行,各行各业基本上都会采用这种做法,科技和游戏行业就更是如此了。另外,对于科技和游戏行业来说,还有一部分新闻是各种传闻(Rumor),这种不确定的消息一般是媒体(尤其是国外媒体)挖掘出来广而告之的。

FromSoftware 的新闻稿页面

所以对于我们普通网民来说,可以通过访问公司官方网站来获取最为及时最为准确的消息。不过很多公司都不会把自己发布的最新消息给挂到首页去,那该怎么找到发布新闻的地方呢?

这里教一招很简单的:利用搜索引擎,用“公司名 Press Release”、“公司名 News”这样的关键词来搜索,这招可以说是屡试不爽。当然也有像 Steam 这种把新消息全当成博文发的,这时候关键词就要换成“Blog”了:

Steam 新闻页中的 Press Releases 已经很久没更新了
近一年半新的官方消息都直接写博文了

而对于一些传言新闻来说,越是靠谱的媒体拿到的内部消息一般会更准确,此时就要选对正确的媒体,对于游戏领域的传闻来说,KotakuPolygon 这两家的爆料新闻准确度还算不错。

那么这么多网站,我总不可能每天就盯着页面刷新等新闻吧,那该怎么将这么多网站和媒体整合到一起看呢?这时候就要请出一个默默在背后奉献了很久的协议——RSS,关于它的介绍请看后文。

精准溯源,拒绝二手错误新闻

当然绝大多数人是没有时时刻刻盯着最新新闻这个必要的,而且就游戏这块来说,国内的几家游戏媒体都是比较及时的,准确性也是比较高的。但科技媒体的新闻就相对要鱼龙混杂一些,这时候就需要我们具有一定的溯源能力,绕过二手新闻。

不准确的翻译可能会带来误解

由于语言隔阂和时差,一般我们通过国内媒体看到的国外科技、游戏公司的新闻都是经过编译,或者直接就是转述的。在编译和转述过程中,很可能就会出现信息失真的现象,最终误导读者,比较常见的就是拿捏不准英文多义词、专业名词或是直接机翻导致出错,比如:

Console,一词多意,这里被错误翻译成了“控制台”

直接拿流言做新闻却不加提示

还有就是直接拿传闻、流言来做新闻,但却不在标题或内容中注明这是流言,对读者进行误导,比如下面这条来自于著名传言站 Wccftech 的 Rumor,在编译之后不仅标题中用于提醒读者的“传言”二字不见了,内文也没有相应的提醒:

到了某媒体那儿,流言提示就没了,变成肯定了

当看到这类新闻的时候,一定要小心,如果你觉得这事情不太对,那么大可稍微小花一点点时间去溯源。国内做的好的媒体都会注明消息出处,点进去稍微读一下,既可以通过原文来理清楚事情原委还能顺便锻炼一下自己的英文阅读能力。如果是没有标明出处的……非一手的新闻就直接拉黑吧。

标题党

这是笔者最为痛恨的一种现象,但不可否认的是,一个非常在我们看来可能是离谱的标题往往可以吸引到很多一般通过路人。标题党在微博、微信朋友圈非常有优势,很多人真的就只看一个标题然后就转发了,实际内容如何呢?不知道没看过没兴趣。

不点名了,都是友媒

这种现象还挺常见的,不过国内几家比较正经的游戏媒体都没有用,这是好的。现在的标题党已经没有以前那么明显了,但是仍然存在曲解文章内容、断章取义这样的情况,所以如果各位读者遇到了一个较为夸张的标题,请务必粗看一下内容以防止被标题带着走了。

定制自己想看的新闻:RSS

上文提到了一个名词,RSS。它定义了一种标准格式,网站可以依照这种标准格式将自己站里面的内容写成一个文件,方便用户抓取网站上面的内容。在 RSS 的帮助下,我们可以用相应的软件从不同的站点上面抓取整理好的内容,直接在一个地方阅读,大大提高了聚合度和效率。其实今天的诸多新闻客户端继承的就是 RSS 的聚合理念,但 RSS 的自由度要更大一些,并且内容也不局限于新闻,所以我们完全可以利用它来打造自己的“新闻客户端”。

目前各个平台上有数量繁多的 RSS 客户端,用的人比较多的有 Feedly、Inoreader 这些,笔者用 Inoreader 比较多,它的免费版基本够用,而且 App 做的挺不错的,比较符合笔者的需求。

那么哪里可以找到 RSS 呢?一般可以留意一下这个标志:

比如在 SIE 的首页,就有一个很明显的 RSS 标记,它超链接到 RSS 文件的地址上,复制这个链接,扔到 RSS 阅读器里面订阅就行了。

很多公司的官网都会提供 RSS,在浏览时可以留意一下。

一些网站也会把 RSS 通道做到页面底部去,比如机核就是

通过一段时间的积累,基本上可以拥有一个稳定的 RSS 源列表,RSS 阅读器会自动按照一定的时间间隔抓取各个订阅站点的 RSS 文件,并把更新的内容展示给你,下图就是笔者积累一段时间之后,RSS 阅读器中订阅的游戏媒体。

这样子做出来的“新闻客户端”具有明显的个人风格,并且有一点很重要的是,你可以摆脱原本各种新闻 App 的推送,看自己想看的媒体,读自己想读的新闻。

结语

网络让我们拥有了更多的信息获取渠道,有了更快的信息获取速度,但不可否认的是,我们在信息的真伪确认上面越发的陷入困境。自媒体的兴起让传统媒体的双重信源确认制度在这个时代显得滞后,但也仍然有 AnandTech 这样对流言坚守双重信源确认的老牌科技媒体,还有像机核这样能够为了新闻报道失实而诚恳道歉的媒体。我相信即使大环境再差,也一定(在新闻上)坚守自己节操的媒体。

希望本文能够起一个抛砖引玉的作用,也希望各位读者朋友在今后,尤其是目前这段特殊时期中,擦亮自己的眼睛,不被谣言所害。

音频编码变迁录

前面讲过了多媒体容器格式的变迁,这期我们来看看音频编码是如何发展的。在讲编码之前,同样地,让我们来看看现在最为通用的数字音频格式——PCM是怎么来的吧。

从音频波形到0和1

声波是一种机械波,在数字时代到来前,录音的原理其实就是将声波的波形、振幅等等特征依样画葫芦给记录到如黑胶唱片、磁带等介质上面,但是这种记录方式并不利于保存,计算机等电子设备的普及使得人们更想使用电子数据的方式来保存音频。但是用于采集声音的麦克风最终将声波转换输出的电流是一种模拟信号,它用电流的大小来表示声波,是连续的;而计算机使用的数字信号系统是一种离散的、非连续的信号系统,在常见的二进制系统中,它只有0和1两种状态,并不能够直接保存模拟信号,两者之间需要经过转换。

怎么转换呢?首先针对一段声音的音频波形,我们可以用一个较为复杂的波形函数来表示,既然它是函数,那让我们回想一下初中高中大学我们都是怎么把函数画出来的,用线把一个个点连接到一起对不对?那么现在我们反过来,在这条已经给定的函数图像上面按照一定的间隔取点,这个过程就叫做采样,取完点之后把它的值用数字给记录下来,这就叫做量化。


在音频编辑软件中将音频波形放大,你可以看到一个个取样点

这种将声波记录成数字数据的方式就叫做PCM调制,这里说的很简化,但是原理其实是一样的,就是用记录下来的点去拟合出声波函数应该有的样子,在PCM调制中,我们记录到的数据是时间与对应的电平值。而上面这两个操作就带来了**采样频率**和**量化位数**这两个关键特征。

PCM调制下的音频重要特征


一个波形函数,上面的红点代表采样点,两个红点之间的横向距离一致,距离值就是采样频率的倒数
量化要做的就是将这个红点的y值以一定的规则记录下来

采样频率

由于声波是一种连续的信号,你可以把它看成数学上面的连续函数,从一个点到下一个点之间有无数多个点,我们没有办法全部将这些时间-振幅信息100%记录下来,只能从中挑选一些,那么怎么挑选呢?以一个固定的时间间隔,到点了就记录。而采样频率指的就是每秒记录这些值的次数,用Hz作为单位。

采样频率越高,我们记录下来的原始声波信息越多,我们保存下来的数字信号自然就越贴近于原始音频信号。

量化位数

在确定了采样次数后,我们在这条声波函数上面拥有了一些间隔相同的点,我们知道,在二维函数上面的点可以用一组二维坐标值来表示,这里横轴是时间t,而纵轴一般就是电平值,因为计算机处理能力的限制,我们不可能用一个无限长的数字去记录它,只能用有限位数的数字去记录,而这个位数就是“量化位数”,它决定了数字音频信号的量化精度。

因为这种记录方式用的是近似值的方法,所以量化位数越大,我们记录下的原始模拟信号的电平值就越精确、越贴近于原始音频信号,另外量化位数越大的音频在动态范围上也要比量化位数小的音频要大。

以音频CD为标尺的无损、有损以及Hi-Res

因为数字信号系统记录下的音频信号已经经过了一次采样了,相对于原始的模拟音频信号它已经是“有损”的了,所以我们今天常说的有损无损指的是有损压缩和无损压缩(可以是无压缩)的区别。顾名思义,无损压缩指的是数据在经过压缩之后没有任何的损失,而有损压缩则相对,它在压缩过后相对于原始数据出现了损失。

而原始数据是什么呢?那就要讲到开启人类数字音频时代的CD。

CD:光、数字、音乐

在上个世纪五六十年代,人们常用的还是黑胶唱片,而随着1965年光盘的问世,这种比黑胶唱片更加小巧精致的记录载体很快受到了大公司的青睐,其中飞利浦和Sony就决定用光盘作为记录数字音频数据的载体,并为它量身定做一种数字音频记录格式,最终他们决定采用LPCM——线性PCM作为编码。

然后飞利浦和Sony这两家在CD要使用的LPCM编码具体参数,也就是采样频率和量化位数上面产生了分歧,进行了一段长时间的拉锯战。

首先因为人耳普遍只能够辨识频率在20Hz~20kHz之间的声音,而根据奈奎斯特–香农采样定理,对于一个连续信号,只要采样率高于(注意,不能等于)原信号带宽的两倍即可通过采样完美(理论上的)重建原信号,所以CD标准的采样频率先被确定到要在40kHz以上。根据这个底线,飞利浦那边提出的标准是44056Hz/14-bit,而Sony则是使用44100Hz/16-bit的标准,双方都是站在自己的利益角度,两种标准都是为保留与原本的电视、录像带系统(NTSC/PAL)的兼容性而提出的。

最终拉锯战以Sony方面的大获全胜而告终,CD音频以44.1kHz/16-bit的双声道LPCM的形式进行记录,这就是Compact Disc Digital Audio(CDDA)标准,它于1980年定稿。

回到我们上面所说的无损、有损的概念。由于CD是我们最早普及的数字音频记录系统,它也是我们普通人能够接触到的最接近原始音频的介质(先不论Hi-Res),所以大家就开始用“无损”来称呼原始的从音频CD上面保存下来的数据,当然它也可以用于无损压缩过的音频。

Hi-Res

CD标准确定之后,它逐渐变成了音乐发行使用的主要介质,但随着时代的发展,有需求的人们还是发现它不够用了,首先16-bit的量化位数限制了CD音频的动态范围,其次44.1kHz的采样频率仍然会在模拟转数字过程中产生人耳可闻的损失。所以制定一种比CD更高的标准就成为了业界的共识。

从CD诞生到现在的短短四十年中,包括它的创造者Sony和飞利浦在内,一直都有新的厂商想要以自己更新更好的编码标准取代掉CD标准,但很可惜他们的努力都没有成功,CD仍然牢牢地占据着业界。虽然没有成功,但这些努力还是引起了行业协会的重视。2014年,美国唱片业协会(RIAA)这家代表着美国唱片业的贸易团体联合了其他几个较为权威的组织一起给比CD更高的音频制式下了定义

Lossless audio capable of reproducing the full spectrum of sound from recordings which have been mastered from better than CD quality (48kHz/20-bit or higher) music sources which represent what the artists, producers and engineers originally intended.

也就是说,采样频率/量化位数在48kHz/20-bit或其上的音频都可以被称之为”High Resolution Music”,简称就是Hi-Res Music。


RIAA的Hi-Res Music Logo

其实在RIAA之前,日本的電子情報技術産業協会(JEITA)在2013年[制定](/images/https://www.jas-audio.or.jp/english/hi-res-logo-en)了一套适用于日本国内的Hi-Res标准,这套标准规定了Hi-Res音频在模拟和数字处理过程中必须参照使用的规范,其中对于数字处理过程,JEITA要求全过程的音频格式均在96kHz/24-bit及之上。


这个Logo也是我们现在能看到最多的代表Hi-Res的Logo。

而这套标准也被日本的音频器材行业带向了全球。

常用的有损音频编码

一张CD翻录下来的大小总会有个500、600MB吧,对于上个世纪90年代还在使用以几MB为单位的软盘的人们来说显然是太大了,另外网络时代早期的带宽还是非常小的,比如当年拨号上网最快也就只有56kbps的带宽,如果想将CD保存到自己电脑里,或者是通过网络跟人分享,在当时几乎是一件不可能的事情。

而有些人说那为什么不做压缩呢?因为在数据压缩软件看来,你这个CD文件的数据几乎没有冗余,传统的数据压缩方式对音频数据是起不了太大效果的,那咋办呢?只能走有损编码的道路了,这其中,MP3是比较早、也是人们用的最多的有损音频编码。

MP3:最常用的,不一定是最好的

MP3的全称为MPEG-1 Audio Layer III,也可以是MPEG-2 Audio Layer III,它是在1993年被标准化的,至今已经有26年的历史了。别看它的岁数大,但它应用的音频压缩思想至今仍然在音频编码领域中发挥着重要的作用。

首先,MP3使用了MDCT算法,这种算法改正了原始DCT算法上面的一些缺点,它将音频原本的时域信息转换成频域信息,是之后对不同频段信号进行处理的前提。

其次,MP3运用了声音心理学模型,这里有三点。第一,人的听觉频率范围大概在20Hz~20kHz,所以可以多去掉一些高频声音;第二,人耳对于不同频率声音的敏感程度不同,大概在2000Hz~5000Hz之间是最灵敏的,而在两端下降的比较厉害,尤其是高频;第三,人耳听声音有遮蔽效应,一个较强的声音会遮蔽掉较弱的声音,比如说手机开同样的音量在闹市中和在自己房中听起来完全是两码事,另外不同频率声音的遮蔽宽度不同。根据以上三点,MP3编码器就可以对不同频段的音频信号进行取舍,给人耳比较敏感的频段多保留一些细节,而去掉人耳不敏感甚至会听不见的一些声音。

最后,MP3运用了哈夫曼算法来对处理过后的音频数据进行压缩,并且编码器会不断地对前面的处理进行调整,以达到用户给出的码率、质量需求。

由于以上三个大的特点还有别的没有提到的原因,MP3在压缩之后仍然拥有相当高的质量,而压缩比一点都不差,大概在1:4~1:6之间,最高可能有个1:10。因此这个已经有26年历史的编码标准时至今日仍未过时,大量在网络上进行传播的音频仍然使用着它,但它并不是没有缺点。

一是它太狠了,对于20kHz以上的声音几乎就是一刀切,比如下面这张图就是一段320kbps CBR编码的MP3音频频谱图,可以看到20kHz上面完全消失了,这种情况主要出现在CBR编码的MP3上面。


使用CBR 320kbps参数进行编码,可以看到编码后的音频频率上限就是20kHz

当然你也可以强行关闭编码器的一刀切行为。


这是开启使用最高品质VBR编码的MP3频谱,可以看到20kHz以上是完整的

一刀切虽然可以大幅减少音频文件的体积,但在实际听感上总会感觉缺了什么。

第二个缺点,其实也不能算是MP3编码自身的缺点而是它使用的标签有问题。肯定有用户在下载网上的MP3资源时遇到过乱码问题,比如:

这是因为MP3文件使用的ID3标签最初没有统一的文本编码,各种语言的系统会以自己当前使用的文本编码标准往里面写数据,导致使用其他文本编码标准的系统无法正确读取文本数据,最终出现乱码。比如图上这个MP3的信息就是日文系统用Shift-JIS文本编码写入的,而我们平时使用的简体中文Windows的文本编码标准是GBK,无法正确读取,所以出现了乱码。ID3标签在之后的v2版本中改进了这一点。

第三个问题是MP3对于多声道的支持较差,常用的MPEG-1 Audio Layer III标准只支持双声道音频,而非主流的MPEG-2 Audio Layer III才支持最高5.1声道,但是它最高只能够支持采样率为24kHz的音频,完全不够用。

其他的缺点可能算不上什么大问题,不然它也不会被用到今天仍然是主流了。

AAC:先进、优秀,但是没能取代MP3

AAC名叫进阶音频编码(Advanced Audio Coding),它本来是开发出来取代MP3的。联合起来开发它的公司有一大堆,个个都是知名大企业或研究机构,比如索尼、微软、杜比实验室、贝尔实验室,等等等等。最终,AAC被MPEG组织接受,写进了他们的MPEG-2和MPEG-4标准中。

相对于MP3,AAC使用了完整的MDCT算法,因此在编码效率上它更胜一筹,一般在同等码率下,AAC的质量比MP3更好一些。而其他的改进点还有支持更大范围的采样率(16~48kHz=>8~96kHz),最多支持高达48个声道,在对频率高于16kHz的音频处理上明显要好等。总之,作为设计目的是取代MP3的编码,它的特性非常优秀,然而,AAC没有如愿以偿的成功取代掉MP3,究其原因可能还是推广力度不够大。另外,尽管用户无需为使用AAC格式进行流式传输或分发而付费,但硬件制造商和软件开发者需要交这笔钱,专利费用也使得在AAC标准确定之初,普通用户手上根本没有能用的AAC编码器,而在这时候,MP3和著名的LAME编码器已经满天下都是了。

实际上我们现在的日常生活中AAC可以说是无处不在的,在线视频的“业界规范”就是以它作为音频编码标准,所以你随便点开一个在线视频,基本上就会听到用AAC编码的音频。另外一个主力推广AAC的公司就是苹果,早在iTunes商店建立之初,他们就使用AAC作为这个数字音乐商店的音频编码标准了,一直到今天都是,包括在前几年推出的Apple Music流媒体服务。

AAC使用两种容器,一般我们见到的都是以.m4a为扩展名的文件,其实就是mp4。而因为使用mp4容器,文件的元数据使用UTF-8编码保存,所以不会出现如MP3那样的乱码。另一种容器现在比较少见,直接以.aac为扩展名,实际上是一种名为ADTS的容器。

除了以上的特性之外,AAC的编码还是可以模块化定制的,在MPEG-2 Part 7中就已经给出了三种模块化编码方式,而到了更加现代化的MPEG-4 Part 3规范中,更是给出了多达11种模块化配置规范,其中不乏有低延迟模式和高效模式(HE-AAC),下面就简单提一下AAC-LC和HE-AAC。

AAC-LC与HE-AAC

AAC-LC,或者叫低复杂度(Low Complexity)AAC,你可以将它看成是原版的AAC编码,它的编码规范写在MPEG-2 Part 7中,在MPEG-4 Part 3中就直接叫做AAC Profile,而HE-AAC全称High-Efficiency AAC,直译就是高效AAC,它的编码规范写在MPEG-4 Part 3中。主要区别是HE-AAC利用了一些新特性,在编码效率上有明显的提高,特别是在低码率情况下。

简单的关系图如上,可以看到HE-AAC包含了很多新特性,这些新特性帮助它实现了更高的压缩比。

WMA:规格很先进,但它是微软的东西

早个十五年,我们在百度上搜索音乐下载的时候,除了MP3,见得最多的一种格式应该就是WMA了,看到开头的WM两个字母就能明白,这是微软的格式。没错,这是“鼎盛”时期的微软开发并强力推广的专有编码,多见于Windows平台。微软最初开发出它的目的很简单,就是为了和MP3和RealAudio竞争,结果大家都知道了,MP3活到了今天,而WMA和RealAudio都已经消逝在历史长河中了。

WMA全称Windows Media Audio,它同样使用了音频心理学对原始音频进行处理,去除人耳不敏感的声音来减小数据体积,思路与MP3大同小异,不过具体实现上面有差异。WMA是与Windows Media紧紧捆绑的一种音频编码格式,不过微软将编解码开放给了第三方,交钱就可以用,所以在十多年前的MP3播放器上我们也可以播放WMA格式的音频。WMA与Windows Media一起升级,它还有个增强版,就是WMA Pro。我们比较熟悉的可能是Windows XP SP2自带的那个Windows Media Player 9.0,实际上在这个版本中,微软还为WMA引入了无损编码,称为WMA Lossless。


Windows 10还带着Windows Media Player,但还有人用吗?

但是随着微软在多媒体格式竞争中的全面失败,Windows Media也不再更新了,WMA也就慢慢的不再流行了。

Dolby Digital(AC-3)与DTS:电影工业的常客

VCD上面用的MP1音频编码效果太差了,还不支持多声道,但这也是因为CD的容量不够大,而从DVD开始,人们终于有机会在自己家里听到影院级别的音效了,因为它的容量足以直接收录电影使用的Dolby Digital或者DTS音频。那么这两种音频是什么呢?先来说Dolby Digital,我们可能更熟知它的另一个名字:AC-3。

Dolby Digital(AC-3)

Dolby实验室是美国一家专注于音频效果、音频编解码领域的公司,原本在模拟时代,它发明的一系列音频编码已经被好莱坞广泛使用,人们在电影院里面最常听到的就是用Dolby技术编码而成的声音。而到了数字时代,他们也紧跟潮流,于1991年推出了Dolby Digital这种数字音频编码。

Dolby Digital的开创性在于它是首个使用MDCT算法进行压缩的编码,同时他们还使用了音频心理学的研究成果对压缩算法进行优化,使得最终压缩后的产物仍然拥有影院级别的效果,但是DD只支持固定码率编码,这使得它的码率一般都会比较高,所以压缩过后的音频体积也较大。常见的DD编码一般有6个声道,称为DD 5.1,而在很多DVD上面我们经常可以看到它的Logo。DD音频的另外一个特点是它的元数据中带有对解码过程进行控制的相关信息,使得它在支持的播放器上可以还原出制片方想要的效果。

随后DD又发展出了很多新分支,其中比较有名的是Dolby Digital Live,它随着另一家老牌音频硬件公司——创新——进入了千家万户。而DD也有自己的后继者——Dolby Digital Plus,我们可能更熟悉它的另一个名字——E-AC-3,它在DD的基础上提升了比特率和声道数量,我们经常可以在下载版的美剧中见到这种编码。

DTS

在电影音频领域中,另一家影响力很广,技术力很强的公司就是DTS了,DVD时代我们经常见到的就是他们以公司名命名的音频编码格式DTS,这种编码推出于1993年,直接竞争对手就是Dolby实验室的产品。

与Dolby Digital选择使用MDCT算法不同的是,DTS选择了ADPCM作为算法基础,这种算法是PCM的变种,与PCM使用固定量化位数记录电平值不同的是,ADPCM有自适应的特征,在音频电平差值较小时用较少的量化位数去记录,而差值大的时候用更多的量化位数进行记录,这样对于存储空间的利用率就更高了,相对于用MDCT算法算出不同的频率段再砍掉人耳不敏感部分的做法,基于ADPCM算法的编码虽然压缩率要低一些,但是对于声音细节的保留肯定是它要做的更好。当然,这就使得它的体积控制比DD要差一些,所以在一般的DVD上,我们更常见到的是DD而不是DTS。


好莱坞电影真的是以Dobly编码居多的

Dolby实验室与DTS的竞争从这时候的DD与DTS开始,一直延续到今天的Dolby TrueHD VS. DTS-HD Master Audio,后面两个都已经是无损编码了,我们放到下面去讲。

Vorbis与Opus:多见于语音编码

说Vorbis这个名字可能大家都不知道是啥,但是一说Ogg那肯定都会“啊我知道”了。其实Ogg是Vorbis编码的音频常用的一种容器,而Vorbis编码则是在2000年公布的一种计划取代所有有损音频压缩的编码,对,它的野心极大。

Vorbis编码的原理与其他有损编码相比也是大同小异,基于MDCT的时频转换,然后过心理声学进行频段舍弃,不过之后的处理有些不同,它使用矢量量化算法,在低码率情况下有着很好的表现,接近于HE-AAC,但没能完成超越。前面也说了,直到今天MP3也仍然稳坐着音频领域第一编码的位置,所以很明显Vorbis没有完成自己的计划。

之后它的主要开发者Xiph.Org基金会又推出了一种新的编码——Opus,这种编码有着比Vorbis更好的低码率表现,在同码率下终于实现了对HE-AAC的超越。而它还有一个低时延的特性,可以做到目前最低的编码延迟,这也使得它在数字语音通信领域中大放异彩,它现在也是IETF标准中的一员。

常见的无损音频编码

在自己的硬盘空间逐渐大到放CD原盘都没有问题了之后,新的问题出现了,网速跟不上。回想一下05年左右,国内家庭普遍还是在用ADSL上网,速率可能也就只有1~2Mbps,用这个速度下点MP3还行,但是下原盘就太慢了,但很多音乐爱好者就是想收藏“没有瑕疵”的无损音频,怎么办呢?这时无损音频压缩编码走上了舞台,首先登场的是Monkey’s Audio,又叫APE。

APE:无损音频压缩的先行者

APE是Monkey’s Audio这个编码使用的扩展名,但是叫得多了大家都只知道APE而不知道Monkey’s Audio了。它是可考的、比较早出现的一种无损音频编码,后面要提到的WavPack(.wv)比它出现的还要早,但是APE却是头一个大范围流行起来的无损音频编码,最初版本公开于2000年。

问题来了,前面不是说对传统压缩方式对于音频数据并不能起到很好的效果吗?那APE是怎么在无损的情况下实现如此高的压缩率的?答案也很简单,传统方式不行,那我就用新的针对性算法呗。

APE主要使用了三大算法来实现对原始音频数据的无损压缩,第一个是Joint Coding,简单说就是将左右两个声道的共同信息进行复用,从而减小音频体积;第二个是线性预测编码(Linear Predictive Coding),因为音频信号前后关联性非常大,可以根据前面一段音频波形预测后面的音频波形,如果预测得到的值与真实值有差距,则对差值进行编码,这种算法是音频无损编码的核心杀手级算法,可以做到在没有损失的情况下大幅提升压缩比;第三个就是预测编码所需要的量化位数。

这三种主要算法使得APE可以在没有损失的情况下达到约50%的压缩比,这是之前的无损音频编码做不到的事情。

但是APE也有较大的缺陷,最高只支持双声道、24-bit的量化位数让它在新世代落后于FLAC,因为存在浮点计算,所以对硬件性能的需求要高于FLAC,在编解码上面也更慢,而它也没有针对数据完整性做

另外由于APE虽然标了自由软件,但是它使用的许可证并不能让人们直接使用Monkey’s Audio现成的源代码,必须自行动手去实现对它的解码支持,这也限制了它的应用范围。

FLAC:免费开放,新的业界事实标准

FLAC基本上是与APE同时间提出来的,稍微晚了那么一丢丢,它直接将编码的最大特点写在自己的名字里了——Free Lossless Audio Codec,自由、无损。

相对于APE,虽然同样使用了线性预测算法,但它的压缩比稍微差了一点,不过由于FLAC使用全整数的数据计算方式,所以低端电子设备也可轻松对其进行解码,而它在数据结构上考虑到了数据完整性和流传输,它采用帧结构设计确保了即使文件的部分片段遭遇不测,其他部分也能够正常播放,而支持流传输的特性使得它在可以在流媒体时代占据一席之地。并且它对于多声道的支持比APE强很多,最高可以支持8声道。

FLAC身上的种种优点使得它成为了目前最为流行的无损音频压缩编码,Android早就添加了对于FLAC的支持,而iOS也在第11个大版本中放下自己的矜持加入了对它的支持。FLAC已经俨然成为了新的业界通用编码,各大Hi-Res音乐售卖网站也在使用FLAC作为载体传播Hi-Res及普通无损音乐。

Apple Lossless(ALAC)

macOS作为很多音频编辑软件使用的系统环境,对于音频编码自然也是有着很高的要求,其实苹果自己也很早就跟进了无损音频的发展,在2004年的时候他们就推出了自己的无损音频压缩编码——Apple Lossless,但是当时这种格式只有苹果自家的系统和软件才能支持,并且会收取授权费用,这也导致了ALAC错过了无损音频开始发展的萌芽期,直到2011年,FLAC已经成为市场主流的情况下,苹果才将ALAC开放出来,并且取消了它的专利费用。

ALAC在编码方式上与其他几种无损音频压缩编码并没有太大的区别,同样是基于线性预测的算法,不过它的编码器连个压缩率选项都不提供,但编码速度确实挺快的。ALAC与AAC一样使用MP4作为数据容器,所以也继承了MP4良好的标签支持。

但是它的使用范围始终不广,本来就基本限定于苹果设备上,而在iOS和macOS纷纷支持FLAC之后,它的存在意义就更小了。

Dolby TrueHD与DTS-HD Master Audio:蓝光时代电影常用音频编码,新的战场

从DVD到蓝光是一次大的飞跃,光盘这种存储介质在新的蓝色激光的帮助下,大幅度提升了存储密度,也使得它可以记录体积更为庞大的音频,有了大的空间,那肯定就要上无损啊,其实蓝光的容量已经足够放7.1声道、48kHz/24-bit的LPCM了,但是它的体积还是太大,所以Dolby和DTS不约而同的在高清时代推出了新版的音频压缩编码技术,Dolby这边是以Dolby TrueHD系列为主,而DTS是以DTS-HD Master Audio为主,两边都是无损压缩技术,这边就讲的粗略一些了。

Dolby TrueHD

Dolby TrueHD使用与DVD-Audio相同的MLP编码对原始PCM音频数据进行处理,最高支持192kHz/24-bit的规格,另外还支持16个独立声道。与前任Dolby Digital一样,它也带有用于控制播放过程的元数据,提供更加还原的音频效果,Dolby后来推出的Atmos氛围声效果就是通过这些独立于音轨之外的元数据实现的。

DTS-HD Master Audio

这两种多见于蓝光原盘的音频编码都附带了对原来有损编码的兼容,DTS-HD Master Audio内建了一条有损音轨,称为DTS Core Stream,它的无损部分其实是对有损部分的一个补充,在支持的设备上自动就会播放无损的DTS-HD Master Audio,而在不支持的设备上也可以切换到DTS Core Stream,不会影响到正常的播放,而另一边的Dolby TrueHD则是通过附带一条Dolby Digital音轨的方式来解决兼容性。

DTS-HD Master Audio在日本用的比较多一些,尤其是各种动画小圆盘。

TTK,TAK,WavPack等

除了上面三个稍微多见一点的编码以外,无损音频编码界还有很多其他的编码,由于APE推出时间早、FLAC用的人多等原因,这些无损压缩编码最终都没有推广开来,成为了比较小众的编码,虽然它们可能在某些方面有着优势,但很可惜,时势造英雄,取代英雄没有这么容易。

PDM与DSD:另一种音频调制方式

说起PDM(Pulse Density Modulation 脉冲密度调制)可能没学过数字电路的同学会云里雾里,简单一点的说法就是PDM使用0和1来模拟原始波形,怎么模拟呢?通过在单位时间内0和1的堆叠来进行,因为此时0和1的密度代表了波形的振幅,所以叫做脉冲密度调制,它与PCM记录电平值的做法是完全不同的。

基于PDM调制的原理,Sony和飞利浦在1999年推出了用于取代CD的SACD(Super Audio CD),它使用的ΔΣ算法在模拟/数字转换(A/D)过程中会以64倍于CD的采样率(2.8224MHz)对原始音频进行过采样,而由于PDM的特性,量化位数当然就只有1-bit,因为只有每一个采样点都只有开或者关两种状态嘛。


PCM与DSD的对比

DSD解决了传统PCM编码上的高频量化噪声问题,高采样率同时还带来了更加丰富的声音细节,而密度调制的方式也使得它拥有更大的声音动态范围。除了原始的64倍采样率的DSD之外,后来还推出了DSD128、DSD256、DSD512等新格式,它们的采样率逐步上升。

现在我们可以拿到的DSD音频一般都是ISO镜像格式的,使用专门的解码器可以将其转换成PCM音频播放,而支持DSD直通播放的设备还是相当的贵。

SACD的物理介质其实就是DVD,同期其实还有一个DVD-Audio阵营,他们仍然使用了兼容性较好的PCM调制,不过是基于一种新的名为MLP(Meridian Lossless Packing)编码方式,在双声道情况下最高支持192kHz/24-bit的PCM音频流,直到今天,它的规格都是相当高的。

但是Hi-Fi最终也只是少数人的玩物,它的配套解码器、播放器都太贵了,而且Sony当时为了拉拢唱片发行商做出了“永远不会让PC读取SACD”的承诺(后来他们食言了)也限制了SACD的进一步推广,在面对以iPod、iTunes为代表的数字音乐浪潮时,它和DVD-Audio都只能站在一边看着眼馋,事实证明,绝大多数人们需要的是方便快捷的听歌体验,所以便于携带的各种MP3播放器很快就取代掉了CD成为了新的潮流。而后,就是流媒体取代传统MP3的又一股浪潮,我们现在就身处于这股浪潮之中。

总结

要总结的话就是,MP3和AAC这两种有二十多年历史的编码统治着有损音频编码,而FLAC基本上成为了无损音频编码的事实标准,而电影工业中Dolby和DTS仍然在竞争,目前看上去Dolby更占上风。而在开放软件领域中,Vorbis和Opus这两种开放的格式也慢慢在Web领域中得到大量应用。

其实看到最后,你会发现,本文写到的几种基于PCM调制的无损、有损音频压缩编码基本上都是基于类似的编码——有损压缩很多都是基于MDCT,而无损压缩基于线性预测编码。用烹饪打个比方,原始的PCM音频就是主要原料,你可以把MDCT和线性预测编码看成是不同的主要做法,比如MDCT是炒而LPC是蒸,其他的一些算法就像是对于主要原料的小处理方式,比如先过个水或者是先腌制一下,他们与主要做法一起左右着整道菜的口感和味道,而最终得到的菜的营养价值也根据不同的处理手段而改变。

另外,在有损压缩技术中,心理声学(Psychoacoustics)是一大助力剂,它帮助各种编码对原始音频进行取舍,在对听感影响很小的情况下大幅减少体积。而心理学也不只是在音频编码领域中起着作用,在视频和图像编码中,它同样有着重要的贡献,当然,这就是后话了。

因为各种物理极限和自然定律,数字记录方式永远不可能100%还原出现实,但是人类是不会停止研究、应用新技术的脚步的,数字世界将会越来越接近于现实。

实际上在这个网络流媒体时代,我们的需求也逐渐发生了改变,从怎么样带更多的歌变成了怎么样听得更爽,所以现在对于音频压缩技术还是有不小的需求的,一个更为高效的编码可以在节省网络带宽的同时提高人们听音乐的享受程度,而聚沙成塔,每个人那儿节省一点点的带宽最终聚合起来就可以节省巨大的带宽费用,对于用户本身也可以节省流量,双赢的事情何乐而不为呢?这也是为何我们要追求更高效的媒体压缩方式的一个初衷。

怎样在境外网站上进行推流

其实很简单,只需要将obs的网络连接引向代理,但是Shadowsocks中直接挂全局模式不太好,因为会将本来能够直连的网站也会通过代理连接,而且应该是不能代理到obs的(我从来不用全局)。

那么要怎么做到这点呢?我常用的是Proxifier,使用教程网上很多,这边不再赘述,只要在规则里面把obs的执行文件加入需代理列表即可,各种使用RTMP协议的直播网站应该都是直接可以这样搞定。

当然,一个高带宽的代理是必须条件。

题外话,无论是Youtube还是Twitch,其直播后台都比Bilibili强太多了。

用youtube-dl在直播进行中同时下载

基于今天花谱Live的下载失败,一怒之下又翻了翻youtube-dl的文档,发现可以在直播的同时直接截流保存成文件,用这种方法可以大大加快海盗效率。

准备工作

  • 良好的网络环境
  • 空闲的CPU资源
  • youtube-dl
  • FFmpeg
  • 一点点命令行基础

这里建议将youtube-dl和FFmpeg所在的目录加入环境变量中,用户或者系统的均可。另外你还要搞清楚自己的本地代理端口号,一般为1080。

配置文件与命令

youtube-dl支持配置文件,可以免去每次手动输一长串命令的麻烦,在Windows下其默认读取的配置文件位于用户目录下的youtube-dl.conf,即%userprofile%\youtube-dl.conf

这边准备好了两份配置文件,一份是直播同时下载,另一份是平常下载视频。两份配置文件都需要手动更改里面的代理端口号,和自己环境所匹配,其他不需要进行更改。

普通下载:

1
--proxy socks5://127.0.0.1:1081
2
-f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best'
3
-o '%(uploader)s/%(title)s.%(ext)s'
4
--add-metadata
5
--write-thumbnail
6
--ignore-errors
7
--extract-audio
8
--audio-format best
9
--audio-quality 0
10
--keep-video
11
--embed-thumbnail

直播的同时进行下载:

1
--proxy http://127.0.0.1:1081
2
-f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best'

分别将这两块命令行保存成两个文件,修改Proxy行的端口为自己使用的,建议一个命名为youtube-dl.conf放置在%userprofile%目录下,另一个换个名字也存%userprofile%目录下方便调用。

以上工作完成之后打开命令提示符,注意是cmd不是PowerShell,因为后者在管道操作上面有一些不同,这边是用最简单的cmd来完成。命令:

youtube-dl -o - U2B-LINK|ffmpeg -i - -vcodec copy -acodec copy "OUTPUT.mp4"

如果你默认的配置文件不是用于直播时同时下载的,那么请指定配置文件:

youtube-dl -o - --config-location PATH\TO\CONFIG U2B-LINK|ffmpeg -i - -vcodec copy -acodec copy "OUTPUT.mp4"

注意,-o之后的--i之后的-均不能遗漏,这是管道操作最重要的两点之一,还有一点是管道操作符|,跟反斜杠\同一个键。命令中的U2B-LINK就是油管链接、PATH\TO\CONFIG就是youtube-dl的配置文件具体位置,OUTPUT.mp4是输出的文件名。

>>endl;

我的 Tools 文件夹中都有什么

写点白开水文,这次介绍一下我存续最久的工具目录中都有些啥,按字母排序

AcDown

充满时代感的名字,早已经没有后续更新,作者 Kaedei 后来去做了弹弹Play

Aegisub

老牌的字幕打轴制作软件

AIDA64

老牌的 PC 整体检测软件

aMule

开源 ED2K 协议下载器
其实国内的 ED2K 网络并没彻底死,还是有人在用的

aria2

全平台命令行下载器,配合图形化前端食用更佳

AS SSD Benchmark

SSD 跑分软件

BDinfo

BD 原盘信息查看工具

BIND

一套关于 DNS 的工具集,其中我常用 dig

CascView

暴雪目前常用的 .casc 格式文件查看器

Cinebench

跑分

Cisco TFTP Server

思科出品的 TFTP 服务器

CPU-Z

老牌 CPU 检测工具

Crass

痴汉公贼开发的通用 GALGAME 资源提取器,已停止更新

CriPackTools

CRIWARE 的 CPK 格式文件解压器

CrystalDiskInfo

老牌硬盘状态查看器,S.M.A.R.T. 查看好手

CrystalDiskMark

老牌硬盘跑分工具

CTF Tool

PSP 主题文件修改器

Display Driver Uninstaller

Windows 的显卡驱动完整清除工具

de4dot

.NET 程序反混淆和解包工具

Detect It Easy

程序包识别工具

DiskGenius

磁盘操作工具,该有的都有,不该有的也有

Dism++

原本是一个类似 Dism 前端的工具,现在有了很多其他实用功能

DXVA Checker

DXVA 的检测工具

Everything

文件搜索器

FastCopy

文件拷贝器

FFmpeg

FLV Extract

FLV 文件的分离小工具

GCFScape

Valve 的各种包格式查看器

GPU-Z

老牌 GPU 检测工具

HD Tune Pro

老牌硬盘测试工具

HWMonitor

跟 CPU-Z 同门的硬件状态监视工具

ILSpy

.NET 程序集查看和反编译器

inSSIDer

WiFi 网络环境查看器

JSON C# Class Generator

根据 JSON 文本生成 C# 类的小工具

LAV Filters

一组应该是目前最牛逼的视频分离解码器

libwebp

WebP 格式工具集

Locale Emulator

Locale 模拟器,作者后来写了 QuickLook

MadVR

目前最牛逼的视频渲染滤镜

MD5Tool

自己写的 MD5 和 SHA-1 查看小工具

MediaController

自己写的远程音乐播放状态控制器

MediaInfo

媒体文件信息查看器

MeGUI

一套视频媒体编码工具图形前端

MKVToolNix

MKV 文件处理工具集

MonaTiny

简易的视频流服务器,支持 RTMP、HTTP(S)、WS 等协议

Mp3tag

音频文件元数据工具

Notepad++

Ntlea

辣个男人写的 Locale 模拟器

NVIDIA Inspector

N 卡驱动配置文件修改器

PPSSPP

PSP 模拟器

Privoxy

Web 代理

Proxifier

Proxy Everything

Putty

Rufus

目前最好用的 USB 启动介质制作器

SysinternalsSuite

针对 Windows 系统的工具集

Universal Extractor

从各种压缩包和安装程序中解压提取文件的工具

UsbEAm Hosts Editor

针对各大游戏平台的 Hosts 修改工具

Valve Resource Format

V社各种类型文件的查看、反编译器

VTFEdit

VTF 文件编辑器

WinHex

居家必备的编辑器

WinMTR

Windows 下的图形化 MTR 工具

WinSCP

WiX Toolset

针对 Windows 安装包(.msi等格式)的工具集

WizTree

磁盘空间占用可视化查看器

x264 & x265

开源 AVC 和 HEVC 编码器

Others

还有一些过于硬核的工具没有列出来,诸如 BIOS 修改之类的工具。

>>endl;

关于抗锯齿

今天听 Gadio News 的时候,最末尾一段提到了希望有人能来讲讲抗锯齿技术。才疏学浅,但是前几年看 MC 的文章还是知道一点相关内容,所以就来看着维基写写看,如有不正之处劳请指出。

锯齿与抗锯齿

首先,什么是锯齿,以及为什么会出现锯齿。

我们的屏幕,是以一个个正方形的像素点组成的,而正方形的特性导致了在倾斜的线上,边缘必定会出现一个个突起的阶梯状“毛刺”,比如图上这种

这种阶梯状的“毛刺”就是典型的锯齿。而有了锯齿也就有了抗锯齿(Anti-Aliasing).

抗锯齿的一般过程就是将这个毛刺的边缘柔化,使图像边缘看起来更平滑。如图:

各种算法简单介绍

抗锯齿算法种类非常多,下面的介绍顺序基本上是各种抗锯齿算法出现的时间顺序。

SSAA

超级采样抗锯齿(Super-Sampling Anti-Aliasing, 也可叫做 Supersampling 超采样)是最早也最简单粗暴的抗锯齿手法,它的原理非常简单,就是在渲染时将要输出的分辨率提升 x 倍,比如要输出 1920x1080 的分辨率到屏幕上,开启 SSAA 2x, 那么内部渲染时的分辨率就是 3840x2160, 然后 Downsampling 到 1920x1080 上,自然在许多纹理边缘上就显得平滑许多。但是这种方式太太太吃资源了,所以又开发出了新的算法。

在 Nvidia 发布二代 Maxwell 架构的时候,同时发布的 技术中就有 SSAA 的影子,技术思路同样是以更高分辨率渲染的原始画面输出到显示器分辨率上来得到更加精细平滑的画面。

MSAA

SSAA 太吃资源了,我们的硬件暂时还跟不上,怎么办?于是就有了多重采样抗锯齿(Multi-Sampling Anti-Aliasing), 它跟 SSAA 的区别就是,MSAA 只对于多边形的边缘进行抗锯齿处理。比如一个红色的圆,只对圆周作抗锯齿多重采样计算,但是圆周以内的部分则不会处理。这种方式下的画面锯齿得到了一定的抑制,而抗锯齿需要的资源也大幅下降到可接受的范围中。所以 MSAA 也逐渐成为目前被使用的最多的抗锯齿技术。

但是 MSAA 也有其局限之处,比如对于半透明物件、边缘不明确或者非常复杂的物件比如密集草丛、铁丝网这类的抗锯齿处理就比较力不从心。

CSAA & CFAA

历史进入 Direct 10 时代,NV 方先声夺人发布了 G80 系列,同时带来了覆盖采样抗锯齿()技术,主要改进了取样类型从而使得抗锯齿效率提升,资源占用量也得到减少。举例来说,如果使用 16x MSAA,需要在周围取得 16 个采样点的色彩值和 Z 轴值,然后保存这些数值进行计算。而 16x CSAA,则全部在被采样的像素点中心取得色彩之和Z轴值,然后对比并去掉同样的数据。一般来说,16x CSAA 后只需要保存 4 份色彩值和 Z 轴值即可。换句话来说,4x MSAA 耗费的资源和 16x CSAA 是相同的,但是,16x CSAA的画面效果相比 4x MSAA 更好。

同期 ATI 在发布 R600 系列时也带来了可编程过滤抗锯齿(Custom Filter Anti-Aliasing)技术。简单的来说 CFAA 就是扩大取样面积的 MSAA,比方说之前的 MSAA 是严格选取物体边缘像素进行缩放的,而 CFAA 则可以通过驱动判断对影响锯齿效果较大的像素进行缩放,以较少的性能牺牲换取平滑效果。

但是由于种种原因,CSAA 被接受程度更高一些,不少游戏就直接加入了 CSAA 选项。而 CFAA 由于需要在显卡驱动面板中进行调试而渐渐被用户所遗忘。

MLAA & FXAA

在 CFAA 被遗忘之后,AMD-ATI 带来了形态抗锯齿(Morphological Anti-Aliasing).

不同于上面几种需要对多边形边缘进行分析计算的算法,MLAA 是一种后处理技术,发生在整个 3D 计算完成即将输出画面到屏幕上前,打个比方就是你拍完照用 Photoshop 处理的过程。

MLAA 的实际效果还是非常不错的,但是资源耗用还是有点厉害的。它的最大优势就是不需要游戏来支持它,因为是后处理技术所以在显卡驱动面板中打开就能用而且兼容性非常好。但是由于其仅仅使用颜色数据来判断抗锯齿边缘,因此 MLAA 的应用可能导致无法辨识到底哪些边缘需要进行抗锯齿计算。特别是一些不需要抗锯齿的地方,如文字,表格等,可能都由于不当抗锯齿而显得圆滑甚至怪异。

这边 A 家出了新抗锯齿技术,老冤家 NV 当然也不甘落后,在 Fermi 上推出了快速近似抗锯齿(Fast Approximate Anti-Aliasing)。

FXAA 和 MLAA 一样,也是一种后处理抗锯齿,两种 AA 在原理上相似,但是由于 FXAA 可以在 AN 两家的卡上都可以用而 MLAA 则由于部分计算处理依赖于硬件所以只能在 A 卡上用,最后导致 FXAA 被广泛的采用了。而且同时期 FXAA 的性能损失比 MLAA 更小,而效果上基本能接近 4x MSAA 的画面,虽然同样还是会出现“字体破坏”的情况。

TXAA

在抗锯齿这条路上,众多程序员以及各种“家”的探索是不会停下来的。在 Kepler 架构发布的同时,NV 也带来了新的 (Temporal Anti-Aliasing 可称为“时间性抗锯齿”)技术,据 NV 自家的介绍,这项技术集时间性过滤器、硬件抗锯齿以及定制的 CG 电影式抗锯齿解算法于一身。

原有的抗锯齿技术在解决静态画面的锯齿上可以说已经达到了瓶颈了,但是在动态画面上,有锯齿的部位很容易出现闪烁。如同其名字中的“时间性”,TXAA 旨在解决“时间性抗锯齿”,也就是动态画面中的锯齿闪烁等问题。而其同时提供着不输于 8x MSAA 的静态画面抗锯齿效果。

TXAA 可以说是目前被采用的较多的抗锯齿算法中最厉害的一种了,但是它一是需要硬件电路配合,二是吃资源,以性能换画面,所以也基本上是中高端 N 卡用户用的。

结语

目前主流的一些抗锯齿技术大概就是这么多了,本文很多内容都是参考中文互联网上的一些文章写成的。第一次在机核发文,存在的许多不足之处也请多多包涵。

家庭网络和路由

上一篇文章中,我提到回家要干的一件事情就是更换路由。把新买的二手 Nepgear Netgear R6250 替换掉用了两年多的洋垃圾 RT-N16. 更换到现在已经过去一天半左右的时间了,遇到了几个问题。

拿快递开箱换上配置好一共花了不到半小时就搞定了,然后问题开始浮现:我的 ThinkPad S1 Yoga 连接不到 R6250 提供的 2.4G 无线网络。开始认为是笔记本上那块单频 Intel 7260 的锅,然后把 R6250 的 2.4G 网的频宽从 40MHz 降到了 20MHz, 结果仍然有时断时续的情况出现,认为还是 7260 这张网卡的问题,准备更换网卡。但北美良心想在 BIOS 中做了限制,更换起来很麻烦,所以一筹莫展。结果今晚日常拿起手柄 V 的时候突发奇想连一下无线,发现根本找不到 2.4G 网的 SSID, 就算不容易刷出来了也是连接不上的状态,遂开始感觉是 R6250 的问题。Google 之,发现使用第三方固件的 R6250 大多都存在这种问题,比如 2.4G 网不稳定,2.4G 根本连不上什么的。但是我又不想用回官方那个烂的很的固件,于是掏出从学校快递回家,原本准备用来替换掉配电箱中的主路由的那只被改装过的 TP-Link WR720N, 本就刷好了 LEDE, 稍微改了几个配置就当 2.4G 的 AP 来用了,连接非常稳定。

把 DMZ 主机指定到自己的机器之后,直接通过 DDNS 域名进行内网访问,速度非常快,延迟非常低,爽。

然后用着用着,无心看到 IPv6 的地址头不对,而且怎么本地 DNS 域也变成了 LEDE 了?一看果然是小的 AP 在作怪,上面的 DHCP 服务器没关,也就是一个网段中有两个设备在 DHCP 广播。遂关闭之,顺带着把 Lan 口设置中的网关确定为 2.1, 并把 Dnsmasq 的服务一起关了,问题消失。

Progressive Web App

什么是 PWA

前不久了解到 Progressive Web App 这个在2015年就已经由 Chrome 项目组提出来的概念,A selection of Progressive Web Apps 这个站点上收录了许多支持 PWA 的网站,不乏有可用性非常高的 Telegram Web 和知名的 Flipboard 应用的网页版。

PWA 是什么?直译过来就是渐进式网络应用。特性有很多,想要了解具体的直接看 Progressive Web App, 这里只举我最看重的几点:

  • 轻量 & 离线可用

    跟普通的网页没啥区别,加载快。而且不像 Hybrid App 那样还是依赖于一个本地的 App 壳子,需要你去 App Store 安装

    PWA 在 Android 上保存到 Home Screen 之后就会自动编译生成一个 APK 安装进系统中,也就意味着,它不止是一个网页,而已经成为了一个本地应用,离线状态下也是可用的(当然依赖于网络的东西就不行了)。而这一过程相当快,所要耗费的网络流量也远远小于 Native/Hybrid App

  • 本地通知支持

    在添加在本地之后,PWA 就拥有了本地通知能力,因为在 Android 上是通过 GCM 实现的,所以国内这点并不好用,微博 PWA 就干脆没有写通知的功能

  • All in Browser

    其实这点就是第一点的补充,一个浏览器干所有的活,不用装那么多又大更新还要开 App Store 的应用。而这一点也包括在所有平台上都有同样的用户体验,虽然目前的 PWA 界面多是为移动设备而设计,但是至少我在 PC 上能一样很方便的用到它,而不是通过虚拟机或者其他手段。

我记得在早期 iPhone 刚发布的时候,Apple 的想推广的就是 Web App, 让用户可以用一个 Safari 干所有的活(可笑的是现在 iOS 还没支持 PWA),可惜当时的前端远远没有今天那么多好用新颖的技术,那时的移动设备性能也满足不了使用非原生代码的开销,所以最后 Apple 妥协了,推出了 App Store 直到今天。而现在 PWA 的推出,多了一个“渐进式”的前缀形容词,没有前几年强推 Web App 的那种势头,更加务实的风格更能被人们接受。

目前比较有用的 PWA 站点

其他的可以上 A selection of Progressive Web Apps 看,虽然好像都是国外的而且好久没有更新了。

怎么安装

非常简单,用你的 PC 版 Chrome 或者 Chrome Android 打开上一节的随意一个站点,等待一会儿就会有一条提示你可以添加到主界面的横幅在下方出现,点击即可。或者你可以手动使用“添加到主界面”的功能来实现。

>>> endl;