企业官网建设流程全解析

1. 一块采集板上的横向拉丝，把 field 这个冷门字段翻了出来

几年前调一块支持标清输入的采集板，现象很怪：静态画面看着挺清楚，一旦镜头里有横向移动的物体，比如一辆车开过，物体边缘就出现一排像梳子一样的锯齿；画面整体上下移动时更明显，能看到水平方向的细横纹在水波一样抖动。第一反应是曝光时间太长导致的运动模糊，换了快门没用；第二反应是带宽不够、数据错位，把分辨率从 D1 一路降到 CIF，锯齿依然在。最后翻驱动里vidioc_try_fmt_vid_cap的实现，看到一行pix->field = V4L2_FIELD_NONE;，改成V4L2_FIELD_INTERLACED并把 upper layer 的去隔行打开，问题当场消失。

这件事之后，我对v4l2_field的态度从"结构体里一个没什么人看的枚举"变成了"每次接新板子、新 sensor、新解码芯片都第一个确认的字段"。它确实只是struct v4l2_pix_format里的一个成员，类型是enum v4l2_field，位置在pixelformat和bytesperline之间，看着毫不起眼。但它决定了驱动交给你的这块内存到底怎么解释——里面装的是完整一帧，还是只有半帧；两场是按行交织排的，还是上下分块排的；时间上先到的是顶场还是底场。解释错了，后面所有的图像处理、缩放、编码都是错的。

这篇内容是写给正在做视频采集相关工作的朋友的：可能是做嵌入式 Linux 摄像头的驱动工程师，可能是写 V4L2 应用层采集模块的开发者，也可能是想在本地把摄像头数据取出做算法验证的算法同学。只要你的采集链路里出现过"梳状锯齿""上下半帧亮度不一致""画面运动时撕裂""每两帧丢一帧"这类症状，field大概率就是你要查的位置。下面我会把场的物理含义、V4L2 里十种取值的真实内存布局、驱动侧该怎么填、应用侧拿到之后该怎么处理、以及我自己踩过的几个坑，一个一个拆开讲。

2. 先把"场"这个概念钉死：一行图像的传输顺序问题

2.1 隔行扫描不是历史包袱，是带宽账本算出来的结果

理解field的前提是理解隔行扫描（interlaced scan）。早年模拟电视信号在有限带宽下要把图像送出去，做法是把一帧拆成两半按时间先后发送：先发第 0、2、4、6……这些偶数索引行，再发第 1、3、5、7……这些奇数索引行。每一半叫做一个场（field），先发的那一半叫顶场（top field），后发的那一半叫底场（bottom field）。两场在时间上错开半个帧周期，人眼因为视觉暂留会把它们合成一幅完整画面。

这笔账很直白：一帧 720×576 的图像，如果按 25 帧/秒逐行传，需要传输 25 次完整帧；如果按隔行传，同样是 25 帧/秒的有效画面，但每次只传一半行数，瞬时带宽直接减半，代价是运动物体在时间上错位。用生活化的说法就是：你没法一次搬完一箱苹果，那就分两趟搬，每趟半箱，看着好像一直在动，但两趟之间箱子里的东西已经变了位置。

在 V4L2 的语境下，v4l2_field要回答的正是这样的具体问题：

1. 这一个缓冲区里装的是一整帧，还是只有一场？
2. 如果是整帧，两场是按行交错排在同一块内存里，还是先放完顶场再放底场？
3. 如果只有一场，那是顶场还是底场，顺序由谁决定？

这三个问题的答案不同，你从mmap拿到的那块内存的解释方式就完全不同。把它当整帧处理，实际只有半帧数据，画面下半部分就是垃圾；把交织布局当分块布局处理，画面会变成标准的"梳子"。

2.2 顶场和底场的行索引约定，这里最容易差一行

V4L2 对顶场和底场的定义跟图像行号绑定，规则是这样的：把图像从第 0 行开始编号，V4L2_FIELD_TOP 指的是包含第 0 行的那一场，也就是所有偶数索引行；V4L2_FIELD_BOTTOM 指的是包含第 1 行的那一场，即所有奇数索引行。

这个约定看上去平凡，但在两个地方特别容易出错。

第一个地方是高度为奇数的情况。比如某个格式的高度是 1081 行，那么顶场有 541 行，底场只有 540 行。如果代码里习惯性地写height / 2，顶场就少取了一行，画面上会看到最底部一条细线闪。正确的取法是顶场(height + 1) / 2，底场height / 2。这个 off-by-one 我在两三个项目上都见过，而且因为影响只有一行像素，经常被当成"面板坏线"排查很久。

第二个地方是 BT.656 这类并口视频总线的场标志位。这类总线在每帧的时序里带一个 F 位，用来标识当前传输的是顶场还是底场，但它标识的"顶场"跟你图像数组里的第 0 行不一定对应。有些前端芯片默认做了一次行重排，有些没做。稳妥的验证方式是：对着一个上黑下白的测试卡，把两场分别 dump 出来看，白的在哪一场，那一场就是底场；如果反了，要么驱动里补一次翻转，要么在应用层调换。

2.3 逐行视频的 field 取值，为什么很多摄像头报 NONE

现在的 CMOS sensor 绝大多数是逐行扫描输出，一次给一整帧，不存在场的时间错位。这种情况下field就应该填V4L2_FIELD_NONE，含义是"这块缓冲区是一个完整的、逐行的帧，没有场的概念"。

USB 摄像头走 UVC 协议，绝大多数情况报的都是V4L2_FIELD_NONE，这一点符合直觉。但这里有个反直觉的现象值得记住：报NONE不代表画面里一定没有隔行残留。有些低成本的模拟转 USB 方案，内部把隔行信号做了很粗糙的行平均就送出来了，field老老实实报NONE，但画面上依然有轻微的梳状痕迹，因为它在硬件层面把两场混了，而混的方式不好。这类问题靠改field是解决不了的，只能靠换硬件或者在后端做更聪明的处理。

3. 十种取值的真实内存布局：INTERLACED、SEQ、ALTERNATE 到底差在哪

enum v4l2_field定义在linux/videodev2.h里，一共十个值，编号从 0 到 9。我把它们整理成一张表，重点看"一个 buffer 装几场"和"内存里怎么排"这两列，这两列决定了你后续所有的偏移计算。

3.1 INTERLACED 和 SEQ_TB 的区别，是行交织还是块拼接

这是最容易混的一对。用一张高度 8 行的图举例，行号 0 到 7，偶数行属于顶场（记为 T），奇数行属于底场（记为 B）。

V4L2_FIELD_INTERLACED（以及带_TB/_BT后缀的变体）在内存里的排布是按行交织的：

内存偏移 0 行0 (T) 内存偏移 1 行1 (B) 内存偏移 2 行2 (T) 内存偏移 3 行3 (B) 内存偏移 4 行4 (T) 内存偏移 5 行5 (B) 内存偏移 6 行6 (T) 内存偏移 7 行7 (B)

V4L2_FIELD_SEQ_TB则是分块的：

内存偏移 0 行0 (T) 内存偏移 1 行2 (T) 内存偏移 2 行4 (T) 内存偏移 3 行6 (T) 内存偏移 4 行1 (B) 内存偏移 5 行3 (B) 内存偏移 6 行5 (B) 内存偏移 7 行7 (B)

两者的height都是 8，sizeimage都是bytesperline * 8，总量一样，排布完全不同。如果你的代码把 SEQ_TB 当 INTERLACED 处理，直接按行送进缩放器或者编码器，得到的结果就是上下两半各自被拉抻、中间有明显的分界，画面看起来像"上半张脸和下半张脸错位"。反过来把 INTERLACED 当 SEQ_TB 处理，画面会因为行序被打乱而出现密集的锯齿。

区分办法其实不难，但要主动去做：拿一段横向运动的素材，按两种解释各解一遍，哪种看起来正常就是哪种。或者更严谨一点，把 raw 数据按行拆开做相关性分析，这个我在第 5 节会给具体做法。

3.2 ALTERNATE 模式下 height 的含义是个坑

V4L2_FIELD_ALTERNATE是最需要小心的一种。它的语义是：驱动每次只交给你一场，顶场和底场分别在不同的 buffer 里，按时间顺序到达，顶场先。应用层如果要得到完整帧，得自己把两场拼起来。

问题在于height字段的含义。规范里的约定是：height仍然表示完整帧的高度，但每个 buffer 里实际只包含一场的数据。也就是说，如果height是 576，每个 buffer 里有效的行数只有 288。

那么sizeimage该怎么填？这里就出现分歧了。有的驱动老老实实填bytesperline * (height / 2)，有的驱动为了 mmap 分配方便，填bytesperline * height，前一半有效后一半浪费。这两种做法我都遇到过，而且从应用层的VIDIOC_G_FMT返回结果上看不出区别，因为height字段都是一样的。

后果很直接：如果你按bytesperline * height去读bytesperline * (height/2)大小的数据，读到的是缓冲区尾部的一堆未初始化内存，严重的会直接越界访问触发段错误；如果你反过来按半帧读一个分配了两倍空间的 buffer，不会崩，但你的拼接逻辑会少处理一半数据，画面变成只显示上半部分。

我的处理习惯是：拿到 ALTERNATE 的格式之后，先申请少量 buffer 抓两帧，把两帧的字节数分别打印出来，跟bytesperline * height和bytesperline * (height / 2)对比一下，就知道这个驱动是哪种。这个"实测一次"的动作三十秒能做完，比读驱动源码还快。

3.3 INTERLACED 和 INTERLACED_TB / BT 的差别：谁先谁后

老代码里常见V4L2_FIELD_INTERLACED，它的含义是"这是交织布局，但具体哪一场在时间上先到，驱动自己知道，我不承诺"。后来内核里补了V4L2_FIELD_INTERLACED_TB和V4L2_FIELD_INTERLACED_BT，把时序信息明确出来。

这个差别在做精确的时间对齐时很重要。比如你要把视频和另一路传感器数据做同步，或者要算运动物体的真实位移，场的先后顺序直接影响时间戳跟像素行的对应关系。_TB表示顶场先到，_BT表示底场先到。接收端如果不关心时序，用INTERLACED就够了；要做精确处理，应该尽量用带后缀的形式，让驱动把话说清楚。

不过现实情况是，很多驱动只实现了INTERLACED，你传_TB进去它在try_fmt里给你改回INTERLACED。这就引出下一个话题：try_fmt返回值和field的关系，一定要逐字段核对，不能只看格式。

3.4 TOP 和 BOTTOM 单独出现时，说的是"这一次只给了一场"

V4L2_FIELD_TOP和V4L2_FIELD_BOTTOM在v4l2_pix_format里出现得不多，因为格式描述的一般是"这一类帧长什么样"。它们更常见的舞台是struct v4l2_buffer的field成员：在VIDIOC_DQBUF返回时，驱动告诉你这一块具体的 buffer 里装的是顶场还是底场。

这个区别要分清：v4l2_pix_format.field是格式级别的、相对静态的约定；v4l2_buffer.field是每帧级别的、动态的事实。在ALTERNATE模式下，这两者配合使用：格式里报ALTERNATE，说明"我会一场一场给你"；每块 buffer 的field报TOP或BOTTOM，告诉你"这一块具体是哪一场"。

4. 驱动侧怎么填：从 sensor 时序一路传到 video node

写驱动的人最容易犯的错，是在try_fmt里给所有格式无脑填V4L2_FIELD_ANY，觉得"让上层自己判断去"。这个想法是错的，因为V4L2_FIELD_ANY的语义是"应用侧不关心、让驱动选"，它是应用侧传参用的值，驱动在VIDIOC_G_FMT/VIDIOC_S_FMT的返回里应该给出一个确定值，而不是把ANY原样吐回来。

4.1 从数据源的物理特性出发判断

驱动侧填什么，取决于数据源本身：

• 逐行 CMOS sensor，一次输出整帧：填V4L2_FIELD_NONE。这是现在最常见的情况，MIPI CSI-2 链路上的 sensor 基本都是这类。
• 模拟标清输入，经解码芯片输出 BT.656：填V4L2_FIELD_INTERLACED或带_TB/_BT后缀的变体，取决于解码芯片的场序设置。
• 硬件只支持分块布局（有些 DMA 引擎不能做行交错写）：填V4L2_FIELD_SEQ_TB或SEQ_BT，但你要清楚这是在用驱动能力去迁就硬件。
• 硬件每场触发一次 DMA 中断：可以考虑V4L2_FIELD_ALTERNATE，让应用层自己拼帧，驱动实现会简单很多。
• 格式本身就不携带场信息，比如某些压缩格式或者元数据格式：V4L2_FIELD_NONE。

判断依据不能靠猜，要看两处：sensor 或解码芯片的寄存器配置，以及 bridge/CSI 接收端的场标志处理。有些 SoC 的 CSI 接收器有专门的寄存器位来配置"F 位为 1 表示顶场还是底场"，这一位配反了，field写得再对画面也是反的。

4.2 在 try_fmt 里做规范化，而不是直接照抄

一个我比较推荐的写法，是在try_fmt里把场序做一次规范化，把"能力"和"请求"分开处理。下面这段代码是示意，is_progressive和hw_order这两个变量需要按你的硬件实际情况填：

static void normalize_field(struct v4l2_pix_format *pix, bool is_progressive, enum v4l2_field hw_order) { /* 逐行源：无论上层要什么，都只能是 NONE */ if (is_progressive) { pix->field = V4L2_FIELD_NONE; return; } switch (pix->field) { case V4L2_FIELD_ANY: /* 上层没提要求，用硬件默认的场序 */ pix->field = hw_order; break; case V4L2_FIELD_NONE: /* 上层要逐行，但硬件只能给隔行，这个请求没法满足 */ pix->field = hw_order; break; case V4L2_FIELD_INTERLACED: case V4L2_FIELD_INTERLACED_TB: case V4L2_FIELD_INTERLACED_BT: case V4L2_FIELD_SEQ_TB: case V4L2_FIELD_SEQ_BT: case V4L2_FIELD_ALTERNATE: /* 能力范围内，接受；但如果硬件布局固定，可以强制改写 */ if (!hw_supports_alternate() && pix->field == V4L2_FIELD_ALTERNATE) pix->field = hw_order; break; default: pix->field = hw_order; break; } }

这段代码的关键点不在于具体怎么分支，而在于驱动必须给出确定值。VIDIOC_S_FMT的语义是"我尽量满足你的要求，但满足不了我会改成我能做的"，应用侧拿到返回值必须重新读一遍。很多应用代码写成了这样：调完S_FMT直接开始采集，把之前G_FMT拿到的fmt结构体继续用。驱动改了field它不知道，于是所有后续计算全错。这属于经典错误，我在评审别人代码时至少见过十几次。

4.3 子设备链路上的 field 也要一路传对

走 media controller 的平台上，格式是从 sensor subdev 开始，经过 CSI receiver、ISP，最后到达 video node 的。每一级都有自己的v4l2_mbus_framefmt，里面同样有field字段。这条链路上任何一个环节把 field 丢了或者填错了，最终 video node 报出来的值就不可信。

v4l2_mbus_framefmt的field和v4l2_pix_format的field用的是同一个枚举，但语义略有差异：前者描述的是总线上传输的格式，后者描述的是内存里的排布。有些 bridge 驱动会把总线上的隔行格式在写入内存时改成逐行（用硬件做了一次去隔行），这时候两级的 field 就应该是不同的值：subdev 报INTERLACED，video node 报NONE。这是正常现象，不是 bug。

用media-ctl -p能把拓扑上每一级 pad 的格式都打出来，field也在里面。这个命令我排在调试工具的第一位，比v4l2-ctl用得还频繁，因为它能一眼看出是哪一级把信息改掉了。

5. 应用侧的处置逻辑：拿到 field 之后到底该干什么

5.1 NONE 就直接当整帧，别多此一举

最简单的情况：field是V4L2_FIELD_NONE，buffer 大小是bytesperline * height，按行连续读取即可。这时候不要画蛇添足去做任何场处理，尤其是不要写那种"为了保险起见做一次行混合"的逻辑，那只会让本来清晰的逐行画面变模糊。

唯一需要检查的是bytesperline和width的关系。很多硬件会对bytesperline做对齐，比如width是 1280，bytesperline被对齐成 1408。如果代码里按width * bytes_per_pixel去算行偏移，每一行都会错位，画面会呈现斜向的条纹。这个问题跟field无关，但经常和field一起出现，因为都是格式解析环节的疏漏。

5.2 INTERLACED 场景下的去隔行，三条路各有代价

如果field是交织类取值，你有三种处理思路：

我在实际项目里的默认选择是：如果后端是给人看的预览流，优先用硬件去隔行；如果后端是给算法用的分析流，优先"只取一场"，因为算法通常对垂直分辨率的敏感度低于对伪影的敏感度，插值引入的重影反而会干扰特征提取。这个取舍没有标准答案，取决于下游要做什么。

代码层面，把交织布局拆成两场，用双重循环按步长 2 取行就够了：

/* 把 V4L2_FIELD_INTERLACED 的 buffer 拆成两场，各占一半高度 */ void split_interlaced(const uint8_t *src, uint8_t *top, uint8_t *bottom, int width, int height, int bytesperline) { int top_rows = (height + 1) / 2; int bot_rows = height / 2; for (int i = 0; i < top_rows; i++) memcpy(top + i * bytesperline, src + (2 * i) * bytesperline, bytesperline); for (int i = 0; i < bot_rows; i++) memcpy(bottom + i * bytesperline, src + (2 * i + 1) * bytesperline, bytesperline); }

注意bytesperline要按实际值传，不要用width * bpp代替，前面说过的对齐问题在这里同样成立。

5.3 ALTERNATE 模式：拼场时必须用 buffer 自带的 field

ALTERNATE模式的正确姿势，是把每块 buffer 的v4l2_buffer.field当作权威依据来拼。伪代码长这样：

struct pending_frame { uint8_t *top; uint8_t *bottom; bool has_top; bool has_bottom; uint32_t seq_top; }; /* 在 DQBUF 之后调用 */ void handle_buffer(struct pending_frame *pf, const uint8_t *data, enum v4l2_field field, uint32_t sequence, size_t len) { switch (field) { case V4L2_FIELD_TOP: if (pf->has_bottom && sequence != pf->seq_top + 1) { /* 序号不连续，上一帧的底场跟这一帧的顶场不是一对，丢弃 */ pf->has_bottom = false; } memcpy(pf->top, data, len); pf->has_top = true; pf->seq_top = sequence; break; case V4L2_FIELD_BOTTOM: if (!pf->has_top) { /* 没有配对的顶场，丢掉 */ break; } memcpy(pf->bottom, data, len); pf->has_bottom = true; break; default: break; } if (pf->has_top && pf->has_bottom) { merge_fields(pf->top, pf->bottom); pf->has_top = pf->has_bottom = false; } }

这里有两个容易被忽略的点。

一是序号连续性检查。ALTERNATE模式下顶场和底场是两块独立的 buffer，序号是连续的。如果中间丢了一块，比如顶场序号是 100，下一个收到的却是序号 102 的顶场，说明 101 的底场丢了，这时候不能拿 102 的顶场去跟前面残留的底场拼，否则画面会是一半新一半旧的"穿越"效果。我见过一个项目就是没做这个检查，网络不好或者缓冲不足的时候偶尔出现半帧错位，排查了很久才定位到。

二是顶底场的行数不对称。前面提过，height为奇数时两场行数差一。拼帧的时候顶场写(height+1)/2行，底场写height/2行，写满即止，不要假设两边一样长。

6. 排查这条路上的四个真实坑，以及怎么绕过去

6.1 buffer 的 field 才是最终事实，格式里的只是约定

有一次排查一个"偶尔出现整帧画面上下颠倒"的问题，格式里报的是INTERLACED，代码也按交织处理，逻辑上没问题。最后打印每块 buffer 的field才发现，驱动在特定条件下会把field设成BOTTOM，意思是"这一帧我只有底场，顶场丢了"。应用代码完全没看这个字段，把只有底场的数据按完整帧解释，缺失的行就用上一帧的残留数据填，视觉上就表现为"上下两半来自不同时刻"，看起来像颠倒。

结论很清楚：v4l2_pix_format.field描述的是能力与约定，v4l2_buffer.field描述的是这一块内存的事实。两者不一致时，一定以 buffer 的为准。这个检查成本极低，DQBUF之后加一行比较打日志就行，建议在开发阶段默认打开。

6.2 S_FMT 之后不重新读回，驱动悄悄改了场序

这个坑值得单独说，因为它的隐蔽性太强。假设应用侧传了V4L2_FIELD_TOP，驱动支持不了单场，就在try_fmt里改成了V4L2_FIELD_INTERLACED，然后S_FMT返回。应用侧如果继续用自己构造的那份fmt结构体，就会以为拿到的是单场数据，按半帧去解析一个完整帧的 buffer，画面立刻错位。

正确做法只有一条：S_FMT返回后，要么用返回结构体覆盖本地副本，要么再调一次G_FMT核对。而且核对要逐字段，不能只比width、height、pixelformat。field恰恰是驱动最常"善意修改"的字段之一。

6.3 分辨率对齐与 bytesperline 的连锁反应

这个坑不直接来自field，但只要你在处理隔行数据，就一定会撞上。假设width = 1280，YUV422 格式每个像素 2 字节，硬件要求bytesperline按 256 字节对齐，于是bytesperline = 1536。如果你按1280 * 2 = 2560以外的算法（比如误算成 2560 而实际是 3072）计算行偏移，每一行都错位，画面会呈现明显的斜条纹，而这种斜条纹又容易被误判成隔行处理错了，白白在field上浪费半天。

判断方法很简单：把bytesperline和width * bpp打出来对比一次，不相等就说明有对齐填充，后续所有的偏移计算都必须用bytesperline。这个检查应该写进采集模块的初始化日志里，长期保留。

6.4 有些设备报 NONE，实际数据是隔行的

前面提过一次，这里展开说。低成本的模拟转 USB 方案、某些 SoC 内部做过粗略混合的 ISP 输出，都会让field报NONE而画面里仍有隔行痕迹。这类问题没法靠改field解决，但你可以通过观察来确认：把画面暂停在一帧上，看运动物体的边缘是否有水平方向的梳齿；或者把相邻两行做差分，如果差分呈现出明显的奇偶行规律，说明数据的组织方式仍然是隔行的。

确认之后的选择无非两条：一是在应用侧做一次软去隔行，代价是 CPU；二是换方案。我一般会先在应用侧加一个可开关的软去隔行，把功能跑通，再评估要不要换硬件，这样不至于卡在选型上。

7. 三把调试利器：把 field 打出来看，别靠脑补

7.1 v4l2-ctl：最快的一次确认

v4l2-ctl是最省事的入口，几条命令就能把当前格式和场序摸清楚：

# 查看当前视频节点的格式，field 会显示在输出里 v4l2-ctl -d /dev/video0 --get-fmt-video # 枚举支持的所有像素格式与分辨率 v4l2-ctl -d /dev/video0 --list-formats-ext # 尝试设置场序，注意这里只是"尝试"，实际值要再读一次确认 v4l2-ctl -d /dev/video0 --set-fmt-video=width=720,height=576,pixelformat=YUYV,field=interlaced # 设置完立刻回读，看驱动最终给了什么 v4l2-ctl -d /dev/video0 --get-fmt-video

输出里会有一行类似Field: Interlaced或者Field: None的内容。关键在于"设置完立刻回读"这一步，很多人只做了前面一半，以为设置成功就完事。实际上驱动完全可能把你设的interlaced改成none，或者把你设的seq-tb改成interlaced。

顺便说一句，v4l2-ctl --all能一次性把所有能力、格式、参数都打出来，新接手一块板子时先跑这一条，能省掉很多试错。

7.2 media-ctl：看清链路上每一级的场序

走 media controller 的平台上，v4l2-ctl只能看到最终的 video node，看不到中间环节。这时候用：

media-ctl -p -d /dev/media0

输出里每个 entity 的每个 pad 都会打出格式，包括field。我排查过一个"driver 报 interlaced 但画面是逐行"的问题，最后就是靠这个命令发现 CSI receiver 那一级已经用硬件做了去隔行，把 field 改成了none，而 video node 的驱动又把 field 硬编码回了interlaced。两级对不上，应用侧自然被误导。

7.3 自己写二十行代码，把 fmt 和 buffer 的 field 都打出来

v4l2-ctl覆盖不到v4l2_buffer的field，这个必须自己写。核心就三段：

#include <linux/videodev2.h> #include <sys/ioctl.h> #include <stdio.h> #include <string.h> static const char *field_name(enum v4l2_field f) { static const char *names[] = { "ANY", "NONE", "TOP", "BOTTOM", "INTERLACED", "SEQ_TB", "SEQ_BT", "ALTERNATE", "INTERLACED_TB", "INTERLACED_BT" }; return (f <= V4L2_FIELD_INTERLACED_BT) ? names[f] : "UNKNOWN"; } void dump_format(int fd) { struct v4l2_format fmt; memset(&fmt, 0, sizeof(fmt)); fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; if (ioctl(fd, VIDIOC_G_FMT, &fmt) < 0) { perror("VIDIOC_G_FMT"); return; } printf("fmt: %ux%u pixfmt=%.4s field=%s bytesperline=%u sizeimage=%u\n", fmt.fmt.pix.width, fmt.fmt.pix.height, (char *)&fmt.fmt.pix.pixelformat, field_name(fmt.fmt.pix.field), fmt.fmt.pix.bytesperline, fmt.fmt.pix.sizeimage); } void dump_buffer_field(int fd, struct v4l2_buffer *buf) { printf("buf[%u]: seq=%u field=%s bytesused=%u\n", buf->index, buf->sequence, field_name(buf->field), buf->bytesused); }

dump_format在初始化之后调一次，dump_buffer_field在每次DQBUF之后调。开发阶段把这两类日志常开，能省掉大量猜测。

7.4 用相关性分析验证内存到底是哪种布局

如果你手上只有一段 raw 数据，不知道它是交织还是分块，可以做一个很朴素但有效的统计：把数据按行切开，计算"第 i 行与第 i+1 行"的差异，再计算"第 i 行与第 i+2 行"的差异。如果画面是自然场景，同一场内的相邻行（行号差 2）在内容上更接近，不同场之间（行号差 1）因为时间错位会有更大差异。

import numpy as np def probe_interlace(raw_path, width, height, bytes_per_px=2, bpl=None): bpl = bpl or width * bytes_per_px data = np.fromfile(raw_path, dtype=np.uint8, count=bpl * height) data = data.reshape(height, bpl)[:, :width * bytes_per_px].astype(np.float32) d1 = np.mean(np.abs(data[0:-1:2] - data[1::2])) # 跨场相邻行差异 d2 = np.mean(np.abs(data[0:-2:2] - data[2::2])) # 同一场相邻行差异 print(f"跨场差异 d1={d1:.2f}, 同场差异 d2={d2:.2f}") if d2 > 0: print(f"比值 d1/d2 = {d1 / d2:.2f}") # 比值明显大于 1，且绝对值有量级差异，说明数据是隔行组织的 return d1, d2

这段代码不需要任何第三方库，有 numpy 就能跑。d1/d2明显偏离 1 就值得深挖。我一般把比值超过 1.5 作为"高度怀疑隔行"的阈值，具体数值跟场景的横向纹理有关，动感强的画面比值会更大，静态场景可能接近 1，所以最好用一段有运动的素材来测。

8. 一点个人经验：把这个字段写进初始化自检

最后分享一个我现在的做法，成本极低但省过不少事。在采集模块初始化完成后，加一段自检逻辑：读回G_FMT，检查field是不是ANY；如果是，直接打警告并拒绝继续。因为ANY出现在G_FMT的返回里几乎总是驱动的问题，意味着它没有把能力说清楚，后续所有基于这个格式的计算都是悬空的。再检查bytesperline是否等于width * bpp，不等就说明有对齐填充，把实际值记进配置结构体，后续一律用它。

每隔一段时间看一眼这些日志，能提前发现很多问题。采集这类东西，格式解析环节的错误往往不会立刻崩溃，而是以一种"看起来差不多但就是有点不对劲"的方式存在，比如画面略微模糊、边缘有细微锯齿、偶尔一帧闪烁。这种问题最难查，因为现象不够尖锐，人容易怀疑到别的地方去。把field从一开始就确认清楚，等于把一整类可能性提前排除掉了。