BT.656数字视频接口详解：从SAV/EAV到YUV 4:2:2传输

简介面向数字视频接口开发与调试人员的ITU-R BT.656协议学习文档适合需要理解视频采集、芯片间并口或串行传输及同步机制的中初级工程师查阅。压缩包仅含1个docx文件大小约46KB篇幅集中便于快速通读和随查随用。内容围绕BT.656与BT.601的关系展开说明8/10位数据传输、YUV传输顺序、27MHz并口与243Mb/s串行接口的差异并重点梳理SAV/EAV定时基准信号的FF 00 00 XY结构、F/V/H标志含义及辅助信号传送方式。文档还对照601的独立行场同步与656的嵌入式同步帮助读者厘清接口时序、软同步和制式参数等常见疑点。已有595人学习适合作为协议入门、接口联调排错和复习查阅的参考资料。1. 拆开排线看到的那八根线BT.656 到底是个什么标准拆开一块摄像头模组的排线你大概率会看到一组奇怪的信号一根时钟八根并排的数据线标着 PCLK 和 YUV0~YUV7。没有行同步没有场同步也没有哪根线告诉你现在走到了第几行。可它确实在稳定地吐画面——这种“引脚少得让人不放心、视频却能跑起来”的接口背后站的多半是 ITU-R BT.656。说白了它是一份数字视频接口标准挂在 ITU-R BT.601 名下是 601 的附件 A规定主要数字视频设备包括芯片之间怎么用 27MHz 并口或 243Mb/s 串行接口把视频从一处搬到另一处。它不管画面怎么采出来只管数据以什么顺序、什么节奏过线。打个比方601 是菜谱规定用什么料、切多大656 是上菜的规矩先上哪道、盘子边贴哪张单子。2. 为什么要有 656601 把画面变成数字656 负责把它送出门2.1 601 规定的其实是“怎么把画面变成数字”彩色全电视信号在变成数字之前要先被拆成亮度信号 Y 和两个色差信号 B-Y、R-Y然后各自单独编码这种做法叫分量编码。为什么要拆因为复合信号是把亮度和色度搅在一起的一碗东西接收端再想把它们分开就容易串色、爬边。分量编码相当于端上来就分三格谁也别沾谁。拆开之后要定采样频率。在 4:2:2 等级里亮度 13.5MHz两个色差各 6.75MHz比例正好 4:2:2。通俗地说13.5 这个数是拿来同时喂饱两种扫描制式的公约数——不管你这套系统是 625 行 50 场还是 525 行 60 场它都能对上。两种制式最后统一到同一条数字有效行上亮度 720 个样点每个色差 360 个样点亮度样点数除以 2 就是色差样点数。这样做的目的很实在就是为了方便制式转换——两边的数字行长得一样转换时才不用重新排版。量化这一层还有个容易被忽略的细节8 比特听起来有 0 到 255 共 256 级但标准并不让你全用满。亮度只分配 220 个量化级黑电平对应 16白电平对应 235每个色差分配 224 级零电平对应 128。为什么不给满一头一尾要留出余量。模拟信号送进来时幅度总会有点过冲若把 0 和 255 都占死稍微冒一点头就削顶了。这跟装箱子留条拉链缝是一个道理塞太满拉链先崩。2.2 601 的物理代价16 位并行、21 芯、两根同步线按 601 走线接口是并行的16 位数据一起推亮度占一路 8 位色差占另一路 8 位一个时钟周期把 Y、U、V 同时送出去。同步信息不藏在数据里而是老老实实单独拉两根线出来一根 HSYNC 管行一根 VSYNC 管场。整套接口数下来 21 芯。这 21 芯不是白来的。多一根线就多一个焊点、多一条走线、多一份等长匹配的麻烦。板子面积紧张的时候这些线是要抢地盘的。而且并行总线有个天然毛病线多了彼此的时序就越难对齐频率往上走一点眼图就开始闭合。这都是实打实的成本。有个等式能把两者的关系说透CCIR601 CCIR656 HSYNC VSYNC这不是什么俏皮话而是精确描述了这两个标准在物理层上的差别。601 比 656 多的就是那两根同步线。2.3 656 做的三处减法以及为此付出的代价656 砍了三刀。第一刀砍同步线行场同步不再单独输出而是嵌进数据流里第二刀砍数据位宽从 16 位降到 8 位也支持 10 位第三刀砍线数21 芯降到 9 芯。省下来的东西很直观但代价也明摆着。数据线从 16 根变 8 根意味着单个时钟周期推出去的比特少了一半要维持同样的信息量时钟就得提上去。所以 656 的传输速率是 601 的两倍接口时钟跑到 27MHz。这个 27 不是拍脑袋定的它就是三个分量采样率之和13.5 加 6.75 加 6.75。一个时钟周期送一个字节27M 个周期正好把一秒内的所有样点送完。另一处代价更隐蔽同步信息既然藏进了数据流那接收端就必须懂这套协议才能把画面拆出来。不懂协议的设备拿到这 8 根线看到的只是一堆毫无规律的跳变。这就是所谓“软同步”——省掉的是线换来的是对协议的强依赖。调试的时候这一点特别要命601 接错了你看同步线有没有波形就知道问题在哪656 接错了波形永远“有”只是全是乱的你得先确认自己有没有在正确的位置上找到 SAV。还有一处常被忽略656 是先传 Y、后传 UV 的。因为色差信号的采样率只有亮度的一半它没法在每一拍都出现只能两个亮度样点配一组色差。这个节奏一旦搞错画面就会呈现出非常典型的样子——颜色对了但位置偏了或者整片发绿发紫。这类问题在后面讲数据流排布时还会细说。3. 数据流拆开看视频、SAV/EAV 和辅助数据三段3.1 视频信号先 Y 后 UV 的四字节循环4:2:2 的含义是每两个亮度样点配一个 U 和一个 V。落到字节流上最小的传输单元就是四个字节第一个 Y、一个色差、第二个 Y、另一个色差然后循环。整条有效行里亮度 720 个两个色差各 360 个加起来 1440 字节。为什么非要“先 Y 后 UV”因为接收端要拿亮度做基准。亮度是每个样点都有的色差是隔一个才有一个接收端必须先锁定亮度的节拍才知道该在哪个位置插入色差。如果把顺序倒过来接收端就得先猜色差属于哪两个亮度样点那就本末倒置了。下面这段代码演示怎么把一行字节流还原成三路分量def split_422(line_bytes): 把一行 BT.656 有效视频字节流拆成 Y / U / V 三路 ys, us, vs [], [], [] # 每 4 个字节是一个单元Y0, U, Y1, V for i in range(0, len(line_bytes) - 3, 4): ys.append(line_bytes[i]) # 单元里的第一个亮度样点 us.append(line_bytes[i 1]) # 共享的 U 色差 ys.append(line_bytes[i 2]) # 单元里的第二个亮度样点 vs.append(line_bytes[i 3]) # 共享的 V 色差 return ys, us, vs这段逻辑的关键在步长 4 和两个偏移量。步长 4 对应一个宏像素单元i和i2是两个亮度样点的位置i1和i3是两个色差的位置。跑完之后ys长度是 720us和vs各 360比例正好 4:2:2。参数上唯一要小心的是len(line_bytes) - 3这个边界如果字节数不是 4 的整数倍尾部会被丢掉——真机上出现这种情况通常说明你把 SAV/EAV 的四个字节也一起喂进来了。3.2 定时基准信号FF 00 00 XY 这四个字怎么读656 的同步全靠两个定时基准信号一个在有效视频数据块开始时出现叫 SAV一个在结束时出现叫 EAV。每个信号由四个字组成格式是 16 进制的FF 00 00 XY。头三个是固定前缀第四个 XY 才带信息。为什么选 FF 00 00 当前缀因为视频数据里几乎不可能连续出现这三个值。前面说过亮度被限制在 16 到 235 之间色差在 16 到 240 之间0x00 和 0xFF 都落在合法视频范围之外。用“不可能出现的值”当路标接收端只要扫到这三个字节就能确定“这里是一条分界线”。这是嵌入式里很常见的一招拿非法值做标记成本低、识别快。XY 这 10 个比特是有讲究的从高到低排下来位名称含义D9固定 1标识这是一个定时基准信号D8F场标识0 为第一场1 为第二场D7V场消隐标志1 表示当前处于场消隐期D6H行消隐标志1 表示当前处于行消隐期D5~D2P3~P0保护比特由 F、V、H 异或运算得出供接收端检错D1~D0固定 0保留F、V、H 这三个标志位组合起来能唯一确定当前处在帧内的哪个位置。直观地说V 为 1 就是场消隐画面不出像V 为 0 就是有效场H 为 1 是行消隐H 为 0 是有效行。SAV 的 H 一定是 0因为它标的是有效视频的开始EAV 的 H 一定是 1因为它标的是有效视频的结束。F 则告诉你这是奇场还是偶场隔行系统靠它对齐。保护比特 P3~P0 是 F、V、H 三位的组合校验接收端算一遍、比一遍不一致就说明这四个字在传输中被干扰了。下面这段代码把解析和校验放在一起def parse_timing_ref(b0, b1, b2, b3): 解析 SAV / EAV 的四个字节返回标志位并校验保护比特 assert (b0, b1, b2) (0xFF, 0x00, 0x00), 前缀不对这不是定时基准信号 f (b3 6) 0x01 # D6 位场标识 v (b3 5) 0x01 # D5 位场消隐 h (b3 4) 0x01 # D4 位行消隐 p b3 0x0F # D3~D0四位保护比特 # 保护比特由 F、V、H 异或组合得到算一遍对比 expect (((v ^ h) 3) | ((f ^ h) 2) | ((f ^ v) 1) | (f ^ v ^ h)) if p ! expect: return None # 校验失败这一组字不可信 return {F: f, V: v, H: h, type: EAV if h else SAV}这里的位移量不是随便写的。b3 6取的是第 6 位对应 Fb3 5对应 Vb3 4对应 H最低四位直接与 0x0F 掩码取出保护比特。返回None表示校验没过这时候应当丢掉这一组字重新同步而不是硬着头皮往下解析——这是新手最容易踩的坑一旦错位后面整行都是废数据。3.3 辅助信号搭消隐期顺风车的数据656 的数据流里除了视频和定时基准还有第三类东西辅助信号。它允许在消隐期捎带一些额外数据比如时间码、字幕信息或者厂商自定义的内容。辅助信号有两种投放方式。10 比特形式只在行消隐期间传送8 比特形式只在场消隐中那些行的有效期间传送。为什么分两种因为空档大小不一样。行消隐是每行之间那点“课间十分钟”能塞的东西有限场消隐是每场之间的“寒暑假”空间宽裕得多。带宽窄的形式只能挤小空档带宽宽的形式才有资格占用大块时间。这个设计思路值得琢磨一下。有效视频期是用来传画面的一个字节都不能挪用辅助数据只能见缝插针。这跟快递装箱是一个逻辑主货先摆好缝隙里再塞填充物绝不能为了填充物把主货挤变形。4. 常见误区与易混概念656、601、YUV 到底差在哪4.1 误区一把 656 当成一种视频编码或压缩格式这是最高频的混淆。看到“协议”两个字很多人下意识觉得它是一种数据格式甚至以为它压缩了画面。不是。656 全程不压缩216Mb/s 的原始码流一个比特都不省它只是规定了这些比特按什么顺序排队、在哪里插标记。你把 656 的数据流原样抓下来丢掉 SAV/EAV剩下的就是裸的 YUV 采样值。为什么容易混因为文件格式、编码格式、传输接口这三件事在日常生活里经常被打包成一个词比如“MP4 视频”它同时包含了容器、编码和常见用途。但 656 只占其中“接口”这一格。区分方法很简单问自己一个问题——这个标准会不会让数据变少会那是压缩不会那只是搬家。4.2 误区二以为 601 和 656 是两个并列的标准不少人把这两个编号当成同一层级的两个方案纠结该选哪个。实际上 656 是 601 的附件 A是它的子协议。601 定的是演播室数字电视的编码参数——采样频率、量化位数、色彩空间、有效样点数656 定的是数字接口——这些参数产出的数据怎么在设备之间传。打个比方601 规定的是“钞票的面额和防伪特征”656 规定的是“运钞车怎么装箱、几点出发”。你不能问“我该用面额还是用运钞车”因为它们是配套的。真要比较的话正确的说法是601 体系里有两套传输方式一套是原始的并行加独立同步另一套就是 656。前者常被直接叫作 601 接口后者叫 656 接口。4.3 误区三把 YUV 和 656 画等号YUV 是分量的形态656 是把这些分量排成队列的方式。同一份 YUV 数据可以走 601 并行口可以走 656也可以被塞进别的传输通道。反过来656 的数据流里装的确实是 YUV但“装的是 YUV”不等于“就是 YUV 格式”。这个混淆带来的实际后果是有人拿到一段 656 数据直接当成 YUV 文件丢给播放器结果花屏。原因是 656 里混着 SAV/EAV 和辅助数据播放器不认识这些标记全当像素处理了。要还原成干净的 YUV必须先按 FF 00 00 的节奏把有效视频段切出来再丢掉所有非像素字节。4.4 误区四以为 656 只能是 8 位656 支持 8 位和 10 位两种位宽。8 位模式下每个分量占一个字节处理起来方便10 位模式下每个分量占 10 个比特量化精度更高能减少暗部的色带。10 位模式不只是“多两位”那么简单它对存储和带宽的要求也跟着涨接口时序也要重新对。判断自己手上是哪种看 SAV/EAV 的形态就行。8 位模式下前缀是三个完整的字节 FF 00 0010 位模式下每个字节扩成 10 位前缀的三个字对应 10 位宽的值。抓波形的时候如果发现“前缀”的宽度和后面数据一样都是 10 位那就是 10 位模式。4.5 误区五把 656 和 PAL/NTSC 当成互斥的选项经常听到“这套是 PAL 的那套是 NTSC 的”这种说法好像 656 也分制式。其实 656 的设计目标之一就是消弭制式差异不管 625 行 50 场还是 525 行 60 场数字有效行的亮度样点数都是 720色差都是 360。差异被推到了行数和场频上而有效行的数字结构是一致的。这也是 601 当年立下的初衷——为便于国际间的节目交换消除数字设备之间的制式差别让两种扫描制式之间能兼容。所以别再问“656 是 PAL 还是 NTSC”正确的问法是“这条 656 链路跑的是 625/50 还是 525/60”那是帧参数层面的问题不是接口层面的。5. 拿到一段数据怎么判断它是不是 656三个可验证的特征5.1 看引脚一根时钟、八根数据外加两根“副产品”656 的输入接口上有一根 pixel_CLK 时钟、8 根 YUV 数据线。有些芯片手册里还会列出两根叫 SVVS/SVHS 的垂直水平同步信号这让很多人当场懵不是说 656 不需要同步信号吗怎么又冒出来两根这里要分清“输入”和“产出”。纯正的 656 链路只靠那 8 根数据线就能恢复全部同步信息不需要外部送同步进来。那两根 SVVS/SVHS 通常是芯片内部从数据流里解出同步之后顺手送出来的旁路信号方便外部逻辑或者老设备对齐使用。它们是解码的副产品不是协议的必要条件。判断的时候看方向如果这两根是芯片往外输出那它是 656如果外部必须喂同步进去才能出画面那它更接近 601 那一套。5.2 看波形找 FF 00 00 出现的节奏最可靠的判据还是数据流本身。用逻辑分析仪抓一段在数据线上找FF 00 00这个三连。找到了再往后看第四个字节的取值。如果第四个字节的高位是 1且随行场位置规律变化基本可以确认。判断节奏是否正常看两个间隔。相邻两个 SAV 之间的字节数应当稳定因为每行的总长度是固定的一帧之内 EAV 和 SAV 的交替次数应当等于行数。如果间隔忽长忽短八成是采样时钟和发送端不同源或者你在错误的边沿上采样了。血泪经验是先用最低采样率抓个大概把 FF 00 00 的粗位置定下来再提高采样率细看别一上来就开最高速率抓出来的文件大到打不开。5.3 算带宽27MHz 这个数是怎么来的很多人把 27MHz 当成一个给定的魔法数字背下来其实它是算出来的。把三个分量的采样率加起来分量采样率每样点位宽码率Y13.5 MHz8 bit108 Mb/sCb6.75 MHz8 bit54 Mb/sCr6.75 MHz8 bit54 Mb/s合计27 MHz—216 Mb/s一个时钟周期送一个字节27M 个周期正好把 216Mb/s 送完所以并口的时钟就是 27MHz。串行接口那个 243Mb/s 也差不多是这么来的27 乘以 9之所以比 216 多一点是因为串行化的时候还得把控制位和同步位一并捎上。这个表还有个实用价值它能帮你判断链路是不是跑满了。如果实测的字节率明显低于 216Mb/s那要么是有效行没填满要么是消隐期被拉长了要么时钟根本没跑到 27MHz。反过来如果字节率超标先怀疑是不是把辅助数据也算进有效像素了。6. 什么时候该上 656什么时候该绕开先说该用的时候。板内芯片到芯片的短距离互联656 几乎是默认选项——8 根数据线加 1 根时钟引脚省下来可以干别的。接现成的摄像头模组、视频编解码芯片、FPGA 视频通路只要对方手册上写着 656直接连就完事不用再折腾同步线的极性和时序。还有一种情况是引脚极度紧张的小板子21 芯的 601 根本布不下656 的 9 芯是唯一出路。再说该绕开的时候这里得给个明确的边界场景适不适合 656原因同一块 PCB 上芯片间互联适合8 根线布线压力小跨板排线超过半米谨慎27MHz 并行走线等长和串扰都难控需要压缩后再传不适合656 不压缩216Mb/s 是硬开销只支持 601 并口的老设备需桥接656 相当于 601 去掉两根同步线需要长距离、少线缆不适合并行总线天然不适合拉长有两类边界特别值得说。一是距离。656 是并行总线8 根数据线要同时到达线长了之后各根线的延迟差就会吃掉采样窗口。板内几十厘米通常没事一旦上了排线、跨了机箱眼图就开始难看。这时候正确的做法是换串行方案而不是硬把时钟降下来——降时钟会让带宽不够画面掉帧问题从一个变成两个。二是带宽。216Mb/s 是裸码率不压缩、不打折。如果你的传输通道本身就紧张比如要过一条窄带链路那 656 从源头上就不合适得先做压缩再传。判断方法很直白算一下通道能给的带宽再和 216Mb/s 比一比差一个数量级就别挣扎了。翻车的典型场景是有人拿 656 去接一个理论带宽刚够的通道跑静态画面一切正常一上运动画面就开始撕裂——因为消隐期的余量被吃掉了。还有个容易被忽略的边界调试能力。656 把同步藏进数据流好处是省线坏处是出问题时你手上没有一根“同步信号”可以拿来当参照。板子 Bring-up 阶段如果团队里没人熟悉 SAV/EAV 的解析定位一个花屏问题可能要耗掉好几天。这种情况下前期先用带独立同步的接口把链路跑通、确认摄像头和时钟都没问题再切到 656反而更快。我自己的习惯是这样每拿到一块新板子先不看画面先抓 SAV/EAV 的间隔。间隔稳了说明时钟和链路没问题间隔不稳画面再好看也是假的早晚出事。有一次为了赶进度跳过这一步后面一个偶发的闪屏查了整整两周最后发现是采样边沿选错了半拍——如果一开始就数了间隔半小时就能看出来。从那以后我每次接新链路都强制走一遍先抓前缀、再数间隔、最后才看画面。资料整理在下载包里了需要的话直接取走对照着看。希望帮到你。本文还有配套的精品资源点击获取