音视频编码基础

113 阅读11分钟

音视频的采集

视频采集

视频的本质就是一张张图片,将这些图片连续播放,由于人眼的视觉暂留效果,就变成了视频。而每一张图片,都是一个个有色彩的像素点构成的,因此我们的图片文件通常有分辨率、色彩等参数。这里主要介绍一下图片的色彩格式,比较常见的有RGB色彩和YUV色彩。

image

RGB色彩

rgb色彩格式源自于大家所熟知的“光的三原色模型”:我们可以使用Red、Green、Blue这三个颜色按不同的比例组合出其他的颜色。即对于每个像素点,我们存储红蓝绿这三个分量,就可以组合出对应的颜色,像素组合到一起就成了图片(参考图片的右侧示意)。

YUV色彩

YUV色彩最早出现于黑白电视。YUV色彩也有三个分量,其中分量Y代表明亮度,或者说灰度值,表示一个像素的明亮程度。单独的Y分量就可以构成一幅在老师黑白电视上看到的那种灰色画面。

而U和V则代表色度,其背后的原理我们先不深究,可以简单理解:Y(黑白画面)+ U&V(色彩数据)=彩色画面(参考图片的左侧示意)

YUV vs RGB

目前音视频使用比较多的色彩格式是YUV格式,主要的原因是因为YUV比较方便压缩。RGB的色彩格式在表示色彩时,三个分量是缺一不可的,这导致其数据不利于编码压缩。

而YUV我们可以注意到,即使只有Y分量,我们人眼也能清晰地识别出一幅图片。这是因为**人眼对于亮度的敏感要远高于色度,**所以我们就可以尽可能的压缩UV值,虽然色彩有所损失,并不太影响我们的肉眼观看的效果。

同时这里我们介绍一下色彩深度的概念,色彩深度是代表每个颜色分量所占用的二进制位的个数,也称为位/像素(bbp)。色彩深度越大,能表示的颜色就越多,色彩就越还原。

所以对于RGB色彩,每个像素需要三个分量也就是3个色深来存储。而YUV则可以牺牲一些UV值,例如常用的YUV420标准,是每4个Y值共用一个UV值,则平均每个像素需要(4+2)/4=1.5个色深来存储,仅有RGB的一半。

音频采集

自然界的音频是由于振动产生的,是一个连续不断的模拟波,而我们需要想办法把他转成二进制的数据。这里我们使用的通常是脉冲编码调制,即PCM

基本原理就是我们将音频分成一个一个小位置,对每个位置进行采样,记录每个位置的振幅。连起来就可以看做原先的模拟波形

image

和色彩深度相似,音频有**采样深度,**用来表示在每个位置记录振幅所用的二进制位个数。同样的,这个数越大,声音失真度就越小,质量就越好。

音频还有**采样率,**单位通常是kHz,代表一秒内采样的次数。根绝香农采样定理:为了不失真地恢复模拟信号,采样频率应该大于等于模拟信号频谱中最高频率的2倍。而人耳能听到的最高频率是20kHz,所以通常无损采样频率就取44.1kHz。

同时很多时候,我们还需要多个音源同时采集来更好的还原声音,所以还会有多个声道。

音视频编码

原生采集的音视频数据的非常的大。举个例子,对于一个1080P分辨率(1920*1080个像素)、24fps

(每秒24帧)、使用YUV420编码的数据,仅仅一分钟的视频就有 1.5 * 1080 * 1920 * 24 * 60 / 8 = 559872000 bit,也就是500多MB大,还没有声音,对于网络传输这是一个难以接受的大小。所以我们通常对音视频进行编码来减小他们的大小。

视频编码

视频编码标准有很多,我们介绍几个比较主流的。

H.264

H.264是目前主流浏览器所支持的标准,浏览器可以播放,应用非常广泛,我们着重介绍。

H.264的编码思路是这样的:一段时间内相邻的图像变化通常很小,所以没必要对这段时间内每一帧都完整编码。我们可以只记录这一段第一帧的完整编码,然后之后一帧只记录与第一帧的差值,以此类推直到这一段视频结束。

上述的这一段变化很小的视频,我们称之为一个序列**,**一个序列内的图像应该是变化不太大的。如果某个图像与之前的图像变换很大,很难参考之前的帧来生成新的帧,那么就结束上一个序列,开始下一个序列。这样一个一个序列就组成了一个视频。

I帧、P帧与B帧

根据编码思路,H.264标准分了三种帧

I帧

I 帧,帧内编码图像帧,不参考其他图像帧,只利用本帧的信息进行编码。

I帧是一个完整编码的帧,即一个序列的第一帧。

P帧

P 帧,即预测编码图像帧,利用之前的 I 帧或 P 帧,进行帧间预测编码。

P帧根据之前的之前的I帧或者P帧,利用运动预测的方式,编码与前一帧的差值。由于I、P帧可能被后续的P帧作为计算基础所参考,所以I、P帧都称之为**参考帧****,**参考帧的错误解码会导致后续的帧解码也发生错误,造成解码错误扩散。

B帧

B 帧,即双向预测编码图像帧,它既需要之前的图像帧(I 帧或 P 帧),也需要后来的图像帧(P 帧),进行帧间双向预测编码。

B帧需要同时根据前后两个参考帧作为基础进行计算,但B帧本身不作为参考帧,B帧解码错误不会引起扩散。同时B帧的编码效率最好,可以提高视频压缩率,但会增加视频解码的复杂度。

B帧并不是必须的,在需要压缩空间时通常会使用,例如存电影等,使用大量的B帧可以节约空间。而对于直播等这种对实时性要求比较高的场景,B帧需要缓冲多余的数据,还会加重CPU的负担,因此通常不使用B帧。

GOP与IDR

GOP即是一个序列长度,由一组I、P、B帧组成。其中序列的首帧(显然,一定是I帧)被称为IDR帧,解码器在读到IDR帧后会清除掉之前参考帧的缓存,从这个I帧开始重新进行计算,可以避免前边的GOP出错影响到后续的解码。

现代编码器会动态的根据帧内容变化幅度,来决定GOP的长度,获得一个比较好的编码效率。

PTS和DTS

在使用B帧时,由于B帧需要前后参考的特性,所以需要把B帧之后的P帧挪到前边去传输。但这样就引入了一个问题,播放的顺序与传输的顺序不一致。所以就有PTS和DTS,分别用来标识传输的顺序与播放的顺序,像这样

Stream: I P B B
   DTS: 1 2 3 4
   PTS: 1 4 2 3

帧内压缩

H.264对于I帧还会单独的进行帧内压缩,即是直接对图片进行压缩,使单独编码的I帧变得更小。主要有以下几步

帧内预测

一般来说,对于一幅图片,图片中像素的分布一般是有规律的,可以用几种模式大致的匹配像素分布的样,子H.264就根据这个原理进行帧内预测。按像素预测效率比较低,因此H.264提出块的概念。一个16*16的像素块成21为宏块,一个宏块还能进一步分为一个4*4的子块(考虑到YUV的编码模式,都是基于4个Y共享UV的逻辑)。H.264提前针对子块和宏块设定了预置的预测模式(色度块和亮度块都有自己的预测模式),用于描述对于相邻块的变化。

对于比较平坦的部分,我们记录相邻宏块的预测模式即可。对于带有大量细节的部分,则细化到子块,记录子块的变化模式。

显然,这样预测出来的图片和现实图片是有差别的,所以我们还需要计算一遍残差,即和原始图片的区别。将残差和预测模式合到一起,就可以还原出原来的图片了

残差压缩

我们刚刚获得的残差图还是比较大的,使用DCT-离散余弦变换可以进一步压缩残差图,这个算法比较复杂,这里就不详细介绍了

量化

H.264还会对图像进行量化,计算方法如下

FQ=round(y/QP)

即对于每个像素点的编码数据y,会指定一个步长QP,用编码数值去除步长就会获得一个编码范围比较小的量化值FQ。但是量化同时会使图像的动态范围变窄,会丢失一些精度。

H.265(HEVC)

H.265是H.264的升级版本,主要是极大地提高了压缩效率。

image

H.265将图像划分编码树单元(coding tree Unit, CTU),而不是宏块,增加了更多尺寸的图像分块(64*64、32*32等等),针对不同分块给出了更多预测单元,进一步提高编码效率,但同样编解码过程也变得复杂了。

目前主流浏览器基本都不支持H.265,想要使用的话需要自己实现播放器。

VP8/VP9

谷歌开发的视频编码格式,在前端不是很普及。

音频编码

音频数据相比视频数据没有那么大,所以音频编码也就没有那么多,并且音频编码高度成熟,平时我们基本可以不用考虑内部编码算法,仅做了解即可。

ACC

目前应用最广泛的音频编码方案,广泛用于各个领域。AAC是一种有损压缩编码,但这里有损并不是指降低音频质量,而是屏蔽了一些人耳听不出来的冗余信息

MP3

应用也相对广泛,但是相比ACC是比较旧的标准了,压缩率也比较一般,正在被ACC逐步替代

音视频封装格式

上文提到的音视频的编码,音频和视频是分开的,但我们使用的时候音频和视频是一起播放出来的。封装格式就是将视频流和音频流打包到一起,然后添加一些分辨率、时长等,将他们打包成一个文件。

注意封装格式和编码是完全不同的概念,每个格式都有自己支持的编码,同一种格式下的文件也有可能使用了不同的编码。

常见的封装格式如下(from [总结]视音频编解码技术零基础学习方法-CSDN博客

名称推出机构流媒体(边下边播)支持的视频编码支持的音频编码目前使用领域
AVIMicrosoft Inc.不支持几乎所有格式几乎所有格式BT下载影视
MP4MPEG支持MPEG-2, MPEG-4, H.264, H.263等AAC, MPEG-1 Layers I, II, III, AC-3等互联网视频网站
TSMPEG支持MPEG-1, MPEG-2, MPEG-4, H.264MPEG-1 Layers I, II, III, AAC,IPTV,数字电视
FLVAdobe Inc.支持Sorenson, VP6, H.264MP3, ADPCM, Linear PCM, AAC等互联网视频网站
MKVCoreCodec Inc.支持几乎所有格式几乎所有格式互联网视频网站
RMVBReal Networks Inc.支持RealVideo 8, 9, 10AAC, Cook Codec, RealAudio LosslessBT下载影视