音视频的采集
视频采集
视频的本质就是一张张图片,将这些图片连续播放,由于人眼的视觉暂留效果,就变成了视频。而每一张图片,都是一个个有色彩的像素点构成的,因此我们的图片文件通常有分辨率、色彩等参数。这里主要介绍一下图片的色彩格式,比较常见的有RGB色彩和YUV色彩。
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。
基本原理就是我们将音频分成一个一个小位置,对每个位置进行采样,记录每个位置的振幅。连起来就可以看做原先的模拟波形
和色彩深度相似,音频有**采样深度,**用来表示在每个位置记录振幅所用的二进制位个数。同样的,这个数越大,声音失真度就越小,质量就越好。
音频还有**采样率,**单位通常是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的升级版本,主要是极大地提高了压缩效率。
H.265将图像划分编码树单元(coding tree Unit, CTU),而不是宏块,增加了更多尺寸的图像分块(64*64、32*32等等),针对不同分块给出了更多预测单元,进一步提高编码效率,但同样编解码过程也变得复杂了。
目前主流浏览器基本都不支持H.265,想要使用的话需要自己实现播放器。
VP8/VP9
谷歌开发的视频编码格式,在前端不是很普及。
音频编码
音频数据相比视频数据没有那么大,所以音频编码也就没有那么多,并且音频编码高度成熟,平时我们基本可以不用考虑内部编码算法,仅做了解即可。
ACC
目前应用最广泛的音频编码方案,广泛用于各个领域。AAC是一种有损压缩编码,但这里有损并不是指降低音频质量,而是屏蔽了一些人耳听不出来的冗余信息
MP3
应用也相对广泛,但是相比ACC是比较旧的标准了,压缩率也比较一般,正在被ACC逐步替代
音视频封装格式
上文提到的音视频的编码,音频和视频是分开的,但我们使用的时候音频和视频是一起播放出来的。封装格式就是将视频流和音频流打包到一起,然后添加一些分辨率、时长等,将他们打包成一个文件。
注意封装格式和编码是完全不同的概念,每个格式都有自己支持的编码,同一种格式下的文件也有可能使用了不同的编码。
常见的封装格式如下(from [总结]视音频编解码技术零基础学习方法-CSDN博客)
名称 | 推出机构 | 流媒体(边下边播) | 支持的视频编码 | 支持的音频编码 | 目前使用领域 |
---|---|---|---|---|---|
AVI | Microsoft Inc. | 不支持 | 几乎所有格式 | 几乎所有格式 | BT下载影视 |
MP4 | MPEG | 支持 | MPEG-2, MPEG-4, H.264, H.263等 | AAC, MPEG-1 Layers I, II, III, AC-3等 | 互联网视频网站 |
TS | MPEG | 支持 | MPEG-1, MPEG-2, MPEG-4, H.264 | MPEG-1 Layers I, II, III, AAC, | IPTV,数字电视 |
FLV | Adobe Inc. | 支持 | Sorenson, VP6, H.264 | MP3, ADPCM, Linear PCM, AAC等 | 互联网视频网站 |
MKV | CoreCodec Inc. | 支持 | 几乎所有格式 | 几乎所有格式 | 互联网视频网站 |
RMVB | Real Networks Inc. | 支持 | RealVideo 8, 9, 10 | AAC, Cook Codec, RealAudio Lossless | BT下载影视 |