3. HDMI协议层解析：数据岛、控制周期、视频数据周期、InfoFrame结构
各位同学，今天我们来聊聊HDMI协议层里最核心的几个概念。说实话，我刚接触HDMI协议时，也被这些术语搞得晕头转向。什么数据岛、控制周期、视频数据周期……听起来像是一堆不相干的东西。但等你真正做采集卡或者显示驱动时，就会发现——这些周期其实构成了HDMI传输的“骨架”。
我个人习惯把HDMI协议层想象成一个“时间分片”系统。就像我们一天有工作、吃饭、睡觉一样，HDMI链路也把时间切成了不同的“周期”，每个周期干不同的事。下面我们一个一个来看。
3.1 三个周期的“分工”
HDMI的TMDS通道上，数据是连续传输的。但不同时间段，传输的内容完全不同。协议定义了三种周期：
- 视频数据周期：传输像素数据（RGB或YCbCr）
- 数据岛周期：传输音频、辅助数据（比如InfoFrame）
- 控制周期：传输控制信号（HSYNC、VSYNC等）
你想想看，这三个周期是怎么切换的？其实靠的是TMDS通道上的“前导码”（Preamble）。每个周期开始前，发送端会先发一组特定的控制信号，告诉接收端：“接下来我要发视频了”或者“接下来是数据岛”。
关键点：这三个周期不会同时出现。它们是时间上严格交替的。视频数据周期占绝大部分时间，数据岛周期穿插在消隐区，控制周期则出现在行/场消隐的边界。
3.2 视频数据周期——最“重”的活
视频数据周期，说白了就是传输像素的地方。每个TMDS时钟周期，三个通道各传一个像素分量。比如RGB 24bit，就是R、G、B各8bit，分别走三个通道。
我在项目中遇到过一个问题：有些便宜的HDMI源设备，视频数据周期里的像素时钟抖动很大。结果采集到的图像边缘有毛刺。后来我加了一级FIFO做时钟域同步，才把问题解决。嗯，这里要注意——视频数据周期对时钟质量要求很高。
视频数据周期的长度由分辨率决定。比如1080p60，一行有1920个有效像素，加上消隐区，总像素数约2200个。视频数据周期就占1920个时钟周期，剩下的就是消隐区，用来插数据岛和控制周期。
3.3 数据岛周期——音频和元数据的“快递员”
数据岛周期，这个名字挺有意思。为什么叫“岛”？因为它像孤岛一样，分散在消隐区里。每个数据岛周期可以传输音频样本、InfoFrame、辅助数据等。
数据岛周期使用TMDS的“4b/10b”编码（注意，不是视频的8b/10b）。每个数据岛周期包含一个包头（Packet Header）和若干包体（Packet Body）。包头告诉接收端：“我接下来要传的是音频包”还是“InfoFrame包”。
我曾经调试过一个HDMI音频无声的问题。折腾了两天，最后发现是数据岛周期里的音频包校验和算错了。HDMI协议对数据岛包的校验非常严格——包头有ECC纠错，包体有BCH校验。一个比特错了，整个包就丢了。
个人经验：如果你在做HDMI接收端，建议把数据岛周期的包解析做成状态机。先检测包头，再根据包类型解析包体。千万别用中断方式——数据岛周期很短，中断响应不过来。
3.4 控制周期——最“短”但最“关键”
控制周期传输的是HSYNC、VSYNC、CTL0~CTL3这些信号。每个控制周期只有12个TMDS时钟周期。但别小看这12个周期——它们决定了视频的同步关系。
控制周期出现在三个地方：
- 行消隐开始前（视频数据周期结束 → 控制周期）
- 行消隐结束后（控制周期 → 数据岛周期或视频数据周期）
- 场消隐期间（控制周期 → 数据岛周期）
控制周期里传输的CTL信号，其实就两个比特（CTL0和CTL1），但通过编码可以表示4种状态。比如CTL0=0, CTL1=0表示“接下来是视频数据周期”，CTL0=1, CTL1=0表示“接下来是数据岛周期”。
我记得有一次，客户说他们的显示器偶尔黑屏。我抓了TMDS波形一看，发现控制周期里的CTL信号在边界处有毛刺。接收端误判了周期切换，导致解不出视频。后来在FPGA里加了三级同步寄存器，问题就消失了。
3.5 InfoFrame结构——HDMI的“身份证”
InfoFrame，全称是Information Frame。它就像HDMI信号的“身份证”，告诉接收端：视频是什么格式、色彩空间是什么、有没有HDR、音频是什么采样率等等。
InfoFrame在数据岛周期里传输。每个InfoFrame包含三个部分：
| 部分 | 长度 | 内容 |
|---|---|---|
| Header | 3字节 | 包类型、版本、长度 |
| Subpacket 0 | 4字节 | 数据字节0~3 |
| Subpacket 1~3 | 各4字节 | 数据字节4~15（含校验） |
常见的InfoFrame类型有：
- AVI InfoFrame：辅助视频信息（分辨率、色彩空间、量化范围等）
- Audio InfoFrame：音频信息（声道数、采样率、编码格式）
- Source Product Descriptor InfoFrame：源设备描述（厂商、产品名）
- HDR Static Metadata InfoFrame：HDR静态元数据（亮度、色域等）
我个人觉得，AVI InfoFrame是最重要的。它里面的“Colorimetry”字段决定了接收端怎么解析颜色。如果发送端说“我是BT.2020”，但接收端按BT.709去解，那颜色就全偏了。
避坑指南：我曾经遇到一个HDMI源，它的AVI InfoFrame里“Quantization Range”字段写的是“Limited Range”（16~235），但实际视频数据却是“Full Range”（0~255）。结果画面暗部细节全丢了。后来我在接收端加了一个“自动检测量化范围”的逻辑，才彻底解决。
3.6 知识体系结构图
下面我用一张SVG图，把这三个周期和InfoFrame的关系画出来。你可以看到，视频数据周期是“主干”，数据岛周期和控制周期是“支线”，它们共同构成了完整的HDMI传输。
3.7 实际设计中的注意事项
好了，理论讲完了。我结合自己的项目经验，给大家几个实用建议：
- 解析控制周期时，一定要做去抖。控制周期只有12个时钟周期，但TMDS信号可能有毛刺。我习惯用三级寄存器同步，再加一个“连续采样3次相同才确认”的逻辑。
- 数据岛周期的包解析，建议用双缓冲。一个缓冲区接收当前包，另一个缓冲区给上层处理。否则容易丢包。
- InfoFrame的校验不能跳过。有些同学为了省资源，不校验InfoFrame的BCH码。结果遇到不规范的源设备，解析出来的信息全是错的。
- 注意视频数据周期里的“保护带”。在视频数据周期开始和结束的地方，有2个时钟周期的保护带（Guard Band）。接收端要忽略这2个周期的数据。
一个小技巧：调试HDMI协议时，我习惯用逻辑分析仪抓TMDS通道的CTL信号。只要看到CTL信号的变化规律，就能判断出三个周期的切换是否正常。这比直接看像素数据快多了。
嗯，关于HDMI协议层的三个周期和InfoFrame结构，今天就讲到这里。这些概念是后续做HDMI采集、显示驱动的基础。你想想看，如果你连数据岛周期里传的是什么都不知道，那怎么解析音频？怎么处理HDR？所以，花点时间把这块吃透，后面会轻松很多。
可可精品资料库