H264简介

来自百度百科的介绍：

H.264是国际标准化组织（ISO）和国际电信联盟（ITU）共同提出的继MPEG4之后的新一代数字视频压缩格式。
H.264是ITU-T以H.26x系列为名称命名的视频编解码技术标准之一。H.264是ITU-T的VCEG（视频编码专家组）和ISO/IEC的MPEG（活动图像编码专家组）的联合视频组（JVT：joint video team）开发的一个数字视频编码标准。

H.264是在MPEG-4技术的基础之上建立起来的，其编解码流程主要包括5个部分：帧间和帧内预测（Estimation）、变换（Transform）和反变换、量化（Quantization）和反量化、环路滤波（Loop Filter）、
熵编码（Entropy Coding）。

H.264标准的主要目标是：与其它现有的视频编码标准相比，在相同的带宽下提供更加优秀的图象质量。通过该标准，在同等图象质量下的压缩效率比以前的标准（MPEG2）提高了2倍左右。

H264编码原理

在了解H264编码原理之前，我们先来了解一下H264码流的数据。

H.264原始码流(裸流)是由一个接一个NALU组成，它的功能分为两层，VCL(视频编码层)和 NAL(网络提取层)。

VCL：包括核心压缩引擎和块，宏块和片的语法级别定义，设计目标是尽可能地独立于网络进行高效的编码。

NAL：负责将VCL产生的比特字符串适配到各种各样的网络和多元环境中，覆盖了所有片级以上的语法级别。

在VCL进行数据传输或存储之前，这些编码的VCL数据，被映射或封装进NAL单元。（NALU）

一个NALU = 一组对应于视频编码的NALU头部信息 + 一个原始字节序列负荷(RBSP,Raw Byte Sequence Payload).

NALU结构单元的主体结构如下所示；一个原始的H.264 NALU单元常由StartCode + NALU Header + RBSP三部分组成，
其中 Start Code 用于标示这是一个NALU 单元的开始，必须是"00 00 00 01" 或"00 00 01"开头。

NALU结构组成

既然H164中的都是NALU数据，那么NALU是怎么来的呢？

首先我们来看两张图：

H264编码数据

从图中我们看到一帧图片经过 H.264 编码器之后，就被编码为一个或多个片（slice），而装载着这些片（slice）的载体，就是 NALU 了。

h264码流结构

H264码流组成，从大到小排序依次是:

H264视频序列、图像、片组、片、NALU、宏块、像素。

H264压缩技术主要采用了以下几种方法对视频数据进行压缩。包括：

帧内预测压缩，解决的是空域数据冗余问题。
帧间预测压缩（运动估计与补偿），解决的是时域数据冗余问题。
整数离散余弦变换（DCT），将空间上的相关性变为频域上无关的数据然后进行量化。
CABAC压缩。

下面我们就来分析一下H264的编码原理：

宏块划分

当每一帧图像被送到 H264 编码器的缓冲区中。编码器先要为每一幅图片划分宏块。

我们以下面这张图为例

H264默认是使用 16X16 大小的区域作为一个宏块，也可以划分成更小的 8X8的大小。

宏块划分好了之后，就会计算宏块内的像素值

依次循环划分，等到将一帧图像宏块划分和像素计算完毕后就是这样子的：

划分子块

H264对比较平坦的图像使用 16X16 大小的宏块。但为了更高的压缩率，还可以在 16X16 的宏块上更划分出更小的子块。

子块的大小可以是 8X16､ 16X8､ 8X8､ 4X8､ 8X4､ 4X4非常的灵活。

帧分组

宏块划分好后，就可以对H264编码器缓存中的所有图片进行分组了。

我们知道视频的压缩原理就是去掉冗余数据，而视频的冗余数据主要是时间冗余和空间冗余两大类，而时间冗余又是最大的。

为什么时间冗余的数据是最大的呢？因为我们通过摄像头每秒中抓取几十帧的画像，而这些画像大部分情况下都是有相关性的，这些关联特别密切的帧，其实我们只需要保存一帧的数据，其它帧都可以通过这一帧再按某种规则预测出来，所以说视频数据在时间上的冗余是最多的。这也是为什么会有I帧、P帧以及B帧的缘由。

那么为了达到通过某几帧图像来预测后面几帧图像的目的，那么我们就需要对帧进行分组，将一些相似的帧划分在一组。

那么如何判定某些帧关系密切，可以划为一组呢？我们来看一下例子，下面是捕获的一组运动的台球的视频帧，台球从右上角滚到了左下角。

H264编码器会按顺序，每次取出两幅相邻的帧进行宏块比较，计算两帧的相似度，如图：

宏块比较

通过宏块扫描与宏块搜索如果发现这两个帧的关联度是非常高的，那么这几帧就可以划分为一组。

其算法是：在相邻几幅图像画面中，一般有差别的像素只有10%以内的点,亮度差值变化不超过2%，而色度差值的变化只有1%以内，我们认为这样的图可以分到一组。

在这样一组帧中，经过编码后，我们只保留第一帖的完整数据，其它帧都通过参考上一帧计算出来。我们称第一帧为IDR／I帧，其它帧我们称为P／B帧，这样编码后的数据帧组我们称为GOP。

运动估计与补偿与帧间压缩

我们把运动矢量与补偿称为帧间压缩技术，它解决的是视频帧在时间上的数据冗余。

在H264编码器中将帧分组后，就要计算帧组内物体的运动矢量了。

H264编码器首先按顺序从缓冲区头部取出两帧视频数据，然后进行宏块扫描。当发现其中一幅图片中有物体时，就在另一幅图的邻近位置（搜索窗口中）进行搜索。
如果此时在另一幅图中找到该物体，那么就可以计算出物体的运动矢量了。

以上面台球的例子为例，下面这幅图就是搜索后的台球移动的位置。

台球运动补偿

通过两帧图像中台球位置相差，就可以计算出台图运行的方向和距离。H264依次把每一帧中球移动的距离和方向都记录下来就成了下面的样子：

运动矢量计算出来后，将相同部分（也就是绿色部分）减去，就得到了补偿数据。
我们最终只需要将补偿数据进行压缩保存，以后在解码时就可以恢复原图了。压缩补偿后的数据只需要记录很少的一点数据，因而达到了压缩的目的。

帧内预测压缩

上面我们说了运动补偿解决的是视频数据在时间上的冗余问题，那么视频数据在空间上的冗余问题该怎么解决呢？这就是帧内预测压缩所要解决的问题。

我们知道，人眼对图象都有一个识别度，对低频的亮度很敏感，对高频的亮度不太敏感。所以基于一些研究，可以将一幅图像中人眼不敏感的数据去除掉。这样就提出了帧内预测技术。

H264编码器在对一幅图像被划分好宏块后，对每个宏块可以进行各种模式的预测。找出与原图最接近的一种预测模式。

我们通过一张图看下都有哪些预测模式，针对宏块大小的不同，有不同的预测模式,注意箭头的角度大小不同代表不同的预测模式。

H264帧内预测模式

在实际应用中，我们查看图片的时候，将图片不断放大之后会看到图片会变模糊，有很多小方块似的马赛克出现，这大概就是帧内预测的效果。

下面这张图就是通过采样宏块的左边和上边的像素值，然后通过9种预测模式预测出来的宏块像素结果：

帧内预测后的图像与原始图像的对比如下：

通过帧内预测之后，将原始图像与帧内预测后的图像相减得残差值。再将我们之前得到的预测模式信息一起保存起来，这样我们就可以在解码时恢复原图了。

这样通过存取小量的残差数据和预测模式就解决了视频数据上的空间冗余问题。

对残差数据做DCT

经过帧内与帧间的压缩后，虽然数据有大幅减少，但还有优化的空间。

可以将残差数据做整数离散余弦变换，去掉数据的相关性，进一步压缩数据。如下图所示，左侧为原数据的宏块，右侧为计算出的残差数据的宏块。

将残差数据宏块数字化后如下图所示：

我们可以看到宏块数字化后的表格数字是杂乱无章，没有规律可言的。我们将残差数据宏块进行 DCT 转换，结果如下图：

我们可以看出经过DCT转换后，我们的宏块数据变得有规律了，从左上角到右下角，数据越来越小。对于DCT转换的原理感兴趣的童鞋可以自行搜索了解，这里就不做多的详细讲解了，大概就是经过DCT转换出来的数据，从左上角到右下角，出现的频率越来约高。那么根据人眼对低频敏感对高频敏感这个原理，省掉右下部分的一些值的话，对人眼来说，看起来实际上是没什么区别的。

CABAC

帧内压缩是属于有损压缩技术。也就是说图像被压缩后，无法完全复原。而CABAC则属于无损压缩技术。

无损压缩技术大家最熟悉的可能就是哈夫曼编码了，给高频的词一个短码，给低频词一个长码从而达到数据压缩的目的。MPEG-2中使用的VLC就是这种算法，我们以 A-Z 作为例子，假如A属于高频数据，Z属于低频数据。
那么我们用一个短码代表A，为了区分则用一个长码代表Z，那么VLC这三个字母则可以通过查询对应的字母码表示出来。如图：

在早期的Android系统中，谷歌因为内存原因将图片的哈夫曼压缩给屏蔽了，所以如果开发者想要使用哈夫曼算法对图片进行压缩的话需要做一些扩展。

CABAC也是给高频数据短码，给低频数据长码。同时还会根据上下文相关性进行压缩，这种方式又比VLC高效很多。其效果如图：

结束

对于H264编码原理今天就讲这么多，希望以上内容能对您有所帮助。对于音视频开发感兴趣的童鞋，请扫码关注，一起学习一起嗨！！！

深圳上班，

生活简简单单，

14年开始从事Android Camera相关软件开发工作，

做过车载、手机、执法记录仪......

公众号记录生活和工作的点滴，

点击关注“小驰笔记”，期待和你相遇~

音视频开发系列-H264编码原理相关推荐

音视频开发系列--H264编解码总结
一.概述 H264,通常也被称之为H264/AVC(或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC) 对摄像头采集的每一帧视频需要进行编码,由于视频中存在空间和时间的冗余,需要 ...
【Android音视频开发】音频编码原理
文章变更表文章版本号变更内容变更日期备注 0.0.1 创建 2022/9/29 初版 0.0.2 补充编码原理和音频格式等内容 2022/9/30 1. 前言在[Android音视频开发] ...
【音视频开发系列】一学就会，快速掌握音视频开发的第一个开源项目FFmpeg
快速掌握音视频开发的第一个开源项目:FFmpeg 1.为什么要学FFmpeg 2.FFmpeg面向对象思想分析 3.FFmpeg各种组件剖析视频讲解如下,点击观看: [音视频开发系列]一学就会,快速 ...
【音视频开发系列】盘点音视频直播RTSP/RTMP推流一定会遇到的各种坑，教你快速解决
聊聊RTSP/RTMP推流那些坑 1.推流架构分析 2.推流缓存队列的设计 3.FFmpeg函数阻塞问题分析 [音视频开发系列]盘点音视频直播一定会遇到的各种坑,教你快速解决更多精彩内容包括:C/C ...
【音视频开发系列】srs-webrtc-janus开源流媒体服务器分析
全球最牛开源流媒体服务器源码分析 1.如何学习流媒体服务器 2.全球最牛流媒体服务器架构分析 3.我们能从全球最牛流媒体服务器得到什么 [音视频开发系列]srs-webrtc-janus流媒体服务器分 ...
【秒懂音视频开发】15_AAC编码实战
本文将分别通过命令行.编程2种方式进行AAC编码实战,使用的编码库是libfdk_aac. 要求 fdk-aac对输入的PCM数据是有参数要求的,如果参数不对,就会出现以下错误: [libfdk_aa ...
音视频开发系列（19）玩转 WebRTC 安全通信：一文读懂 DTLS 协议
在 WebRTC 中,为了保证媒体传输的安全性,引入了 DTLS 来对通信过程进行加密.DTLS 的作用.原理与 SSL/TLS 类似,都是为了使得原本不安全的通信过程变得安全.它们的区别点是 DTL ...
音视频开发系列（16）技术解码 | SRT和RIST协议综述
概要近些年来,互联网行业出现了几波和音视频相关的热潮:VR.短视频.直播等.除了VR因技术成熟度问题,还在蓄势待发,短视频和直播持续热度不减,以各种方式进入新的行业应用领域.视频直播方向,RTMP仍 ...
音视频开发系列(65）-FFMPEG进阶系列01-ffplay命令详解
概述 ffplay是一个基于FFMPEG库和SDL库开发的多媒体播放器.它的主要目的是是用来测试FFMPEG的各种API,比如codec/format/filter等等库. 掌握ffplay的设计逻辑 ...

音视频开发系列-H264编码原理