STM32F1xx官方资料：

《STM32中文参考手册V10》-第25章通用同步异步收发器（USART)

 

通信接口背景知识

设备之间通信的方式

一般情况下，设备之间的通信方式可以分成并行通信和串行通信两种。它们的区别是：

并、串行通信的区别
	
 
			
并行通信
			
串行通信
		
传输原理
			
数据各个位同时传输
			
数据按位顺序传输
		
优点
			
速度快
			
占用引脚资源少
		
缺点
			
占用引脚资源多
			
速度相对较慢
		
串行通信的分类

1、按照数据传送方向，分为：

单工：数据传输只支持数据在一个方向上传输；
	
半双工：允许数据在两个方向上传输。但是，在某一时刻，只允许数据在一个方向上传输，它实际上是一种切换方向的单工通信；它不需要独立的接收端和发送端，两者可以合并一起使用一个端口。
	
全双工：允许数据同时在两个方向上传输。因此，全双工通信是两个单工通信方式的结合，需要独立的接收端和发送端。


2、按照通信方式，分为：

同步通信：带时钟同步信号传输。比如：SPI，IIC通信接口。
	
异步通信：不带时钟同步信号。比如：UART(通用异步收发器)，单总线。
在同步通讯中，收发设备上方会使用一根信号线传输信号，在时钟信号的驱动下双方进行协调，同步数据。例如，通讯中通常双方会统一规定在时钟信号的上升沿或者下降沿对数据线进行采样。

在异步通讯中不使用时钟信号进行数据同步，它们直接在数据信号中穿插一些用于同步的信号位，或者将主题数据进行打包，以数据帧的格式传输数据。通讯中还需要双方规约好数据的传输速率（也就是波特率）等，以便更好地同步。常用的波特率有4800bps、9600bps、115200bps等。

在同步通讯中，数据信号所传输的内容绝大部分是有效数据，而异步通讯中会则会包含数据帧的各种标识符，所以同步通讯效率高，但是同步通讯双方的时钟允许误差小，稍稍时钟出错就可能导致数据错乱，异步通讯双方的时钟允许误差较大。

常见的串行通信接口

 

常见的串行通信接口
	
通信标准
			
引脚说明
			
通信方式
			
通信方向
		

			
UART

			
（通用异步收发器）
			
			

			
TXD：发送端

			
RXT：接收端

			
GND：共地
			
			
异步通信
			
全双工
		

			
1-wire

			
（单总线）
			
			
DQ：发送/接收端
			
异步通信
			
半双工
		
SPI
			

			
SCK：同步时钟

			
MISO：主机输入，从机输出

			
MOSI：主机输出，从机输入
			
			
同步通信
			
全双工
		
I2C
			

			
SCK：同步时钟

			
SDA：数据输入/输出端
			
			
同步通信
			
半双工
		
 

STM32串口通信基础

STM32的串口通信接口有两种，分别是：UART（通用异步收发器）、USART（通用同步异步收发器）。而对于大容量STM32F10x系列芯片，分别有3个USART和2个UART。

UART引脚连接方法

RXD：数据输入引脚，数据接受；
	
TXD：数据发送引脚，数据发送。


对于两个芯片之间的连接，两个芯片GND共地，同时TXD和RXD交叉连接。这里的交叉连接的意思就是，芯片1的RxD连接芯片2的TXD，芯片2的RXD连接芯片1的TXD。这样，两个芯片之间就可以进行TTL电平通信了。



若是芯片与PC机（或上位机）相连，除了共地之外，就不能这样直接交叉连接了。尽管PC机和芯片都有TXD和RXD引脚，但是通常PC机（或上位机）通常使用的都是RS232接口（通常为DB9封装），因此不能直接交叉连接。RS232接口是9针（或引脚），通常是TxD和RxD经过电平转换得到的。故，要想使得芯片与PC机的RS232接口直接通信，需要也将芯片的输入输出端口也电平转换成rs232类型，再交叉连接。

经过电平转换后，芯片串口和rs232的电平标准是不一样的：

单片机的电平标准（TTL电平）：+5V表示1，0V表示0；
	
Rs232的电平标准：+15/+13 V表示0，-15/-13表示1。
RS-232通讯协议标准串口的设备间通讯结构图如下： 



所以单片机串口与PC串口通信就应该遵循下面的连接方式：在单片机串口与上位机给出的rs232口之间，通过电平转换电路(如下面图中的Max232芯片) 实现TTL电平与RS232电平之间的转换。



具体要了解RS232串口的，可以查看链接RS232串口简介。

STM32的UART特点

全双工异步通信；
	
分数波特率发生器系统，提供精确的波特率。发送和接受共用的可编程波特率，最高可达4.5Mbits/s；
	
可编程的数据字长度（8位或者9位）；
	
可配置的停止位（支持1或者2位停止位）；
	
可配置的使用DMA多缓冲器通信；
	
单独的发送器和接收器使能位；
	
检测标志：① 接受缓冲器  ②发送缓冲器空 ③传输结束标志；
	
多个带标志的中断源，触发中断；
	
其他：校验控制，四个错误检测标志。
 

串口通信过程



STM32中UART参数

串口通讯的数据包由发送设备通过自身的TXD接口传输到接收设备的RXD接口，通讯双方的数据包格式要规约一致才能正常收发数据。STM32中串口异步通信需要定义的参数：起始位、数据位（8位或者9位）、奇偶校验位（第9位）、停止位（1,15,2位）、波特率设置。

UART串口通信的数据包以帧为单位，常用的帧结构为：1位起始位+8位数据位+1位奇偶校验位（可选）+1位停止位。如下图所示：



奇偶校验位分为奇校验和偶校验两种，是一种简单的数据误码校验方法。奇校验是指每帧数据中，包括数据位和奇偶校验位的全部9个位中1的个数必须为奇数；偶校验是指每帧数据中，包括数据位和奇偶校验位的全部9个位中1的个数必须为偶数。

校验方法除了奇校验(odd)、偶校验(even)之外，还可以有：0 校验(space)、1 校验(mark)以及无校验(noparity)。 0/1校验：不管有效数据中的内容是什么，校验位总为0或者1。

UART（USART）框图



这个框图分成上、中、下三个部分。本文大概地讲述一下各个部分的内容，具体的可以看《STM32中文参考手册》中的描述。

框图的上部分，数据从RX进入到接收移位寄存器，后进入到接收数据寄存器，最终供CPU或者DMA来进行读取；数据从CPU或者DMA传递过来，进入发送数据寄存器，后进入发送移位寄存器，最终通过TX发送出去。

然而，UART的发送和接收都需要波特率来进行控制的，波特率是怎样控制的呢？

这就到了框图的下部分，在接收移位寄存器、发送移位寄存器都还有一个进入的箭头，分别连接到接收器控制、发送器控制。而这两者连接的又是接收器时钟、发送器时钟。也就是说，异步通信尽管没有时钟同步信号，但是在串口内部，是提供了时钟信号来进行控制的。而接收器时钟和发送器时钟有是由什么控制的呢？

可以看到，接收器时钟和发送器时钟又被连接到同一个控制单元，也就是说它们共用一个波特率发生器。同时也可以看到接收器时钟（发生器时钟）的计算方法、USRRTDIV的计算方法。

这里需要知道一个知识点：

UART1的时钟：PCLK2（高速）；
	
UART2、UART3、UART4的时钟：PCLK1（低速）。
框图的中部分，涉及到UART（USART）的中断控制部分，在后面的文章中会具体介绍到。



 

1 USB Type-C的基本原理

1.1 基本特性

Figure 1-1 USB Type-C接头外形

 

USB Type-C（简称USB-C）的基本特性：

1. 接口插座的尺寸与原来的Micro-USB规格一样小，约为8.3mm X 2.5mm

2. 可承受1万次反复插拔

3. 支持正反均可插入的“正反插”功能

4. 最大传输速度10Gb/s,即是USB 3.1 Gen2标准

5. 配备USB-C连接器的标准规格连接线可通过3A电流，同时还支持超出现有USB供电能力的USB Power Delivery，可以最大提供100W电力（20V/5A）


1.2 引脚定义

Figure 1-2 引脚定义

母口：

 

公头：

 

Figure 1-3 引脚映射图



1.3 USB-C设备识别方法

Figure 1-4 USB-C设备识别方法

 

电阻和充电电流映射如Table 1-1所示。

Table 1-1 USB-C Rp和Rd具体值（以上拉电压5V为例）

 

1.4 正反可插原理

Figure 1-5 正反可插图示

 

1.5 DRP设备如何工作

Figure 1-6 DRP设备电路原理图

 

DRP状态机伪代码示例如下所示（该示例伪代码状态机来源于P124 Figure 4-15 of USB Type-C Specification Release 1.1），为便于理解下一章节讲述的USB PD，所以也加入了USB PD的简单状态。


drp_toggle_timeout = 50ms;

tc_sm(void *arg)

{

    switch (state) {

    case UFP_STATE_DETACHED:

        if (DFP连接) {

            state = UFP_STATE_ATTACHED_DEBOUNCE;

            debounce_timeout = 100ms;

        } else if (drp_toggle_timeout) {

            set_drp_mode(CC电阻上拉);

            state = DFP_STATE_DETACHED;

        }

        break;


    case UFP_STATE_ATTACHED_DEBOUNCE:

        if (DFP仍然连接) {

            state = UFP_STATE_ATTACHED;

        } else {

            state = UFP_STATE_DETACHED;

        }

        break;


    case UFP_STATE_ATTACHED:

        // TODO

        state = UFP_STATE_DISCOVERY;

        break;


    case UFP_STATE_DISCOVERY:

        // TODO: PD negotiate

        break;


    [...]


    case DFP_STATE_DETACHED:

        if (UFP连接) {

            state = DFP_STATE_ATTACHED_DEBOUNCE;

            debounce_timeout = 100ms;

        } else if (drp_toggle_timeout) {

            set_drp_mode(CC电阻下拉);

            state = UFP_STATE_DETACHED;

        }

        break;


    case DFP_STATE_ATTACHED_DEBOUNCE:

        if (UFP仍然连接) {

            state = DFP_STATE_ATTACHED;

        } else {

            state = DFP_STATE_DETACHED;

        }

        break;


    case DFP_STATE_ATTACHED:

        // TODO

        state = DFP_STATE_DISCOVERY;

        break;


    case DFP_STATE_DISCOVERY:

        // TODO: PD negotiate

        break;

    } // end of switch

}


1.6 防伪以及线缆验证

Figure 1-7 eMarker（EMCA）原理简介

 

Question：USB-C的接口是否一定要IC支持？


2 Abbreviations

ARC：Argonant RISC Core

AT91SAM9260：SAM means Smart ARM-based Microcontroller

ATMEL SAMBA：ATMEL Smart ARM-based Microcontroller Boot Assistant

CC2530：TI ChipCon2530

DWC2：Design Ware Controller 2，Apple的嵌入式设备，包括iPad和iPhone都是使用的DWC2

ISP1161：Philips' Integrated host Solution Pairs 1161，“Firms introduce USB host controllers”，https://www.eetimes.com/document.asp?doc_id=1290054

SL811HS：Cypress/ScanLogic 811 Host/Slave，性能上与ISP1161（Integrated host Solution Pairs 1161）相当

TDI：TransDimension Inc.，该公司首先发明了将TT集成到EHCI RootHub中的方法，这样对于嵌入式系统来说，就省去了OHCI/UHCI的硬件，同时降低了成本，作为对该公司的纪念，Linux内核定义了宏ehci_is_TDI(ehci)

TLV：TI Low Value，高性价比

TPS：TI Performance Solution

TT：Transaction Translator（事务转换器，将USB2.0的包转换成USB1.1的包）

全系列目录：通过 JFR 与日志深入探索 JVM - 总览篇

我个人有个习惯，对于要用的一个新的框架，新的中间件等等，我一般不太信任它的官网“吹”的优点以及性能测试，我一般会一边使用一边自己测试，并且猜想其内部实现并结合源码搞清楚它的实现原理以及一些“坑”（这些“坑”并不是说这些框架或者中间件有什么毛病，而是因为官网浮夸的“吹”以及有些事情说一半留一半导致用户有误解），在这之后我才敢放心使用。
所以呢，我想先将 JFR 实现的基本原理提前说明白，这样可以让大家先有个整体印象，搞明白为何这么配置就对线上 JVM 影响小，从而放心使用。
JFR 的生命周期

JFR 记录开始：每个 JVM 进程可以同时启用多个 JFR 记录采集，可以在 JVM 启动的时候利用 JVM 启动参数启用 JFR 记录，也可以通过jcmd动态开启 JFR 记录采集，也可以在程序内通过代码开启采集。
JFR 记录结束：可以启动时指定在采集多久后结束，也可以通过jcmd动态关闭 JFR 记录采集，也可以在程序内通过代码结束采集。在结束时，可以指定让 JFR 记录 dump 到一个文件中。JFR 记录也会随着 JVM 的结束而结束。
JFR 记录分析：可以随时通过jcmd动态将 JFR 记录 dump 到一个文件中，或者通过代码程序中执行 dump，进行后续分析。注意 dump 并不会结束一个 JFR 记录，并且 dump 最多只能 dump 出上次 dump 到现在的所有记录。
JFR 记录实时分析：可以通过 JFR Stream 实现对于 JFR 记录的实时消费与处理。
JFR 的核心 - Event 的构成
在 JFR中，一切皆为事件（Event）：

任意 JVM 行为都是一个 Event，例如类加载也是一个 Event，对应 Class Load Event
开启 JFR 记录的原因也是一个 Event，对应的就是 Recording Reason Event
就算是有 Event 丢失，他也是一个 Event，对应 Data Loss Event

这些 Event 在某些特定的时间点或者特定的场景下产生，每个事件都有事件类型，开始时间，结束时间，发生事件的线程，事件发生的线程堆栈还有 Event 数据体组成。Event 数据体不同的 Event 数据不同，例如 CPU 负载，Event 发生之前还有之后的 Java 堆大小， 获取锁的线程 ID 等等。需要注意的是，并不是所有事件都要采集结束时间，发生事件的线程或者事件发生的线程堆栈，例如那种定时采样事件，就不需要记录这些。
Event 的分类
首先，按照采集规则，可以分为三类：

瞬时事件（Instant Event）：顾名思义，这种 Event 在发生时就立刻采集。例如：抛异常的事件 Throw Exception Event 还有线程一旦启动就会有 Thread Start Event，类似于这种在某一时刻发生的 Event。
持续事件（Duration Event）：这种 Event 需要耗费一些时间，在完成的时候如果超过一定时间限制才会记录。这个时间限制是可以设置的。例如有 GC 发生的时候的 GC Event，以及线程休眠的 Thread Sleep Event。
采样事件（Sample Event 或者是 Requestable Event）：按照一定的频率采集，这个频率是可以配置的。例如定时采集所有线程堆栈的 Thread Dump Event，定时检查 Runnable 线程在执行那些方法的 Method Sampling Event

按照事件类型，又可以分为：

Java 应用监控

a. TLAB 分配相关事件与统计事件

b. 文件 IO 相关

c. 网络 IO 相关

d. Java 异常与错误相关事件与统计事件

e. Java 锁同步相关

f. Java 线程相关事件与统计事件

g. 类加载统计
JVM 监控

a. 类加载相关事件

b. JIT 编译相关事件与代码高速缓存相关事件与统计事件

c. GC 相关事件

d. 安全点相关事件

e. 偏向锁相关事件

f. JVM 操作事件监控采集

g. JVM 信息与运行信息相关事件

h. 模块化操作相关事件
操作系统监控

Event 的序列化存储结构
这里先用一个事件作为例子，简单介绍下存储，具体存储结构的详细介绍，请参考后面的章节。
Class Load Event
0000FC10 : 98 80 80 00 87 02 95 ae e4 b2 92 03 a2 f7 ae 9a 94 02 02 01 8d 11 00 00


0000FC10: 文件位置
98 80 80 00: Event 大小
87 02: Event ID
95 ae e4 b2 92 03: 时间戳
a2 f7 ae 9a 94 02: 持续时间
02: 线程 ID
01: 堆栈 ID
PayLoad（每种 Event 的 field 不同）：

8d 11: 加载的类
00 : 定义类的 ClassLoader
00 : 初始化类的 ClassLoader



可以看出，JFR 的事件，是一个非常紧凑的存储方式，为了节省空间，对于同一类型的数字，根据大小变长存储。同时，没有存储字段名称。最后，对于一些公共的字段，例如上面这个事件定义类的 ClassLoader这样的字段，保留的是指向元空间的指针。的这样保证了节省空间，对于 JFR 这种存储流程来说，节约空间对于提升性能是很重要的，下一小节就会说明为何这样。
这里仅仅是举个例子，实际使用中，我们肯定不会去这么看每个 Event 的，而是通过可视化工具 JMC 去看，这个我们后面会讲到。这些 Event 也可以被应用消费解析，解析的工具类也是 Java 内置的，后面也会讲到。
Event 是如何产生的？存储流程是？
首先，Event 肯定是多线程产生的，这点显而易见。如果 Event  记录要保证全局有序，那么肯定需要多线程向一个指定队列或者缓存输出，那么不可避免的会涉及到锁争用，这样是很低效的。 Event本身带时间戳，那么可不可以在最后读取的时候进行排序？在一个线程内，生成的 Event 肯定是有序的；那么多线程产生的 Event， 就可以看成一个又一个的有序集合。最后，针对这些有序集合的每个元素进行整体排序，算法上快很多。所以我们没有必要在 Event 产生的时候就进行整体排序。

在 JFR 中，所有的 Event，会先存储到每个线程自己的线程 JFR 缓冲（Thread Buffer）中；在这个 Buffer 满了之后，会将 Buffer 的内容刷入全局 JFR 缓冲（Global Buffer ）中；Global Buffer 是一个环形 Buffer，保存着所有线程发送来的 Thread Buffer 中的内容。当这个环形 Buffer 存储到达上限之后，根据配置，会选择丢弃或者刷入文件。
可以看出，不同的 Buffer 之间的数据不会有任何重叠。并且某一块数据，要么就是在内存中，要么就是在磁盘上，不会两个地方都存在，那么这样会带来数据丢失的问题：

首先，在断电的时候或者操作系统强制重启的时候，还未写入磁盘的 Event 会丢失。
如果只是强制 kill -9 掉了 Java 进程，那么刷入文件写入高速缓冲的 Event 不会丢失，但是 Global Buffer 中还有 Thread Buffer 中的数据会丢失。同样的，如果JVM崩溃了，这些内存Buffer中的数据也会丢失。正常退出，或者应用异常但是JVM正常退出的，数据不会丢失。
采集的数据在可见之前可能会有很小的延迟。例如数据在从 Thread Buffer 刷入 Global Bufeer 的时候， 你如果去 dump JFR 的数据，可能这部分数据会被忽略而导致看不到。
最后一点，任何情况下导致在从 Global Buffer 刷入磁盘不够快的时候，这时候要刷入磁盘的数据可能被丢弃。当发生这种情况是，就会记录下数据丢失事件，这个事件包括是那块时间的数据丢掉了。通过 JFR 的日志也能看到这个信息。

这里涉及到的概念说明：

线程 JFR 缓冲（Thread Buffer）：每个线程写入 JFR 事件的缓冲池
全局 JFR 缓冲（Global Buffer ）：当某个线程的 Thread Buffer 满了，会刷入 Global Buffer。
JFR 数据块（Data Chunk）：Global Buffer 满了默认会刷入本地临时文件，本地临时文件并不是一个文件，而是按照一定大小分割的多个文件。每一个临时文件就是一个 Data Chunk，或者 Chunk

JFR 快的原因
由于 Event 产生是每个线程独立产生的，生成事件就像打印日志一样，这些事件是尽可能地节省了空间的，可以让各种缓冲不那么快变满。同时，通过从 线程 JFR 缓冲 -> 全局 JFR 缓冲的流程大大减少了并发争用。并且，写入临时文件也是在全局 JFR 缓冲满了之后才刷入文件，减少了文件 IO。
造成 JFR 慢的原因以及如何避免
通过上面的分析，我们可以知道，只要 Event 的产生没有瓶颈，那么 JFR 记录是很快的。但是，如果配置不当，Event 的产生很可能产生瓶颈，原因是：

JFR 某些 Event 采集可能会造成全局进入安全点（Safepoint）从而造成 STW（Stop-The-World）。例如 Thread dump event 采集所有线程堆栈，打印线程堆栈是需要全局进入安全点的，对于这种事件采集过于频繁肯定会对性能造成影响。还有如果开启了 JFR 追踪 GC 根节点，也会造成频繁进入安全点。
JFR 某些 Event 可以开启堆栈采集，但是追踪堆栈是一个比较耗费性能的操作。

对于可能进入安全点的 Event，或者是开启了堆栈采集的 Event，一定要控制好采集的频率或者事件的时间阈值限制，减少采集次数，如果过快，或者在业务高峰时采集的事件过多，肯定会影响性能。

前言

H264视频压缩算法现在无疑是所有视频压缩技术中使用最广泛，最流行的。随着 x264/openh264以及ffmpeg等开源库的推出，大多数使用者无需再对H264的细节做过多的研究，这大降低了人们使用H264的成本。

但为了用好H264，我们还是要对H264的基本原理弄清楚才行。今天我们就来看看H264的基本原理。 



H264概述



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

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

I帧：关键帧，采用帧内压缩技术。
P帧：向前参考帧，在压缩时，只参考前面已经处理的帧。采用帧音压缩技术。
B帧：双向参考帧，在压缩时，它即参考前而的帧，又参考它后面的帧。采用帧间压缩技术。
除了I/P/B帧外，还有图像序列GOP。

GOP:两个I帧之间是一个图像序列，在一个图像序列中只有一个I帧。如下图所示：


下面我们就来详细描述一下H264压缩技术。

H264压缩技术

H264的基本原理其实非常简单，下我们就简单的描述一下H264压缩数据的过程。通过摄像头采集到的视频帧（按每秒 30 帧算），被送到 H264 编码器的缓冲区中。编码器先要为每一幅图片划分宏块。

以下面这张图为例:



划分宏块

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



划分好宏块后，计算宏块的象素值。



以此类推，计算一幅图像中每个宏块的像素值，所有宏块都处理完后如下面的样子。



划分子块

H264对比较平坦的图像使用 16X16 大小的宏块。但为了更高的压缩率，还可以在 16X16 的宏块上更划分出更小的子块。子块的大小可以是 8X16､ 16X8､ 8X8､ 4X8､ 8X4､ 4X4非常的灵活。



上幅图中，红框内的 16X16 宏块中大部分是蓝色背景，而三只鹰的部分图像被划在了该宏块内，为了更好的处理三只鹰的部分图像，H264就在 16X16 的宏块内又划分出了多个子块。



这样再经过帧内压缩，可以得到更高效的数据。下图是分别使用mpeg-2和H264对上面宏块进行压缩后的结果。其中左半部分为MPEG-2子块划分后压缩的结果，右半部分为H264的子块划压缩后的结果，可以看出H264的划分方法更具优势。



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

帧分组

对于视频数据主要有两类数据冗余，一类是时间上的数据冗余，另一类是空间上的数据冗余。其中时间上的数据冗余是最大的。下面我们就先来说说视频数据时间上的冗余问题。

为什么说时间上的冗余是最大的呢？假设摄像头每秒抓取30帧，这30帧的数据大部分情况下都是相关联的。也有可能不止30帧的的数据，可能几十帧，上百帧的数据都是关联特别密切的。

对于这些关联特别密切的帧，其实我们只需要保存一帧的数据，其它帧都可以通过这一帧再按某种规则预测出来，所以说视频数据在时间上的冗余是最多的。

为了达到相关帧通过预测的方法来压缩数据，就需要将视频帧进行分组。那么如何判定某些帧关系密切，可以划为一组呢？我们来看一下例子，下面是捕获的一组运动的台球的视频帧，台球从右上角滚到了左下角。




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



通过宏块扫描与宏块搜索可以发现这两个帧的关联度是非常高的。进而发现这一组帧的关联度都是非常高的。因此，上面这几帧就可以划分为一组。其算法是：在相邻几幅图像画面中，一般有差别的像素只有10%以内的点,亮度差值变化不超过2%，而色度差值的变化只有1%以内，我们认为这样的图可以分到一组。

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

运动估计与补偿

在H264编码器中将帧分组后，就要计算帧组内物体的运动矢量了。还以上面运动的台球视频帧为例，我们来看一下它是如何计算运动矢量的。

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



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



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



我们把运动矢量与补偿称为帧间压缩技术，它解决的是视频帧在时间上的数据冗余。除了帧间压缩，帧内也要进行数据压缩，帧内数据压缩解决的是空间上的数据冗余。下面我们就来介绍一下帧内压缩技术。

帧内预测

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

H264的帧内压缩与JPEG很相似。一幅图像被划分好宏块后，对每个宏块可以进行 9 种模式的预测。找出与原图最接近的一种预测模式。



下面这幅图是对整幅图中的每个宏块进行预测的过程。



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



然后，将原始图像与帧内预测后的图像相减得残差值。



再将我们之前得到的预测模式信息一起保存起来，这样我们就可以在解码时恢复原图了。效果如下：



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

对残差数据做DCT

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



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



将残差数据宏块进行 DCT 转换。



去掉相关联的数据后，我们可以看出数据被进一步压缩了。



做完 DCT 后，还不够，还要进行 CABAC 进行无损压缩。

CABAC

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

无损压缩技术大家最熟悉的可能就是哈夫曼编码了，给高频的词一个短码，给低频词一个长码从而达到数据压缩的目的。MPEG-2中使用的VLC就是这种算法，我们以 A-Z 作为例子，A属于高频数据，Z属于低频数据。看看它是如何做的。



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



现在将 A-Z 换成视频帧，它就成了下面的样子。



从上面这张图中明显可以看出采用 CACBA 的无损压缩方案要比 VLC 高效的多。

小结

至此，我们就将H264的编码原理讲完了。本篇文章主要讲了以下以点内容： 

1. 简音介绍了H264中的一些基本概念。如I/P/B帧， GOP。 

2. 详细讲解了H264编码的基本原理，包括：

宏块的划分
图像分组
帧内压缩技术原理
帧间压缩技术原理。
DCT
CABAC压缩原理。
希望以上内容能对您有所帮助。谢谢！