BT.656时序解析：FPGA图像采集软同步与SAV/EAV状态机设计

简介：这份文档面向数字视频接口开发与调试人员，系统梳理ITU-R BT.656协议的核心内容，帮助读者理清其与BT.601的从属关系及工程应用差异。文档重点讲解656作为601附件A数字接口标准的定位：8/10位数据传输、无需独立同步信号、行场同步嵌入数据流，并拆解SAV与EAV定时基准信号的FF 00 00 XY四字序列格式及XY各标志位含义，同时说明视频信号、定时基准信号、辅助信号三部分构成。文中还对比601并行16位传输与656串行传输在速率、芯数、同步方式上的区别，并补充4:2:2取样结构、量化级分配与比特流计算等编码参数。资源包为1个docx文件，约46KB，篇幅精炼便于查阅。已有595人学习，适合硬件工程师、FPGA开发者及视频接口初学者作为协议速查与理解参考。

1. 拆开一份 BT.656 时序：为什么它把同步信号“藏”进了数据流

做 FPGA 图像采集的同行大概率遇到过这种场面：摄像头模组只引出 8 根数据线加一根像素时钟，示波器上找不到独立的 HSYNC、VSYNC，可图像偏偏能正常出。第一次碰到时我以为是模组省了引脚，后来把数据抓出来才明白，行场同步被塞进了数据流本身——这就是 ITU-R BT.656 最核心的设计。它隶属 ITU-R BT.601 的附件 A，本质是一个数字接口标准，解决的是主要数字视频设备（包括各类视频芯片）之间怎么用 27MHz 并口或 243Mb/s 串行接口把 YUV 分量数据传过去的问题。和 BT.601 的 16 位并行、YUV 同时传输、行场同步单独走线不同，BT.656 走 8/10 位数据、不需要额外同步信号、先传 Y 后传 UV，同步信息靠 SAV/EAV 定时基准信号嵌在数据里。这份资料把两套标准的差异、时序格式和接口引脚讲得比较完整，适合正在调摄像头接口、写采集逻辑、或者被“软同步”绕晕的嵌入式与 FPGA 从业者。

2. BT.601 与 BT.656 的分工：先把选型理由立住

2.1 分量编码定下的采样骨架

要理解 656，得先接受 601 定下的那套采样规则。601 规定彩色电视信号采用分量编码：全电视信号在转数字前先拆成亮度 Y 和两个色差 R-Y、B-Y，分别编码再合成。4:2:2 等级下，Y 采样频率 13.5MHz，两个色差各 6.75MHz，取样结构是正交的，按行、场、帧重复，每行中 R-Y、B-Y 的取样与奇次 Y 取样同位置，取样点在屏幕上的相对位置固定不变。量化上采用线性 PCM，演播室用 10bit、传输用 8bit；亮度只分配 220 个量化级，黑电平对应 16、白电平对应 235，色差各分配 224 级、零电平对应 128。这套“不占满动态范围”的做法是为了给同步码字留空间——0 和 255 专用于同步，1 到 254 才给视频。

算一下码率就明白为什么接口设计这么讲究：4:2:2 下比特流为 13.5×8 + 6.75×8×2 = 216Mb/s。有效行亮度样点 720、色差各 360，625 行/50 场和 525 行/60 场都是这个数，为的是方便制式转换——亮度样点数除以 2 就是色差样点数。这些数字不是背下来就完事，它们直接决定了你后面配 DMA 行长、算 FIFO 深度时的边界。

2.2 接口层面的取舍：16 位并行 vs 8 位软同步

两套标准在接口上的差别，用一张表能说清，这也是选型时最该盯的部分：

一句话概括：CCIR601 = CCIR656 + HSYNC + VSYNC。656 把两根同步线省掉，代价是数据速率翻倍、接收端必须自己从码流里把 SAV/EAV 抠出来。省引脚在芯片间互联、模组排线、PCB 布线紧张的场景里是实打实的收益，这也是为什么大量摄像头模组和视频解码芯片默认走 656 而不是 601。但“软同步”意味着接收逻辑多了一层状态机，调试复杂度从“看两根线电平”变成“抓码流找 FF 00 00 XY”，这是后面所有坑的源头。

2.3 定时基准信号的结构

656 的数据流由三部分组成：视频信号、定时基准信号、辅助信号。定时基准信号有两个，一个在每个视频数据块开始处（SAV，Start of Active Video），一个在结束处（EAV，End of Active Video）。每个定时基准信号是 4 个字的序列，格式为FF 00 00 XY（16 进制），前三个是固定前缀，第四个 XY 携带信息。XY 的位定义（MSB9-0）为1, F, V, H, P3, P2, P1, P0, 0, 0：F 标识第二场，V 是场消隐状态，H 是行消隐状态，P3~P0 是保护位，用于检错和纠错。接收端只要在码流里匹配到FF 00 00前缀，再读 XY 的 F/V/H，就能重建出行场时序，完全不需要外部同步线。

辅助信号这块容易忽略：辅助数据可以以 10bit 形式只在行消隐期间传送，也可以以 8bit 形式只在场消隐中的行有效期间传送。实际项目里如果你只关心图像，辅助数据段可以直接跳过，但跳过的方式要对——不能简单按固定偏移丢字节，得靠 SAV/EAV 定位，否则一旦上游插了辅助数据，你的行对齐就整体错位。

3. 从码流到像素：接收端状态机怎么写

3.1 引脚与时钟的接法

BT.656 输入接口的物理连接很精简：一根 pixel_CLK 像素时钟、8 根 YUV 数据信号，外加两根 SVVS/SVHS（垂直/水平同步信号）。注意这里的 SVVS/SVHS 在不同芯片上语义不完全一致，有的芯片即使走 656 也会把内部解出的同步引出来方便调试，有的则完全不引。我一般会先把 pixel_CLK 和数据线接好，SVVS/SVHS 先悬空或只做观测用，真正的同步以码流解析结果为准，避免被芯片手册里含糊的引脚定义带偏。

时钟极性是第一个要确认的点。656 通常在像素时钟的上升沿或下降沿采样，具体看发送端约定，抓一次波形确认数据在时钟哪个边沿稳定，比对着手册猜快得多。数据位序也要确认：8 位模式下是 YUV 分量按时分复用轮流出现在同一组数据线上，先 Y 后 UV，别把它当成三组独立总线。

3.2 SAV/EAV 解析的核心逻辑

接收端的核心是一个匹配FF 00 00前缀、再锁存 XY 的状态机。下面这段是常见写法的骨架，用 Python 表达便于理解逻辑，移植到 Verilog 时把循环换成逐时钟推进即可：

# 逐字节扫描 BT.656 码流，定位 SAV/EAV 并解出 F/V/H def parse_656(stream): i = 0 events = [] while i < len(stream) - 3: # 匹配固定前缀 FF 00 00 if stream[i] == 0xFF and stream[i+1] == 0x00 and stream[i+2] == 0x00: xy = stream[i+3] # XY 位定义: 1,F,V,H,P3,P2,P1,P0,0,0 f = (xy >> 6) & 0x01 # 第二场标识 v = (xy >> 5) & 0x01 # 场消隐 h = (xy >> 4) & 0x01 # 行消隐 # H=0 表示有效视频开始(SAV)，H=1 表示有效视频结束(EAV) events.append({"pos": i, "type": "SAV" if h == 0 else "EAV", "field": f, "vblank": v}) i += 4 else: i += 1 return events

逻辑说明：前缀匹配必须严格按字节对齐，FF 00 00在视频数据里也可能偶然出现，所以匹配到之后还要用 XY 的高两位（bit7 固定为 1）做二次校验，降低误判。参数上，F 位告诉你当前属于第一场还是第二场，V 位告诉你是否处于场消隐，H 位区分 SAV 和 EAV。实际硬件实现时，这三个位直接驱动行计数器、场计数器的复位与使能，比软件轮询稳得多。

3.3 有效数据窗口的界定

定位到 SAV 之后，紧跟其后的才是有效视频数据。以 4:2:2、8bit 为例，一行有效数据是 720 个 Y 样点和 360 个 Cb、360 个 Cr，按Cb Y Cr Y的顺序交错排列，总字节数 1440。EAV 到来即表示本行有效数据结束。这里有个容易翻车的细节：不同制式下从数字有效行末尾到基准时间样点的间隔不同，525 行/60 场是 16 个样点，625 行/50 场是 12 个样点。如果你的行缓冲按固定长度写死，换制式时就会差几个像素，表现为图像整体偏移或右侧出现竖条。

我一般会在状态机里维护三个计数器：行内字节计数、行计数、场计数。SAV 到来时把行内计数清零并置有效标志，EAV 到来时清有效标志并把行计数加一，V 位跳变时处理场切换。FIFO 深度按一行 1440 字节再加余量来估，别按 720 估——交错排列下字节数是像素数的两倍，这个账算错是新手最常见的翻车点。

4. 避坑与排查：五个真实踩过的坑

4.1 图像整体偏移几个像素

现象：采集出来的图像左边多一条黑边或右边被裁掉几个像素。原因：有效数据窗口的起止没按制式对齐，525/60 与 625/50 在有效行末尾到基准样点的间隔分别是 16 和 12 个样点，写死一个值换制式就错。解决：把间隔做成参数，按检测到的场频或配置寄存器切换，并在 SAV 之后延迟对应样点数再开始写有效数据。

4.2 偶发整帧错位

现象：大部分帧正常，偶尔整帧上下错位或花屏。原因：FF 00 00前缀在视频数据中偶然出现，状态机误判成 SAV/EAV。解决：前缀匹配后增加 XY 校验（bit7 必须为 1，保护位 P3~P0 参与校验），并加一个“最小间隔”约束——两个定时基准信号之间不可能短于一行，短于该间隔的匹配直接丢弃。

4.3 色度与亮度对不上

现象：图像亮度正常但颜色发花、红绿边缘错位。原因：把 8 位时分复用数据当成三路独立总线处理，或者 UV 顺序接反（Cb/Cr 颠倒）。解决：确认数据线上是Cb Y Cr Y交错，接收端按字节位置分流，Y 进亮度通道、Cb/Cr 交替进色度通道；若颜色整体偏，先查 Cb/Cr 是否接反，这是最快的定位手段。

4.4 时钟极性选错导致全黑

现象：数据线有波形但采不到有效像素，或采到的全是 0/255。原因：采样边沿与发送端约定相反，数据在采样时刻不稳定。解决：抓 pixel_CLK 与数据线的相对关系，确认数据稳定窗口落在哪个边沿，改采样沿；同时确认 0 和 255 是同步专用码字，若有效数据区大量出现这两个值，基本可判定采样沿错了。

4.5 辅助数据段导致行错位

现象：某些源设备接入后行对齐整体偏移。原因：行消隐期间插了辅助数据，接收端按固定偏移跳过消隐段，长度对不上。解决：不要按固定长度跳消隐，一律以 EAV 到下一个 SAV 之间的实际字节数为准动态处理，辅助数据段整段丢弃即可，不影响有效视频。

5. 进阶验证：用一帧合成码流把接收逻辑跑通

调 656 接口最省时间的做法不是等真实摄像头，而是自己合成一帧符合规范的码流灌进接收逻辑，把状态机先验证透。具体做法：按 625/50、4:2:2、8bit 构造，每行先放 EAV（XY 的 H=1），再放行消隐和辅助数据占位，然后放 SAV（H=0），接着 1440 字节有效数据（Cb Y Cr Y交错，Y 取值 16~235、Cb/Cr 取值 16~240 模拟合法范围），行末再放 EAV。场消隐期间把 V 位置 1，并按场序翻转 F 位。合成时故意在有效数据里埋几个FF 00 00序列，用来验证 4.2 里的误判防护是否生效。

验证分三步走：第一步只看 SAV/EAV 解析结果，打印每行的 F/V/H 和字节偏移，和构造时的预期逐行比对；第二步把解析出的有效数据按 Y/Cb/Cr 分流，统计每行样点数是否为 720/360/360，数量不对说明窗口界定有偏差；第三步把分流后的数据按 YCbCr 转 RGB 存成图，肉眼确认无偏移、无色偏。三步都过，再上真实模组，此时若出问题，基本可以锁定在模拟前端或时钟域，而不是协议解析本身。

这套合成码流的习惯是被坑出来的：早期我直接拿真实模组调，图像一花就怀疑是硬件问题，换线、换板、换电源折腾一圈，最后发现是状态机把数据里的FF 00 00当成了 SAV。从那以后我每次接 656 接口，都先用合成码流把解析逻辑跑一遍，确认误判防护和窗口界定都对了，再碰真实信号。希望这套流程能帮你少走几晚弯路。

本文还有配套的精品资源，点击获取