720×576i SD-SDI BT.656编码FPGA实现与仿真避坑

简介：面向FPGA视频处理入门、课程设计选题及视频类板卡前期验证的参考资料，围绕SD-SDI BT656格式720×576i数字视频流编码展开，适合具备一定Verilog基础、希望理解标清视频时序与硬件实现的读者。文档系统梳理576i行数据格式、帧格式、消隐与显示起止行、场结构及奇偶场行数范围，并说明EAV/SAV、F/V/H信号与P3～P0保护位的逻辑关系。在上述规范基础上给出Verilog编码实现，包含参数化行场计数、同步字节生成与YCbCr数据组织思路，并已在ModelSim完成仿真验证，可作为后续ALTERA 5cefa5U19i7n+LMH0340平台功能验证的参考。资源包共1个docx文件，约1.12MB，便于集中查阅。已有579人学习，适合用于课程作业实现、协议理解与编码模块对照排错。

1. 从一块 720×576i 的板卡说起：这套 SD-SDI 编码资料到底能干什么

真正让人卡住的往往不是 SDI 那根同轴线，而是它前面那 10 根并行数据线。板子焊好了，串行器也选好了，可 FPGA 该按什么节奏往外吐 SD-SDI 的 BT.656 码流，行消隐里那几个 0xFF、0x00、0x00、XY 到底怎么排，F/V/H 三位什么时候翻转，翻早了翻晚了对接收端意味着什么——这些问题在手册里散成几十页，拼不起来就寸步难行。这套围绕 720×576i（PAL 625/50）的 SD-SDI BT656 编码资料，核心就是一个叫AV_GEN_CBB的 Verilog 模块，在 27MHz 时钟下把 Y/CbCr 像素流打包成标准 BT.656 时序，另外配了行场格式、EAV/SAV、保护位逻辑的说明文档，以及 ModelSim 仿真。目标验证平台写得很明确：5CEFA5U19I7N 加 LMH0340 这套组合。适合正在做视频类板卡、想搞清楚标清 SDI 是怎么从并行码流长出来的开发者，也适合拿它当课程设计的选题底稿——模块不大，但行场时序、状态机、跨时钟域这几样一个都不少。

2. 协议底子先打牢：BT.656 的行场结构与 AV_GEN_CBB 的接口面

2.1 一行 1728 个时钟：EAV、消隐、SAV、有效数据怎么分段

先把账算清楚，后面看代码才不会晕。PAL 的行频是 15625Hz，一行 64μs；时钟给 27MHz，64μs × 27MHz = 1728，这就是H_LENGTH = 1728的来历。一帧 625 行，625 × 64μs = 40ms，正好 25 帧每秒。这两个数字对不上，后面所有波形都是错的。

这 1728 个时钟不是全给像素的。720 个像素，每个像素要送一个亮度 Y 和一路色度 Cb/Cr，Cb 和 Cr 是交替送的，所以一行有效样本是 720 × 2 = 1440 个。1728 - 1440 = 288，这 288 个时钟就是行消隐的全部家当，也就是参数H_BLANK_LENGTH = 288。它内部还要再切：

顺序是 EAV 在前、SAV 在后，这点和很多人先入为主的印象相反。因为 BT.656 的行是以"上一行的结束"作为本行起点的，EAV 结束的是上一行，SAV 开启的是这一行。代码里hcnt从 0 数到 1727，0~3 送 EAV，4~283 送填充，284~287 送 SAV，288~1727 送有效数据，跟这张表完全对齐。hcnt == 0时先出 0xFF，hcnt为 1、2 时出 0x00，hcnt == 3时出 XY 字节——这个四拍节奏在代码里出现了两次，一次给 EAV 一次给 SAV，是最容易被抄错的地方。

2.2 F/V/H 与 P3~P0：四个保护位不是随便凑的

XY 那个字节才是一行里信息密度最高的地方。它的 bit7 固定为 1，bit6 是 F（场标志），bit5 是 V（垂直消隐标志），bit4 是 H（水平消隐标志），低四位 P3~P0 是保护位。代码里这一句写得很直白：

assign P3 = V ^ H; assign P2 = F ^ H; assign P1 = F ^ V; assign P0 = F ^ V ^ H; SYNC_BYTE <= {1'b1, F, V, H, P3, P2, P1, P0};

保护位的用途是给接收端做一致性校验。收端收到 XY 后，用收到的 F/V/H 重新算一遍 P3~P0，跟收到的四位比对，对不上就认为这一行/这一场的同步信息不可信，直接丢弃或保持上一状态。这套机制在并行短线上用处不大，但一旦上了电缆、经过均衡和时钟恢复，误码是常态，保护位就是最后一道保险。有个细节值得记：当 F=V=H 三者全同（全 0 或全 1）时，P3=P2=P1=0、P0=1，这是 BT.656 里唯一一个"保护位不全为 0"的退化组合，写校验逻辑时别把它当异常。

F/V/H 三位的语义也要咬死。F=0 是奇数场（场 1），F=1 是偶数场（场 2），代码里vcnt == 0清 F、vcnt == 312置 F，一帧 625 行被切成 0~311 和 312~624 两段，前半场后半场各占约 312 行，符合 625/50 的交错结构。V=1 表示处在垂直消隐期，V=0 表示有效视频期。场 1 的有效行是 23~310，场 2 的有效行是 336~623，这个行号范围在文档里专门列了一节，也是V_BLANK_START1 = 23、V_BLANK_START2 = 336两个参数的来源。H=1 表示行消隐期，H=0 表示行有效期。三位组合起来，接收端不用看任何别的信号就能知道当前这一拍是"第几场的第几行的哪个位置"。

2.3 模块端口与参数表：改分辨率之前先认清这些旋钮

AV_GEN_CBB的端口不多，但每一个都不能想当然。下表是我按代码逐个核对过的：

data_BT656是{DATA, 2'b00}拼出来的 10bit，低两位恒为 0。这对应 BT.656 的 10bit 映射规则：8bit 数据左移两位，中间值 0x80（128）映射到 0x200（512），这样量化电平的对应关系跟 10bit 分量标准一致。如果你在接收端按 8bit 直接截高 8 位，图像会暗一截，因为动态范围被压了。

还有三个派生参数是代码里现算的，它们决定了图像在 720×576 有效区里怎么摆：

REG_H_START = H_BLANK_LENGTH + ((H_LENGTH - H_BLANK_LENGTH)/2 - IMG_WIDTH); REG_V_START1 = V_BLANK_START1 + (576 - IMG_HEIGHT)/4; REG_V_START2 = V_BLANK_START2 + (576 - IMG_HEIGHT)/4;

代入默认值：REG_H_START = 288 + (720 - 640) = 368，像素从 368 号时钟开始取，对应有效区里第 40 个像素，左右各留 40 像素黑边，居中。REG_V_START1 = 23 + (576-512)/4 = 39，每场有效 288 行，图像每场 256 行，(288-256)/2 = 16，所以从场 1 第 39 行开始，上下各留 16 行。这两个式子看着绕，其实是同一件事的两种写法：(H_LENGTH-H_BLANK_LENGTH)/2就是半行的有效样本数 720，(576-IMG_HEIGHT)/4之所以除以 4 而不是 2，是因为 576 是整帧行数，而每场只有 288 行，居中偏移要再折半。

3. 核心代码拆解：一个 27MHz 时钟下跑完的编码器

3.1 行场计数器：hcnt/vcnt 怎么被 syn_in_r 对齐到帧起点

整个模块的自由运行基准就是这两个计数器，别的信号全是它们的函数。原码里hcnt、vcnt都是 12bit，因为 1728 和 625 都超过 10bit，用 12bit 是稳妥的。计数器部分我按原逻辑重写了一遍，加了注释：

always @(posedge clk_27) begin if (rst_27) begin hcnt <= 12'd0; vcnt <= 12'd0; syn_d1 <= 1'b0; syn_d2 <= 1'b0; end else begin // 两级寄存，把外部同步打成单拍脉冲 syn_d1 <= syn_in_r; syn_d2 <= syn_d1; if (syn_d1 && !syn_d2) begin // 检测到同步上升沿 hcnt <= 12'd0; // 行场同时归零，锁定帧起点 vcnt <= 12'd0; end else if (hcnt == H_LENGTH - 1) begin hcnt <= 12'd0; // 一行数满 1728 拍，回卷 vcnt <= (vcnt == V_LENGTH - 1) ? 12'd0 : vcnt + 12'd1; end else begin hcnt <= hcnt + 12'd1; end end end

这里的关键是syn_d1 && !syn_d2这个边沿检测。为什么要两级寄存？因为syn_in_r是从模块外进来的，跟clk_27没有建立好的时序关系，直接拿来当异步复位会让计数器出现亚稳态，仿真里看不出来，上板就是随机丢帧。打两拍之后，亚稳态概率被压到可接受范围，同时把任意宽度的外部脉冲整形成严格一拍宽的使能。

代价是同步信号必须比一个时钟周期宽。如果外部给的syn_in_r是个窄于 37ns 的毛刺，两级寄存可能只采到一次甚至一次都采不到，计数器就永远等不到归零。我一般会在外部先把同步信号展宽到至少两个 27MHz 周期再送进来，这是血泪经验。

还有一个隐含约束：syn_in_r归零的是hcnt和vcnt两个计数器，也就是说它要求外部同步脉冲恰好落在行首。如果你的同步源是摄像头的 VSYNC，通常它跟 27MHz 像素时钟不是同源，落点会漂。工程上常见的做法是用一个 PLL 把摄像头时钟锁到同一参考上，或者干脆让AV_GEN_CBB自由运行、把外部同步只用来做相位微调。原设计显然是前者假设——syn_in_r跟clk_27同源。

3.2 H/V/F 三个标志位的生成与消隐区间

计数器跑起来之后，H/V/F 就是三段纯粹的比较逻辑。原码写法比较紧凑，我把三个 always 块合并成一个看，逻辑更清楚：

always @(posedge clk_27) begin if (rst_27) begin H <= 1'b0; V <= 1'b1; F <= 1'b0; end else begin // H：行消隐区拉高，覆盖 hcnt 0~286 H <= (hcnt < H_BLANK_LENGTH - 1) ? 1'b1 : 1'b0; // V：两场各有一段垂直消隐，进入时清 0，288 行后置 1 if (vcnt == V_BLANK_START1 - 1 || vcnt == V_BLANK_START2 - 1) V <= 1'b0; else if (vcnt == V_BLANK_START1 + 287 || vcnt == V_BLANK_START2 + 287) V <= 1'b1; // F：前半帧为 0，后半帧为 1 if (vcnt == 0) F <= 1'b0; else if (vcnt == 312) F <= 1'b1; end end

H的判据用的是hcnt < H_BLANK_LENGTH - 1，也就是 0~286 为 1，287 开始为 0。为什么不是 0~287？因为hcnt == 287那一拍已经在送 SAV 的 XY 字节了，SAV 里 H 位必须是 0，所以 H 要提前一拍落下。这个"提前一拍"的思路在整段代码里反复出现，是理解它的钥匙——所有标志位都是"为下一个时钟要输出的内容做准备"，而不是描述当前这一拍。

V的边界要特别小心。vcnt == V_BLANK_START1 - 1即 22 时清 0，vcnt == V_BLANK_START1 + 287即 310 时置 1，中间覆盖 22~309 共 288 行。而文档里写的有效行是 23~310。这两组数字差了一行，是hcnt/vcnt从 0 开始计数、而行号从 1 开始计数的经典错位。在仿真波形上表现为有效区的第一行和最后一行各有一半落在 V=0 区间外，肉眼看不出，但拿标准 BT.656 分析仪一测就会报场消隐长度不对。改法很简单：把两个比较值都加 1，让 V=0 覆盖 23~310。这也是我在第 5 章要专门说的一条坑。

F的翻转点定在 312，是 625 行对半分再取整的结果。严格按 625/50 的交错结构，场 1 是 312.5 行、场 2 是 312.5 行，数字电路做不出半行，只能一场 312 一场 313 交替。原码固定 312，长期跑下来帧率会差一点点，但对于本身就不做模拟同步输出的纯数字 SDI 链路，这个误差可以接受——接收端是认 SAV/EAV 里的 F 位来分场的，不认行数。

3.3 同步字节与数据选择：EAV/SAV 与 Y/CbCr 复用的那一套 if-else

这一段是整个模块的输出级，一个 1728 路的大选择器，优先级从高到低排下来：

always @(posedge clk_27) begin if (rst_27) begin DATA <= 8'd0; end else begin if (hcnt == 0) DATA <= 8'hff; // EAV 前导 else if (hcnt < 3) DATA <= 8'h00; // 两个 0x00 else if (hcnt == 3) DATA <= SYNC_BYTE; // EAV 的 XY else if (hcnt < 284) DATA <= hcnt[0] ? 8'h10 : 8'h80; // 消隐填充：Y=0x10, C=0x80 else if (hcnt == 284) DATA <= 8'hff; // SAV 前导 else if (hcnt < 287) DATA <= 8'h00; else if (hcnt == 287) DATA <= SYNC_BYTE; // SAV 的 XY else begin if (req_img_h) DATA <= hcnt[0] ? crcb : y; // 有效区：奇拍送 C，偶拍送 Y else DATA <= hcnt[0] ? 8'h10 : 8'h80; // 未请求区域补消隐值 end end end

hcnt[0]这个用法很省资源：用行计数的最低位当时钟分频用，偶拍走一个分支、奇拍走另一个。消隐区里偶拍送 0x80（色度中值）、奇拍送 0x10（亮度黑电平），跟 BT.656 对消隐期的规定一致。有效区里反过来，偶拍送y、奇拍送crcb，也就是 Y 在前、C 在后。

这里有个必须咬死的细节：BT.656 规定有效数据的第一个样本是 Cb，不是 Y。顺序是 Cb Y Cr Y Cr Y…… 代码里hcnt[0]为 1 时送crcb、为 0 时送y，看起来是 Y 在前。但结合req_img_h的赋值时机（下一节细说），实际生效的数据是从hcnt = 369开始的，369 是奇数，第一拍送的就是crcb，正好对上。这种"靠相位差把顺序掰正"的写法很精巧，也很脆——你要是把REG_H_START改成奇数，整个颜色就反了，图像会呈现诡异的偏色，而且因为 Cb/Cr 互换后视觉上仍然是"有颜色的图"，新手很难第一眼判断出是这里错了。

SYNC_BYTE只在hcnt == 3和hcnt == 287两个时刻被采样进DATA，而SYNC_BYTE本身是每个时钟都在更新的，等于说它一直在算、只在两处被取用。这不算浪费，因为保护位必须在 XY 输出那一拍是最新的，提前算好反而避免了组合逻辑毛刺。

3.4 图像请求握手：req_img_v / req_img_h 的居中算法

req_img_v和req_img_h是给外部图像源（FIFO、DDR 读控制器、测试图案发生器）看的两个握手信号。它们决定了图像在屏幕上的位置和大小：

always @(posedge clk_27) begin if (rst_27) begin req_img_v <= 1'b0; req_img_h <= 1'b1; end else begin // 行请求：到起点时跟随场请求，走满 2×IMG_WIDTH 拍后落下 if (hcnt == REG_H_START) req_img_h <= req_img_v; else if (hcnt == REG_H_START + IMG_WIDTH * 2) req_img_h <= 1'b0; // 场请求：两个场各拉起 IMG_HEIGHT/2 行 if (vcnt == REG_V_START1 || vcnt == REG_V_START2) req_img_v <= 1'b1; else if (vcnt == REG_V_START1 + IMG_HEIGHT/2 || vcnt == REG_V_START2 + IMG_HEIGHT/2) req_img_v <= 1'b0; end end

req_img_h <= req_img_v这一句是整个模块里最巧的一笔。行请求不自己判断"这一行要不要图"，而是直接抄场请求的值——场请求有效，这一行到点就拉高；场请求无效，这一行就保持低。省掉了一个与门，也保证了行场两级请求天然同步，不会出现"场说不要、行说要"的矛盾状态。

IMG_WIDTH * 2这个乘法别忽略。行请求的持续长度是像素数乘 2，因为一个像素占两个时钟（Y 一个、C 一个）。默认 640 像素对应 1280 拍，从hcnt = 368数到 1647。有效区总共 1440 拍（288~1727），1280 拍占 88.9%，两边各留 80 拍空白——正好是 40 个像素的黑边，跟前面算的居中偏移对得上。

IMG_HEIGHT/2同理，每场请求 256 行，两场加起来 512 行，跟IMG_HEIGHT = 512一致。这说明IMG_HEIGHT参数的口径是"整帧行数"，不是"每场行数"，用的时候别填错。填 576 就是满屏，此时(576-576)/4 = 0，场 1 从第 23 行开始请求 288 行，一直到 310 行，正好铺满整个有效区。

三个派生参数和两个请求信号的配合，本质上是一个"把任意尺寸的图像居中贴到 720×576 画布上"的定位器。想改成左上角对齐，把REG_H_START直接写成H_BLANK_LENGTH、REG_V_START1直接写V_BLANK_START1就行，其余逻辑不用动。

4. 仿真验证：在 ModelSim 里把一帧 625 行完整跑出来

4.1 testbench 骨架：时钟、复位、同步与假图像源

这套代码不上板也能验证个七七八八，前提是 testbench 得把三件事喂对：27MHz 时钟、帧同步脉冲、符合握手时序的假图像。下面是我照着原设计搭的一份 tb，能直接跑：

`timescale 1ns/1ps module tb_av_gen; reg clk_27 = 0; reg rst_27 = 1; reg syn_in_r = 0; reg [7:0] y = 8'h10; reg [7:0] crcb = 8'h80; reg [9:0] pix_x = 0; wire req_img_v, req_img_h, odd_even; wire [9:0] data_BT656; // 27MHz，周期 37.037ns always #18.5185 clk_27 = ~clk_27; // 假图像源：只在行请求有效时推进横坐标，产生横向灰阶 always @(posedge clk_27) begin if (!req_img_h) begin pix_x <= 10'd0; y <= 8'h10; crcb <= 8'h80; end else begin pix_x <= pix_x + 10'd1; y <= pix_x[7:0]; // 0~255 循环，肉眼可辨的渐变 crcb <= 8'h80; // 固定中值，先排除色度干扰 end end AV_GEN_CBB #( .IMG_WIDTH (640), .IMG_HEIGHT(512) ) dut ( .clk_27 (clk_27), .rst_27 (rst_27), .syn_in_r (syn_in_r), .req_img_v (req_img_v), .req_img_h (req_img_h), .y (y), .crcb (crcb), .odd_even (odd_even), .data_BT656 (data_BT656) ); // 数据落盘，供后续脚本还原成图像 integer fp; initial fp = $fopen("bt656_out.txt", "w"); always @(posedge clk_27) if (!rst_27) $fwrite(fp, "%0d\n", data_BT656); // 复位后每 40ms 给一拍同步，模拟 25Hz 帧率 initial begin #200 rst_27 = 0; forever begin @(posedge clk_27); syn_in_r <= 1'b1; @(posedge clk_27); syn_in_r <= 1'b0; #39999963; // 补足到约 40ms end end initial begin #3000000000; // 跑 3 秒，约 75 帧 $fclose(fp); $stop; end endmodule

时钟用always #18.5185翻转，半周期 18.5185ns 对应 27.0MHz，误差在 1e-5 量级，跑几十帧看不出漂移。syn_in_r给一拍宽，正好被两级寄存采到，触发器边沿检测能命中。

假图像源这里只驱动了y，crcb固定 0x80。这是有意的：第一次跑仿真先看亮度通道，色度固定中值不会干扰对同步和定位的判断。等 Y 通道的波形对上了，再把crcb换成一个随场变化的常量（比如场 1 给 0x40、场 2 给 0xC0），就能一眼看出奇偶场是否分对了。

$fwrite落盘那一段是把 10bit 数据原样写成文本，一行一个十进制数。文件会很大——3 秒约 75 帧 × 625 行 × 1728 拍 ≈ 8100 万行，几百兆。实际调试时我一般只抓前两帧，把#3000000000改成#90000000，文件降到 20MB 左右，Python 处理起来不吃力。

4.2 波形怎么看：五个必须核对的关键点

仿真跑起来之后，别急着看数据对不对，先按顺序把这五个点逐个确认，任一处不对后面都不用看：

第一，hcnt在syn_in_r上升沿之后是不是从 0 开始。如果它继续往前跑，说明边沿检测没命中，多半是同步脉冲宽度不足或者落在时钟沿上被漏采。

第二，vcnt能不能走满 0~624 再回卷。如果它在某个固定值反复归零，说明syn_in_r的周期比一帧短，把计数器中途打断了。

第三，req_img_v的高电平区间是不是 256 行、req_img_h的高电平区间是不是 1280 拍。拿光标卡一下起止点，跟第 3.4 节算的值比对。

第四，data_BT656在hcnt == 0那一拍是不是 0x3FC（0xFF 左移两位）。如果不是，检查{DATA, 2'b00}有没有漏写。

第五，odd_even的跳变点跟vcnt == 312是否对应。这一位是给外部做奇偶场区分的，错一位整场图像就上下颠倒。

4.3 用脚本把 10bit 数据还原成可视帧

波形看时序，脚本看内容。落盘的数据拿 Python 按 1728 一拍切开，跳过前 288 拍消隐，取有效区里的 Y 样本，就能拼出一张 720×576 的灰度图：

H_LENGTH = 1728 # 一行总时钟数 H_BLANK = 288 # 行消隐长度 V_LENGTH = 625 # 一帧总行数 WIDTH = 720 # 有效像素数 with open("bt656_out.txt") as f: raw = [int(line) for line in f] # 10bit 还原成 8bit：右移两位，0x200 对应 0x80 samples = [v >> 2 for v in raw] frame = [] for line in range(V_LENGTH): base = line * H_LENGTH row = samples[base + H_BLANK : base + H_LENGTH] # 有效区是 Cb Y Cr Y 交替，取奇数下标拿 Y frame.append(row[1::2][:WIDTH]) # 输出 PGM，任何看图软件都能开 with open("frame.pgm", "w") as f: f.write(f"P2\n{WIDTH} {V_LENGTH}\n255\n") for row in frame: f.write(" ".join(str(min(v, 255)) for v in row) + "\n")

这段脚本跑通，基本就能确认图像数据通路没问题。如果图上下颠倒，是 F 位的场序反了；如果左右偏移几十像素，回去查REG_H_START；如果整张图跟雪花一样，多半是req_img_h的起止点跟hcnt错位，取到了消隐值。

5. 避坑与排查：这套代码上手最容易翻车的五处

5.1 时序类：非阻塞赋值留下的两个相位陷阱

坑一：SAV 的 XY 里 H 位是 1，接收端把 SAV 认成 EAV。

现象很隐蔽：仿真波形上SYNC_BYTE的数值看着没问题，data_BT656也规规矩矩输出了 FF 00 00 XY，但把 XY 拆开看 bit5（也就是 H 位）是 1，而 SAV 里的 H 必须是 0。拿标准 BT.656 分析仪一测，整帧报"同步字非法"。

原因是H的更新判据写的是hcnt < H_BLANK_LENGTH - 1，即hcnt到 287 时才把 H 置 0；而SYNC_BYTE恰好在hcnt == 287那一拍被采样，此时 H 还是上一拍的值 1。非阻塞赋值让H的新值晚了一拍才可见，正好错过。

解决是把 H 的翻转再提前一拍：判据改成hcnt < H_BLANK_LENGTH - 2，让 H 在 286 就落下 0，287 采样时读到的是新值。改完之后 EAV 那边也要一起看——EAV 在hcnt == 3采样，此时 H 应该是 1，判据改了之后 3 < 286 仍然为 1，不受影响。

坑二：图像整体左移一个像素，首列是黑边。

现象是还原出来的图跟源图对不上，整体往左错一格，最右边多出一列消隐值 0x80。

根子在req_img_h的赋值时机。hcnt == REG_H_START那一拍，req_img_h <= req_img_v是非阻塞赋值，真正变成 1 要到下一拍，也就是hcnt = REG_H_START + 1。而数据选择器判断的是if (req_img_h)，用的是当前值，所以hcnt = REG_H_START这一拍走的是 else 分支，输出消隐值。等到hcnt = REG_H_START + 1才开始送真数据，一个像素的错位就这么产生了。

解决有两条路：要么把REG_H_START减 1 提前拉起，要么把数据选择器改成if (hcnt >= REG_H_START && hcnt < REG_H_START + IMG_WIDTH*2)，用计数范围判断而不是握手信号。我倾向前者，改动小，不影响别的逻辑。

5.2 数据类：颜色反了、图像偏了、同步丢了

坑三：图像颜色诡异，红绿蓝全错位。

现象是 Y 通道正常、图像轮廓清晰，但颜色一塌糊涂，蓝色区域发红、红色区域发蓝。新手第一反应是色度矩阵算错了，其实 90% 是 Cb/Cr 顺序反了。

回到第 3.3 节的分析：有效区的第一拍应该送 Cb，靠的是REG_H_START = 368是偶数、req_img_h晚一拍生效导致实际从 369 开始，369 是奇数，hcnt[0]为 1，送crcb。这个链条只要断一环——比如你把IMG_WIDTH改成 641，REG_H_START变成 367，奇偶性变了——第一拍就变成 Y，整行的 Cb/Cr 全部互换。

解决建议是把REG_H_START强制对齐到偶数：REG_H_START = (… ) & ~1，或者更彻底一点，别依赖相位巧合，改成用y和crcb两根线各自的有效标志来做选择，把顺序问题显式化。

坑四：图像上下不对称，上面留 14 行黑边、下面留 18 行。

现象是明明算好居中，实际看图偏上几行。

原因是(576 - IMG_HEIGHT) / 4这个整除。如果IMG_HEIGHT不是 4 的倍数，商会被截断，偏移量取整偏小，图像整体上移。比如 `IMG_HE

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