BT.656视频接口解析：SAV/EAV同步与裸流解帧实战

简介这份文档围绕ITU-R BT.656数字视频接口标准展开面向从事视频采集、FPGA/SoC接口开发与嵌入式图像处理的初中级读者帮助理清BT.601与BT.656的隶属关系和工程差异。内容重点讲解8/10位数据传输、27MHz并口或243Mb/s串行接口、先Y后UV的传输顺序以及嵌入数据流的SAV/EAV定时基准信号格式SAV与EAV由FF 00 00 XY四字序列组成并说明场标识、场消隐、行消隐状态和辅助信号安排同时对照BT.601的16位并行数据、独立行场同步及4:2:2取样结构补充13.5MHz与6.75MHz取样、8比特量化等背景梳理二者在接口线数与同步方式上的区别。资源包仅含1个docx文件约46KB篇幅精炼便于快速查阅标准要点、核对接口时序和整理学习笔记。已有595人学习也可作为课程复习与资料查阅的辅助材料适合视频接口调试与协议入门参考。1. 一根八位数据线省下的两根线BT.656 到底解决了什么调试一块视频采集板时示波器上最容易让人心里发毛的不是没有信号而是有信号却对不上行场。ITU-R BT.656 就是这样一个接口它把行同步、场同步全塞进 8 位数据流省掉两根线代价是你必须先看懂字节流才知道这一行从哪开始。它出现的场景很具体——主控和视频编解码芯片之间只剩一条并口或串行链路没有多余 IO 走 HSYNC/VSYNC或者你手里只有一段裸抓流需要一个不靠硬件触发就能对齐的格式。做摄像头驱动、可编程逻辑视频通路、车载图像采集、格式转换的人绕不开它。下面按协议边界、数据流结构、代码解帧、踩坑、验证的顺序拆。2. 601 与 656 的分工4:2:2 采样和 27MHz 时钟分别管什么2.1 601 定的是像素长什么样656 定的是像素怎么排队出门把这两个标准混为一谈是很多配置错误的源头。ITU-R BT.601 原名 CCIR601管的是演播室数字电视的编码参数彩色信号先拆成亮度 Y 和两个色差 R-Y、B-Y再分别线性 PCM 编码4:2:2 等级下亮度取样 13.5MHz、两个色差各 6.75MHz每个样点 8bit演播室可 10bit亮度只用 220 个量化级黑电平落在 16、白电平落在 235色差各 224 级零电平落在 128码字 0 和 255 专门留给同步1 到 254 才是视频。有效样点数固定为每行亮度 720、色差各 360625/50 和 525/60 都一样就是为了两种制式之间好转。ITU-R BT.656 是 601 附件 A 里的数字接口标准它不改任何一个像素的值只规定这些像素怎么从一颗芯片搬到另一颗芯片三路分量复用成一条 8 位或 10 位总线行场同步以 SAV/EAV 的形式嵌进数据流接收端不再需要独立的同步线。所以判据很简单——参数不对、颜色不对、量化级不对去查 601行对不齐、帧拼不上、同步找不到去查 656。维度BT.601BT.656定位演播室数字编码参数601 附件 A 的数字接口数据宽度16 位并行Y、U、V 同传8/10 位复用一条总线同步方式HSYNC、VSYNC 独立输出嵌入 SAV/EAV引脚规模常见 21 芯常见 9 芯速率8bit 下 216Mbps27MB/s8bit或 270Mbps10bit一句话关系决定内容决定运输有一句流传很广的概括叫「601 等于 656 加 HSYNC 加 VSYNC」方向是对的但别理解成两者可以随意互换接口时序、消隐期长度、辅助数据位置都是 656 独有的把 656 流硬拆成 601 并口得自己补出同步脉冲补错了就是整屏斜切。2.2 216Mbps 是怎么算出来的27MHz 又从哪来带宽账必须先算明白否则选型阶段就会低估布线难度。按 4:2:2、8bit 量化亮度 13.5MHz × 8bit 108Mbps两个色差各 6.75MHz × 8bit 54Mbps合计 108 54 54 216Mbps。复用成一条总线后时钟必须能在一个周期里送出一个样点于是 13.5MHz × 2 27MHz每周期 1 字节27MB/s 正好等于 216Mbps。换成 10bit时钟还是 27MHz但每周期送 10 位速率变成 270Mbps。行预算是第二个必须算的数。625/50 制式行频 15625Hz27 000 000 ÷ 15625 1728也就是说一行固定 1728 个字节一个不多一个不少。525/60 制式行频约 15734Hz27 000 000 ÷ 15734 ≈ 1716。所有「一行多长、有效数据多少、消隐多少」的问题都是从这两个数推出来的不是拍脑袋定的。参数625/50525/60帧率 / 场率25 / 5030 / 60行频15625 Hz约 15734 Hz每行总字节8bit17281716每行有效字节14401440每行消隐数据不含同步字280268一帧总行数625525一帧有效行576288 × 2480240 × 2一帧场消隐行49451440 这个数在两套制式里完全相同因为 720 亮度 360 Cb 360 Cr 是 601 写死的跟行频无关。这也解释了一个常见困惑为什么 525/60 的每行字节更少有效数据却一样多——省掉的是消隐不是画面。2.3 什么时候该上 656什么时候该绕开接口选型不用纠结标准本身看三个约束就够了。IO 紧张、连接器芯数受限、板间只允许一条排线选 656传输距离超过板内、需要走差分选串行版本早期资料按 8bit 有效载荷把这一档写成 243Mbps工程上按 270Mbps 留裕量主控端只有 656 输入、没有并口采集能力也只能选它。反过来这几种情况我会主动避开 656调试初期还没有稳定的抓流工具需要靠示波器一根一根看波形那就先用带独立同步的并口跑通分辨率很低、帧率很低用 656 的固定行预算反而浪费带宽需要每像素超过 10 位精度656 的容器装不下得换别的接口。真要上 656配置阶段按下面五步走顺序别乱确认源端输出的是 656 而不是 601 并口看有没有 HSYNC/VSYNC 引脚在动确认是 8bit 还是 10bit10bit 时确认容器是 16 位还是打包成 8 位确认制式是 625/50 还是 525/60这决定接收端行计数器上限确认时钟方向是源端出 PCLK 还是本地晶振供时钟这一条错了两边都别想稳定确认消隐期有没有辅助数据有的话接收端不能把消隐段当垃圾直接丢。第 4 步是最容易翻车的一步。656 名义上是「源同步」接口但如果接收端用本地 27MHz 去采两边晶振差几十 ppm跑几十行就会漂一个字节表现是画面缓慢斜切。正确做法是用源端送出的 PCLK 采样本地时钟只用来做后续处理。3. 数据流拆开看SAV/EAV 四个字、XY 状态位和消隐期辅助数据3.1 一行 1728 字节的完整排布把一行按时间顺序摊开结构非常规整先是 EAV 四字节标志行消隐开始接着是消隐段625/50 下 280 字节里面可以塞辅助数据然后是 SAV 四字节标志有效视频开始最后是 1440 字节有效数据。四段加起来 4 280 4 1440 1728对上了。有效数据段的排列方式需要特别说清楚。很多资料一句话概括成「先传 Y 再传 UV」落到字节流上并不是先铺满 720 个 Y 再铺色差而是四个字节一组Cb、Y0、Cr、Y1然后 Cb、Y2、Cr、Y3一路推下去。720 个亮度样点加 360 组色差正好 1440 字节。这个顺序业内常写作 UYVY 或 CbYCrY接收端如果按 YUYV 去解颜色会整体偏但亮度和轮廓完全正常——这是最容易误判成「色彩矩阵算错」的一类问题。EAV 和 SAV 都是四字节格式统一为 FF 00 00 XY。前三字节是固定前缀第四字节 XY 携带场标识、场消隐状态和行消隐状态。这个前缀设计有讲究8bit 有效数据被限制在 1 到 254 之间00 和 FF 不会出现在画面数据里所以接收端一旦连续看到 FF 00 00就知道撞上同步字了。但光靠前缀不够因为辅助数据里也可能出现这三个字节所以还必须校验 XY。提示扫描同步字时不能只匹配 FF 00 00 就收工。XY 合法值里有一个 0x00第一场有效行的 SAV会形成 FF 00 00 00 这样的四连零字节只看前缀的实现很容易在这里多切一刀或者少切一刀。3.2 XY 状态字逐位拆解与偶校验XY 在 8bit 传输下是 8 位位序从高到低为 F、V、H、P3、P2、P1、P0、0。F 是场标识0 表示第一场、1 表示第二场V 是场消隐标志1 表示当前处于场消隐期H 是行消隐标志1 表示 EAV、0 表示 SAV最低位恒为 0。中间四位 P3 到 P0 是保护位用来做偶校验规则是P3 F ⊕ V ⊕ HP2 F ⊕ VP1 F ⊕ HP0 V ⊕ H这四位不是冗余装饰。接收状态机如果只判 H 位不看 P 位遇到一行数据被干扰成 FF 00 00 36 这种伪同步就会把后面 1440 字节整体错位一格画面上表现为一条水平细缝或者整帧偏左一列而且只在特定输入源上复现极难定位。位名称含义bit7F场标识0 第一场 / 1 第二场bit6V场消隐1 表示场消隐期bit5H行消隐1 表示 EAV / 0 表示 SAVbit4P3F ⊕ V ⊕ Hbit3P2F ⊕ Vbit2P1F ⊕ Hbit1P0V ⊕ Hbit0保留恒为 0按这套规则推F0、V0、H0 时 XY 等于 0x00F0、V0、H1 时 XY 等于 0x36F1、V1、H1 时 XY 等于 0xF0。这几个值不用背写代码时按公式现算比查表可靠。顺带说清 F 位的一个细节它标识的是「这一行属于哪一场」不是「这一行是不是场的起点」。所以拼帧时不能用 F 位跳变当帧头得结合 V 位从 1 变 0 的那个时刻判断场消隐结束。3.3 辅助数据放在哪ADF 为什么不是 FF 00 00消隐段不是空的音频、时间码、字幕、闭路信息都能塞在里面。辅助数据的起始标志叫 ADF值是 00 FF FF故意跟同步字的 FF 00 00 反过来避免接收端把数据包当成定时基准。一个辅助数据包的结构大致是ADF 三字节、DID数据标识、SDID二级标识、DC数据计数、若干用户数据字、最后一个校验和 CS要求整个包从 ADF 到 CS 所有字节累加后低 8 位为 0。字段长度说明ADF3 字节固定 00 FF FFDID1 字节数据类型标识SDID1 字节二级标识可为 0DC1 字节后续用户数据字个数UDWDC 字节用户数据CS1 字节校验和使整包字节和为 0标准对辅助数据的放置位置有约束10bit 形式可以只在行消隐期间传8bit 形式只能放在场消隐期那些行的有效数据区里传。这条约束在接收端很实用——如果你在 V0 的有效行里扫到了 ADF那基本可以断定同步状态机跑飞了或者抓流时丢了字节导致错位。3.4 8bit 与 10bit 的容器差异很多采集链路里源端明明输出 10bit抓下来的文件却按 8bit 去解结果全是花屏。区别在于容器8bit 时一个样点占一个字节10bit 时一个样点通常占两个字节16 位容器但真正有效的只有其中 10 位剩下 6 位可能是 0也可能是符号扩展。容器带来两个必须确认的参数一是有效位对齐方式低位对齐值域 0 到 1023和高位左对齐值域 0 到 65472在数值上差了 64 倍二是字节序两个字节谁在前。这两项猜错画面表现完全不同——对齐错是整体亮度塌成一片黑或爆成一片白字节序错则是相邻像素互换画面上出现规则的棋盘格纹理。625/50 的 10bit 流一行是 1728 个字也就是 3456 字节扫描同步字时匹配的是两个字节的 FF 00 和 00 00而不是单字节。移植解析脚本时这一处必须同步改只改有效数据长度不改同步匹配会出现「同步能找到但每行都差一半」的诡异现象。4. 把裸流解成图一份不依赖第三方库的 BT.656 解析脚本4.1 先确认三件事位宽、字节序、制式拿到一段 .bin 抓流别急着写代码先把这三个参数钉死否则后面每一步都在猜。位宽决定样点占几个字节字节序决定多字节容器怎么读制式决定每行总字节数和一帧有效行数。项目625/50525/60每行总字节8bit17281716每行有效字节14401440每行消隐数据280268一帧有效行576480一场有效行288240抓流长度也有讲究。625/50 一帧 40ms抓 100ms 只能覆盖两帧半一旦起点落在场消隐中间可能一帧都拼不完整。我一般抓 300ms 到 500ms保证至少五帧完整数据方便交叉验证。注意如果抓流工具是从中间开始录的文件开头大概率不是同步字。解析脚本要做「跳过开头直到第一个合法 SAV」的处理不能假设第 0 字节就是 FF。4.2 用 FF 00 00 定位同步并本文还有配套的精品资源点击获取