1. 先弄清楚 v4l2_field 在整条链路里处在什么位置v4l2_field是 V4L2 里讨论隔行视频时最容易产生混淆的东西。它不是某个功能开关也不是采集参数而是一个描述「这块 buffer 里的像素行在时间顺序和空间排列上属于哪一场」的枚举。我第一次接触它是在给一块带 BT.656 输入的板子做标清采集当时的需求很简单拿 720x576 的 PAL 画面转成 YUV 送编码。按逐行采的思路把field写成V4L2_FIELD_NONE出来画面一动就是满屏梳齿静止时又完全正常。折腾到第三天去翻驱动的set_fmt才明白硬件在逐行送场我却在告诉应用「这是一帧完整的图」。这个字段一旦理解偏了后面算 buffer 大小、拼场、配时间戳全都会跟着出错。这篇内容面向三类人做摄像头或视频输入驱动、需要和硬件寄存器打交道的底层工程师做采集应用、需要处理隔行信号的上层开发者以及做视频流水线调优、遇到撕裂或场序错乱却找不到原因的人。下面的内容不假设你熟悉传统电视制式但假设你至少写过一次VIDIOC_S_FMT。1.1 三个数据结构里装着同一个字段很多人第一次查v4l2_field是在struct v4l2_pix_format里看到的field成员。但这个字段其实出现在三个地方语义不完全一样fmt.fmt.pix.field或者 mplane 下的fmt.fmt.pix_mp.field这是格式协商的结果代表「后续按这种模式出图」。你VIDIOC_S_FMT传的值是请求G_FMT读回来的才是驱动真正接受的。buf.fieldstruct v4l2_buffer这是这一块 buffer 实际装的内容。驱动在dqbuf之前填好。它和格式协商的值可以不一样——这一点是后面所有问题的根源。subdev 的 pad formatstruct v4l2_subdev_format和v4l2_mbus_framefmt里也有field媒体控制器架构下整条链路上每个节点的 field 声明需要自洽。理解这三者的关系可以用一个不太严谨但好记的比喻fmt是合同buf是每次交付的货物清单subdev 是供应商之间的内部约定。合同上写「交整箱」不代表某一次不会给你送半箱——尤其是驱动能力有限的时候。1.2 协商、采集、时间戳三条线互相牵连field不是孤立存在的它同时牵动三件事第一是内存布局。整帧模式和半帧模式下同一块 buffer 能装的像素行数差一倍sizeimage直接跟着变。算少了会写越界算多了浪费带宽还可能被驱动拒绝。第二是时间维度。顶场和底场在时间上相差半个场周期PAL 是 20msNTSC 是约 16.7ms。如果驱动一场一个 buffer那么相邻两块 buffer 不是同一时刻的画面。应用如果按「一 buffer 一帧」去喂编码器运动区域就会出现时间错位。第三是时间戳。V4L2_FIELD_INTERLACED的语义里明确带着「第一场的时刻最接近这个 buffer 的 timestamp」而TOP/BOTTOM模式下每块 buffer 的时间戳代表的是这一场自己的采样时刻。做音视频同步或者多路拼接时搞错这一层同步误差会稳定偏半个场。1.3 什么时候必须关心什么时候可以忽略不是所有项目都要处理这些。判断标准很实际看信号源是不是隔行的。现代 CMOS 传感器绝大多数是滚动快门的逐行输出配 MIPI CSI-2 进来field就该老老实实是V4L2_FIELD_NONE。这种场景下你把field设成别的反而是错。需要认真处理的典型场景是场景典型信号field 语义模拟视频输入复合、S 端子PAL / NTSC576i / 480i总是隔行两场HDMI / SDI 采集1080i50、1080i60隔行取决于源老式摄像机、工业相机CCIR 制式输出隔行手机、USB 摄像头、网络摄像头逐行基本不需要某些医疗、内窥镜设备可能是隔行需要逐案确认我个人的经验是只要你的设备支持V4L2_CAP_VIDEO_CAPTURE并且能枚举出 576i 这类尺寸就默认要按隔行去设计哪怕最终跑的是逐行模式。2. 十个枚举值逐个拆从整帧到半帧enum v4l2_field一共十个值0 到 9。名字看起来杂其实可以按两个维度整理一块 buffer 装几个场以及这两个场在内存里怎么排。按这个维度分完记忆负担会小很多。2.1 NONE 和 ANY最常用也最容易误用V4L2_FIELD_NONE表示「这是逐行帧一块 buffer 一整幅完整图像」。这是现代设备上的默认值也是绝大多数应用唯一需要写的值。它的隐含信息是不存在场序问题第 0 行到第 height-1 行就是同一个时刻从上到下的采样。V4L2_FIELD_ANY完全不一样它是请求侧的占位符。你在S_FMT里写ANY意思是「我无所谓你驱动挑一个能给的」。关键点在于驱动不应该在返回结果里给你ANY。如果你G_FMT读回来还是ANY说明驱动的set_fmt实现有 bug这个值必须由应用自己兜底处理。提示V4L2_FIELD_ANY只应该出现在S_FMT/TRY_FMT的入参里。看到buf.field V4L2_FIELD_ANY直接当成驱动缺陷处理不要试图猜测它的含义。用ANY有真实的代价。我遇到过一种情况应用用ANY请求驱动挑了个V4L2_FIELD_ALTERNATE因为硬件只支持半帧输出应用却按NONE算 buffer 大小结果每块 buffer 的后半段全是脏数据。稳妥做法是要么明确指定你需要的值要么在S_FMT之后立刻检查返回值并按实际值重算所有尺寸。2.2 TOP、BOTTOM、ALTERNATE半帧模式的三种表达V4L2_FIELD_TOP表示「这块 buffer 只装了顶场」也就是偶数行按传统定义顶场是第 0、2、4… 行V4L2_FIELD_BOTTOM表示只装底场即奇数行。注意这里说的是行号归属不是「画面上面一半」。半帧 buffer 里存的仍然是整行像素只是这些行的物理行号是隔一个取一个。V4L2_FIELD_ALTERNATE是这两个的「合体声明」意思是「本设备一场一个 buffer顶场底场交替返回」。它最有价值的地方是让应用提前知道接下来DQEVENT/DQBUF拿到的每一块 buffer 都只有半帧你要自己凑对。至于某一块具体是顶还是底看buf.field——驱动会填成TOP或BOTTOM。内核头文件里给了一组辅助宏判断某个 field 值里是否含某个场#define V4L2_FIELD_HAS_TOP(field) \ ((field) V4L2_FIELD_TOP || \ (field) V4L2_FIELD_INTERLACED || \ (field) V4L2_FIELD_INTERLACED_TB || \ (field) V4L2_FIELD_INTERLACED_BT || \ (field) V4L2_FIELD_SEQ_TB || \ (field) V4L2_FIELD_SEQ_BT)HAS_BOTTOM和HAS_BOTH同理。这三个宏在实际代码里比手写 switch 好用得多尤其是你需要同时兼容几种隔行模式的时候。写之前对着自己那版内核头文件确认一遍不同版本的值集合可能有细微差别。2.3 INTERLACED 家族整帧里塞两个场的四种排法剩下五个值都属于「一块 buffer 装完整一帧但两个场都塞在里面」区别只在排列方式V4L2_FIELD_INTERLACED两个场按行交织。第 0 行属于第一场第 1 行属于第二场依次类推。但第一场到底是顶还是底这个值本身没有说死历史上依赖驱动和应用的约定。V4L2_FIELD_INTERLACED_TB明确顶场行在前即第 0 行是顶场第 0 行。V4L2_FIELD_INTERLACED_BT明确底场行在前。V4L2_FIELD_SEQ_TB两个场不交织buffer 前一半连续放整个顶场后一半连续放整个底场且各场内按时间顺序排列。V4L2_FIELD_SEQ_BT底场在前顶场在后。把「是否交织」和「哪个场先」两两组合就是下面这张表枚举值一块 buffer 装几个场内存排布场序是否明确NONE1 个完整逐行帧逐行不涉及ANY仅请求侧不涉及不涉及TOP1 场顶仅偶数行明确BOTTOM1 场底仅奇数行明确ALTERNATE1 场交替单场看 buf.field由 buffer 指定INTERLACED2 场行交织不明确INTERLACED_TB2 场行交织顶先明确INTERLACED_BT2 场行交织底先明确SEQ_TB2 场分块顶块在前明确SEQ_BT2 场分块底块在前明确INTERLACED那个「不明确」是真实存在的坑。早年很多驱动默认按顶场先行处理但并没有强制约定。所以如果你的硬件支持尽量在S_FMT里指定带_TB或_BT后缀的值如果驱动只认INTERLACED那就必须在驱动侧把场序用注释写清楚或者干脆在用户态用画面内容验证一遍。3. 内存布局与 sizeimage算错一次整条流水线报废field最直接的物理后果就是bytesperline和sizeimage的关系变了。这里的推导没有魔法但很容易被「height 就是行数」这个直觉带偏。3.1 三种布局的字节计算方式假设分辨率声明为 1920x1080像素格式是打包的 YUV422UYVY每个像素 2 字节逐行模式NONEbytesperline 1920 × 2 3840sizeimage 3840 × 1080 4147200。这是标准算法。整帧隔行INTERLACED 系、SEQ 系行数还是 1080因为两个场的行加起来正好等于整帧行数顶场 540 行 底场 540 行。所以sizeimage和逐行模式完全相同也是 4147200。区别只在于这些行的物理顺序而顺序不影响总字节数。半帧模式TOP/BOTTOM/ALTERNATE这里就变了。一块 buffer 只装 540 行但每一行仍然是完整的 1920 像素sizeimage 3840 × 540 2073600正好是整帧的一半。bytesperline不变仍然是 3840。最后这一点是新手最容易搞错的地方有人以为半帧模式下bytesperline也减半结果算出来 960×540图像被横向压扁一半还以为是驱动 bug。3.2 一个真实的算错案例某项目上做过一次模拟视频采集需求是把 720x576i 的 PAL 信号采下来送硬件编码器。A 同学按逐行思路写了代码/* 错误示例 */ fmt.fmt.pix.width 720; fmt.fmt.pix.height 576; fmt.fmt.pix.pixelformat V4L2_PIX_FMT_UYVY; fmt.fmt.pix.field V4L2_FIELD_NONE; ioctl(fd, VIDIOC_S_FMT, fmt); /* 然后自己算 buffer 大小 */ size_t sz fmt.fmt.pix.bytesperline * fmt.fmt.pix.height; /* 720*2*576 */驱动实际返回的是V4L2_FIELD_ALTERNATE每块 buffer 只有 288 行sizeimage是 414720 而不是 829440。应用按自己算的尺寸去 mmap、去解析后半段全是未定义的脏内存。表现出来是画面下半部随机花屏且每次重启位置都不一样。修正方式其实很简单而且是个通用原则永远不要自己推导 buffer 尺寸。REQBUFS之后用QUERYBUF拿驱动填好的length那才是权威值struct v4l2_requestbuffers req {0}; req.count 4; req.type V4L2_BUF_TYPE_VIDEO_CAPTURE; req.memory V4L2_MEMORY_MMAP; if (ioctl(fd, VIDIOC_REQBUFS, req) 0) { /* 处理错误 */ } for (unsigned int i 0; i req.count; i) { struct v4l2_buffer buf {0}; buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; buf.index i; if (ioctl(fd, VIDIOC_QUERYBUF, buf) 0) { /* 处理错误 */ } /* buf.length 是驱动给的真实长度直接用它 mmap */ void *p mmap(NULL, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, buf.m.offset); /* 记录 p 和 buf.length */ }如果你确实需要预估尺寸比如提前算好 DMA 缓冲那就用TRY_FMT结果里的sizeimage而不是自己乘。sizeimage有时会比理论值大对齐填充以它为准最保险。注意半帧模式下fmt.fmt.pix.height报的仍然是整帧高度1080不是 540。驱动在sizeimage里体现半帧在height里保持整帧几何这两个地方不矛盾。但也确实有驱动把height也折半返回遇到这种情况以sizeimage / bytesperline反推出的行数做校验别信单一字段。4. 驱动侧怎么写set_fmt 的校验与中断里的填值如果你只写应用层这一章可以快速浏览但建议还是看一眼因为很多「应用层怎么调都不对」的问题根源在这里。4.1 set_fmt 里的 field 协商逻辑一个健壮的vidioc_s_fmt_vid_cap大致要干这几件事把应用请求的field和硬件实际支持的能力集比对能支持的照单全收不支持的话要么降级替换、要么返回-EINVAL。这里有个设计取舍值得说清楚。V4L2 内核框架层面有一套兜底如果驱动在set_fmt里返回-EINVAL框架可能会退一步用V4L2_FIELD_ANY重新试一次。这带来一个隐患——应用明明指定了某种场模式却被静默改掉而应用没重新读G_FMT就直接往下走。所以驱动侧更稳妥的做法是尽量协商成功并返回真实值而不是动不动就-EINVAL。伪代码大概长这样static int mydev_s_fmt_vid_cap(struct file *file, void *priv, struct v4l2_format *f) { struct mydev *dev video_drvdata(file); struct v4l2_pix_format *pix f-fmt.pix; u32 supported dev-caps.field_mask; /* 硬件能给的集合 */ /* 逐项校验分辨率、像素格式不通过就调整 */ if (pix-field V4L2_FIELD_ANY) { /* 请求侧占位符替换成硬件默认 */ pix-field dev-default_field; } else if (!(supported FIELD_BIT(pix-field))) { /* 明确请求了不支持的值 */ return -EINVAL; } /* 按最终 field 重算 bytesperline / sizeimage */ mydev_calc_sizes(dev, pix); /* 把配置真正下到硬件寄存器 */ mydev_hw_configure(dev, pix); return 0; }关键在倒数第二步sizeimage必须在field定下来之后算。我见过把尺寸计算放在前面、field调整放在后面的实现结果返回的sizeimage和最终field对不上应用 mmap 之后直接越界。4.2 采集中断里怎么决定 buffer 的 field对于模拟解码或 HDMI 接收这类硬件场序信息通常藏在数据流里。BT.656/BT.1120 的 SAV/EAV 码里有一个 F 位Field bit硬件解码后一般会置到某个状态寄存器里或者直接给出一个中断/标志位。驱动在填 buffer 的时候static void mydev_fill_buffer(struct mydev *dev, struct v4l2_buffer *vb) { u32 status readl(dev-regs REG_FIELD_STATUS); if (dev-cur_field_mode V4L2_FIELD_ALTERNATE) { vb-field (status F_BIT) ? V4L2_FIELD_BOTTOM : V4L2_FIELD_TOP; } else if (dev-cur_field_mode V4L2_FIELD_INTERLACED_TB) { vb-field V4L2_FIELD_INTERLACED_TB; } else { vb-field dev-cur_field_mode; } vb-sequence dev-sequence; vb-timestamp ktime_get_ns(); }有个细节值得注意F 位的极性在不同硬件上可能相反有的芯片 F1 表示顶场有的表示底场。这个不能靠猜得看手册或者拿一张有竖直运动物体的测试图实测。测法很简单让画面里一条水平白条缓慢上下移动抓连续两场看哪一场的白条位置更靠上——靠上的是时间上更早的场。4.3 媒体控制器链路上的 field 一致性如果用的是 media controller 架构field会在整条链路上传播sensor → CSI 接收 → ISP → 视频节点。每个 pad 上的v4l2_mbus_framefmt都有自己的field。实际项目里最容易出问题的是链路中间某个节点把field重置成NONE。比如 ISP 的 sink pad 收到INTERLACED但 source pad 输出时默认填了NONE应用在/dev/videoX上就永远看不到隔行信息即使硬件确实在送两个场。排查方法是用media-ctl打印拓扑逐个 pad 看格式media-ctl -p输出里每个 pad 的 fmt 会带field字段。如果发现某个节点前后不一致就去查那个子设备的set_fmt实现大概率是没把field透传下去。这类问题在多层 ISP 的方案上挺常见尤其是各家自己写的 pipeline 代码field往往是最先被忽略的字段。5. 用户态实操从探查到抓帧验证理论讲完落到能跑的命令和代码上。这一章的内容你可以直接抄。5.1 先用工具摸清设备底细不要一上来就写代码。先确认设备支持什么# 看设备能力、驱动名、支持的格式 v4l2-ctl -d /dev/video0 --info v4l2-ctl -d /dev/video0 --list-formats-ext--list-formats-ext的输出会列出每种格式支持的分辨率和帧率。重点看两处一是分辨率里有没有 720x576、1920x1080 这类「i」制式常见的尺寸二是抓一帧当前格式v4l2-ctl -d /dev/video0 --get-fmt-video输出里会有一行Field: None或者Field: Alternate、Field: Interlaced。这就是设备当前的field状态。想改的话# 新版本 v4l2-ctl 支持在 set-fmt-video 里直接带 field v4l2-ctl -d /dev/video0 \ --set-fmt-videowidth720,height576,pixelformatUYVY,fieldalternate # 老版本用独立参数 v4l2-ctl -d /dev/video0 --set-fmt-video-field7field的数值就是枚举值0ANY、1NONE、2TOP、3BOTTOM、4INTERLACED、5SEQ_TB、6SEQ_BT、7ALTERNATE、8INTERLACED_TB、9INTERLACED_BT。改完之后再--get-fmt-video确认一遍看驱动是不是真的接受了你要的值。这一步花不了两分钟但能省掉后面几个小时的困惑。5.2 一段能直接用的配置代码下面这段是完整的格式设置加校验流程重点在于每一步都检查返回值#include linux/videodev2.h #include sys/ioctl.h #include stdio.h #include string.h static const char *field_name(enum v4l2_field f) { switch (f) { case V4L2_FIELD_ANY: return ANY; case V4L2_FIELD_NONE: return NONE; case V4L2_FIELD_TOP: return TOP; case V4L2_FIELD_BOTTOM: return BOTTOM; case V4L2_FIELD_INTERLACED: return INTERLACED; case V4L2_FIELD_SEQ_TB: return SEQ_TB; case V4L2_FIELD_SEQ_BT: return SEQ_BT; case V4L2_FIELD_ALTERNATE: return ALTERNATE; case V4L2_FIELD_INTERLACED_TB: return INTERLACED_TB; case V4L2_FIELD_INTERLACED_BT: return INTERLACED_BT; default: return UNKNOWN; } } int setup_capture(int fd, unsigned w, unsigned h, enum v4l2_field want) { 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 -1; } fmt.fmt.pix.width w; fmt.fmt.pix.height h; fmt.fmt.pix.pixelformat V4L2_PIX_FMT_UYVY; fmt.fmt.pix.field want; if (ioctl(fd, VIDIOC_S_FMT, fmt) 0) { perror(VIDIOC_S_FMT); return -1; } printf(requested%s got%s %ux%u stride%u size%u\n, field_name(want), field_name(fmt.fmt.pix.field), fmt.fmt.pix.width, fmt.fmt.pix.height, fmt.fmt.pix.bytesperline, fmt.fmt.pix.sizeimage); /* 这两处偏差必须当作错误处理不能忽略 */ if (fmt.fmt.pix.field V4L2_FIELD_ANY) { fprintf(stderr, driver returned ANY, thats a driver bug\n); return -1; } if (fmt.fmt.pix.width ! w || fmt.fmt.pix.height ! h) { fprintf(stderr, resolution adjusted by driver\n); } return 0; }几个要点解释一下。G_FMT那一步不能省。V4L2 的v4l2_format里还有colorspace、priv、flags等字段如果整个结构体清零后直接S_FMT等于把这些都重置成默认值。有些驱动会因此把色彩空间设错后面做 CSC 时颜色偏。打印出got那一行是我个人强制要求所有项目都加的调试输出。真出问题的时候这一行往往是第一个能看出端倪的地方。最后那两个判断是硬性检查。驱动返回ANY或者悄悄改了分辨率这两种情况都必须让上层知道否则后面的尺寸计算全建立在错误假设上。5.3 抓帧、拼图、肉眼判场序配置对不对最终要靠画面说话。最直接的方法是把原始数据抓出来转成图片# 抓 10 帧原始数据 v4l2-ctl -d /dev/video0 \ --stream-mmap4 --stream-count10 --stream-to/tmp/frames.raw # 转成 PNG注意 pix_fmt 要和设备一致 ffmpeg -f rawvideo -pix_fmt yuyv422 -s 720x576 \ -i /tmp/frames.raw -frames:v 1 /tmp/frame0.png如果是半帧模式ALTERNATE这里会暴露一个陷阱--stream-to拼出来的连续数据每块 buffer 只有 288 行但 ffmpeg 按 576 行去解析结果是把两场当成一帧。这恰好可以用来判断场序——如果两场顺序正确拼出来的图在运动物体边缘应该只有「时间差造成的轻微错位」如果顺序反了会看到明显的上下分离或者锯齿。想更严谨一点可以把偶数行和奇数行分别抽出来存成两张图# 抽出顶场偶数行 ffmpeg -f rawvideo -pix_fmt yuyv422 -s 720x576 -i /tmp/frames.raw \ -vf selectnot(mod(n,2)),setptsN/25/TB -frames:v 1 /tmp/top.png # 抽出底场奇数行 ffmpeg -f rawvideo -pix_fmt yuyv422 -s 720x576 -i /tmp/frames.raw \ -vf selectmod(n,2),setptsN/25/TB -frames:v 1 /tmp/bot.png两张图分别看运动物体的位置。传统定义里顶场在时间上更早所以如果物体在向下运动顶场里的物体应该比底场更靠上。如果反了说明场序错回头去检查S_FMT里那次INTERLACED_TB到底有没有被驱动接受。另外还有一个非视觉的判断方法看时间戳间隔。半帧模式下相邻两个 buffer 的时间戳差应该约等于场周期的一半。720x576i25 的帧周期是 40ms场周期是 20ms那么 buffer 间隔应该是 20ms 左右。如果实测是 40ms说明驱动实际给的是整帧ALTERNATE只是个幌子。6. 排查实录与问题速查表这一章是踩坑总结症状和原因之间的对应关系基本都是实际遇到过的。6.1 四类典型症状的归因症状一静止画面正常运动物体边缘出现梳齿。这是最经典的「把隔行当逐行处理」。原因就是field设成了NONE或者驱动声明了NONE但实际给的是隔行数据。判断方法把画面冻结在一帧上放大看运动边缘梳齿的间距正好是 2 行。修复思路是让整条链路包括fmt和buf.field如实反映隔行状态然后在合适的位置做去隔行。症状二画面整体上下抖动幅度约 1 个像素行。典型的场序反了。顶场当底场用画面在垂直方向上会有半行的偏移叠加起来就是抖动。这种症状很有欺骗性因为幅度小很多人第一反应是「传感器抖动」或者「时钟抖动」去查 PLL 查了半天。快速验证法拿一张水平横线测试图如果横线在动但画面整体在细微地上下跳基本就是场序问题。症状三画面下半部花屏或者每隔一块 buffer 出现一次脏数据。buffer 尺寸算小了。要么是按整帧算的尺寸去装半帧浪费但不会坏要么是按半帧算的尺寸去装整帧越界。前者表现为下半部是上次的残留后者直接内存越界可能把相邻 buffer 踩坏。回到第 3 章的方法用QUERYBUF的length和TRY_FMT的sizeimage交叉验证。症状四ioctl(VIDIOC_S_FMT)返回成功但G_FMT读回来的 field 变了。驱动做了静默降级。有些驱动在set_fmt里发现请求的field不支持不返回错误而是自己改成一个能支持的值。这本身不算 bugV4L2 允许协商但应用必须接受协商结果。处理方式S_FMT之后一律以驱动返回值为准重新配置后续所有参数不要保留自己请求时的假设。6.2 问题速查表现象可能原因快速验证处理方向运动边缘梳齿隔行数据当逐行用冻结画面放大看边缘检查 fmt.field 与 buf.field画面小幅上下抖动顶底场序反了水平横线测试图换 INTERLACED_TB / BT 并实测下半部花屏sizeimage 算错对比 sizeimage 与自行计算值改用 QUERYBUF 的 lengthS_FMT 成功但 field 变了驱动静默降级打印 S_FMT 前后 field以返回值为准重算参数时间戳间隔翻倍ALTERNATE 实为整帧打印相邻 buffer ts 差查驱动实际出图模式链路中间 field 丢失subdev 未透传media-ctl -p 逐 pad 看修子设备的 set_fmt帧率只有一半每场一个 buffer 当整帧算统计 DQBUF 频率按场计数而非按帧计数编码后码率暴涨隔行内容直接编码对比静态和动态场景码率编码前做去隔行6.3 几个只有踩过才知道的细节别信height信sizeimage和length。半帧模式下height报整帧高度这件事不同驱动的处理并不统一。有的按文档报 1080有的报 540。与其纠结不如用sizeimage / bytesperline反推实际行数再用length兜底。buf.field和fmt.field不一致是合法的。尤其在ALTERNATE模式下fmt.field是ALTERNATE每块buf.field是TOP或BOTTOM。应用必须每块 buffer 都读一次buf.field不能缓存在一个全局变量里。sequence在 ALTERNATE 模式下的语义要实测。有的驱动一场一个 sequence 号递增有的驱动同一帧的两个场共用一个 sequence。这直接影响你怎么把两场配对。配错的表现是画面周期性闪烁因为有 50% 的概率把不同帧的场凑到一起。半帧模式的 buffer 数量要给够。整帧模式下 4 块 buffer 够用半帧模式下同样的帧率意味着 buffer 周转速度快一倍4 块很容易不够表现为DQBUF阻塞或丢帧。我一般直接给 8 块起步。测试一定要用有运动的画面。静态测试图会把所有场序问题都掩盖掉。最省事的测试源是一个缓慢横向移动的竖条或者一个钟摆。如果手头只有静态图可以在镜头前晃一支笔。7. 去隔行到底该放在哪一层field配对了紧接着的问题就是「谁来消掉这两个场」。这里面有个分工决策选错了会带来不必要的带宽开销或者画质损失。如果硬件链路里有专门的去隔行模块有些 ISP 或者 FPGA 里有那采集端应该让驱动输出V4L2_FIELD_INTERLACED之类的整帧模式把两个场都拿进来交给硬件去合成。这样应用层只面对逐行帧代码最简单延迟也最低。如果硬件没有这能力那采集端配成V4L2_FIELD_ALTERNATE一场一块 buffer应用自己配对后用软件或 GPU 做去隔行。这样灵活但应用复杂度上去了要维护场的配对状态要处理丢场的情况缓冲队列也要加深。还有一种做法是「不开去隔行直接按场输出」用非线性拉伸或者只取一场的方式。CCTV 这类场景里常见——只取顶场垂直分辨率减半但帧率不变运动看起来很流畅。这种方案在监控回放里其实观感不错代价是静态细节损失。我个人的取舍标准是看最终显示设备的刷新率和信号源场频的关系。如果信号源是 50i、显示端是 50Hz做场合并bob 或者 weave最省事延迟也最低如果显示端是 60Hz那就得考虑帧率转换去隔行的质量就变得关键了这时候软件算法比如运动自适应通常比简单的行插值效果好很多。顺带说一个容易忽略的点如果下游编码器是 H.264/HEVC并且支持隔行编码frame_mbs_only_flag0那么把隔行内容原样送进去比先去隔行再编码能省不少码率细节也保留得更好。很多编码器的隔行支持默认是关的配置的时候要显式打开。最后再分享一个我自己的习惯任何涉及field的新项目第一步都是写一个二十行的小程序只做G_FMT→ 打印 →S_FMT各种 field 值 → 每次打印返回值。这个程序不采集、不处理纯试探。跑一遍下来驱动到底支持什么、会怎么降级、返回什么奇怪值全都清清楚楚。花在这上面的二十分钟通常能抵掉后面调图像时的一整个下午——毕竟图像类的问题你看到的异常和真正的原因之间往往隔着好几层抽象。 
长河君 · 2026/11/2 2:35:23 · 阅读 1.2k v4l2_field 隔行视频场序与 buffer 布局实战
1. 先弄清楚 v4l2_field 在整条链路里处在什么位置v4l2_field是 V4L2 里讨论隔行视频时最容易产生混淆的东西。它不是某个功能开关也不是采集参数而是一个描述「这块 buffer 里的像素行在时间顺序和空间排列上属于哪一场」的枚举。我第一次接触它是在给一块带 BT.656 输入的板子做标清采集当时的需求很简单拿 720x576 的 PAL 画面转成 YUV 送编码。按逐行采的思路把field写成V4L2_FIELD_NONE出来画面一动就是满屏梳齿静止时又完全正常。折腾到第三天去翻驱动的set_fmt才明白硬件在逐行送场我却在告诉应用「这是一帧完整的图」。这个字段一旦理解偏了后面算 buffer 大小、拼场、配时间戳全都会跟着出错。这篇内容面向三类人做摄像头或视频输入驱动、需要和硬件寄存器打交道的底层工程师做采集应用、需要处理隔行信号的上层开发者以及做视频流水线调优、遇到撕裂或场序错乱却找不到原因的人。下面的内容不假设你熟悉传统电视制式但假设你至少写过一次VIDIOC_S_FMT。1.1 三个数据结构里装着同一个字段很多人第一次查v4l2_field是在struct v4l2_pix_format里看到的field成员。但这个字段其实出现在三个地方语义不完全一样fmt.fmt.pix.field或者 mplane 下的fmt.fmt.pix_mp.field这是格式协商的结果代表「后续按这种模式出图」。你VIDIOC_S_FMT传的值是请求G_FMT读回来的才是驱动真正接受的。buf.fieldstruct v4l2_buffer这是这一块 buffer 实际装的内容。驱动在dqbuf之前填好。它和格式协商的值可以不一样——这一点是后面所有问题的根源。subdev 的 pad formatstruct v4l2_subdev_format和v4l2_mbus_framefmt里也有field媒体控制器架构下整条链路上每个节点的 field 声明需要自洽。理解这三者的关系可以用一个不太严谨但好记的比喻fmt是合同buf是每次交付的货物清单subdev 是供应商之间的内部约定。合同上写「交整箱」不代表某一次不会给你送半箱——尤其是驱动能力有限的时候。1.2 协商、采集、时间戳三条线互相牵连field不是孤立存在的它同时牵动三件事第一是内存布局。整帧模式和半帧模式下同一块 buffer 能装的像素行数差一倍sizeimage直接跟着变。算少了会写越界算多了浪费带宽还可能被驱动拒绝。第二是时间维度。顶场和底场在时间上相差半个场周期PAL 是 20msNTSC 是约 16.7ms。如果驱动一场一个 buffer那么相邻两块 buffer 不是同一时刻的画面。应用如果按「一 buffer 一帧」去喂编码器运动区域就会出现时间错位。第三是时间戳。V4L2_FIELD_INTERLACED的语义里明确带着「第一场的时刻最接近这个 buffer 的 timestamp」而TOP/BOTTOM模式下每块 buffer 的时间戳代表的是这一场自己的采样时刻。做音视频同步或者多路拼接时搞错这一层同步误差会稳定偏半个场。1.3 什么时候必须关心什么时候可以忽略不是所有项目都要处理这些。判断标准很实际看信号源是不是隔行的。现代 CMOS 传感器绝大多数是滚动快门的逐行输出配 MIPI CSI-2 进来field就该老老实实是V4L2_FIELD_NONE。这种场景下你把field设成别的反而是错。需要认真处理的典型场景是场景典型信号field 语义模拟视频输入复合、S 端子PAL / NTSC576i / 480i总是隔行两场HDMI / SDI 采集1080i50、1080i60隔行取决于源老式摄像机、工业相机CCIR 制式输出隔行手机、USB 摄像头、网络摄像头逐行基本不需要某些医疗、内窥镜设备可能是隔行需要逐案确认我个人的经验是只要你的设备支持V4L2_CAP_VIDEO_CAPTURE并且能枚举出 576i 这类尺寸就默认要按隔行去设计哪怕最终跑的是逐行模式。2. 十个枚举值逐个拆从整帧到半帧enum v4l2_field一共十个值0 到 9。名字看起来杂其实可以按两个维度整理一块 buffer 装几个场以及这两个场在内存里怎么排。按这个维度分完记忆负担会小很多。2.1 NONE 和 ANY最常用也最容易误用V4L2_FIELD_NONE表示「这是逐行帧一块 buffer 一整幅完整图像」。这是现代设备上的默认值也是绝大多数应用唯一需要写的值。它的隐含信息是不存在场序问题第 0 行到第 height-1 行就是同一个时刻从上到下的采样。V4L2_FIELD_ANY完全不一样它是请求侧的占位符。你在S_FMT里写ANY意思是「我无所谓你驱动挑一个能给的」。关键点在于驱动不应该在返回结果里给你ANY。如果你G_FMT读回来还是ANY说明驱动的set_fmt实现有 bug这个值必须由应用自己兜底处理。提示V4L2_FIELD_ANY只应该出现在S_FMT/TRY_FMT的入参里。看到buf.field V4L2_FIELD_ANY直接当成驱动缺陷处理不要试图猜测它的含义。用ANY有真实的代价。我遇到过一种情况应用用ANY请求驱动挑了个V4L2_FIELD_ALTERNATE因为硬件只支持半帧输出应用却按NONE算 buffer 大小结果每块 buffer 的后半段全是脏数据。稳妥做法是要么明确指定你需要的值要么在S_FMT之后立刻检查返回值并按实际值重算所有尺寸。2.2 TOP、BOTTOM、ALTERNATE半帧模式的三种表达V4L2_FIELD_TOP表示「这块 buffer 只装了顶场」也就是偶数行按传统定义顶场是第 0、2、4… 行V4L2_FIELD_BOTTOM表示只装底场即奇数行。注意这里说的是行号归属不是「画面上面一半」。半帧 buffer 里存的仍然是整行像素只是这些行的物理行号是隔一个取一个。V4L2_FIELD_ALTERNATE是这两个的「合体声明」意思是「本设备一场一个 buffer顶场底场交替返回」。它最有价值的地方是让应用提前知道接下来DQEVENT/DQBUF拿到的每一块 buffer 都只有半帧你要自己凑对。至于某一块具体是顶还是底看buf.field——驱动会填成TOP或BOTTOM。内核头文件里给了一组辅助宏判断某个 field 值里是否含某个场#define V4L2_FIELD_HAS_TOP(field) \ ((field) V4L2_FIELD_TOP || \ (field) V4L2_FIELD_INTERLACED || \ (field) V4L2_FIELD_INTERLACED_TB || \ (field) V4L2_FIELD_INTERLACED_BT || \ (field) V4L2_FIELD_SEQ_TB || \ (field) V4L2_FIELD_SEQ_BT)HAS_BOTTOM和HAS_BOTH同理。这三个宏在实际代码里比手写 switch 好用得多尤其是你需要同时兼容几种隔行模式的时候。写之前对着自己那版内核头文件确认一遍不同版本的值集合可能有细微差别。2.3 INTERLACED 家族整帧里塞两个场的四种排法剩下五个值都属于「一块 buffer 装完整一帧但两个场都塞在里面」区别只在排列方式V4L2_FIELD_INTERLACED两个场按行交织。第 0 行属于第一场第 1 行属于第二场依次类推。但第一场到底是顶还是底这个值本身没有说死历史上依赖驱动和应用的约定。V4L2_FIELD_INTERLACED_TB明确顶场行在前即第 0 行是顶场第 0 行。V4L2_FIELD_INTERLACED_BT明确底场行在前。V4L2_FIELD_SEQ_TB两个场不交织buffer 前一半连续放整个顶场后一半连续放整个底场且各场内按时间顺序排列。V4L2_FIELD_SEQ_BT底场在前顶场在后。把「是否交织」和「哪个场先」两两组合就是下面这张表枚举值一块 buffer 装几个场内存排布场序是否明确NONE1 个完整逐行帧逐行不涉及ANY仅请求侧不涉及不涉及TOP1 场顶仅偶数行明确BOTTOM1 场底仅奇数行明确ALTERNATE1 场交替单场看 buf.field由 buffer 指定INTERLACED2 场行交织不明确INTERLACED_TB2 场行交织顶先明确INTERLACED_BT2 场行交织底先明确SEQ_TB2 场分块顶块在前明确SEQ_BT2 场分块底块在前明确INTERLACED那个「不明确」是真实存在的坑。早年很多驱动默认按顶场先行处理但并没有强制约定。所以如果你的硬件支持尽量在S_FMT里指定带_TB或_BT后缀的值如果驱动只认INTERLACED那就必须在驱动侧把场序用注释写清楚或者干脆在用户态用画面内容验证一遍。3. 内存布局与 sizeimage算错一次整条流水线报废field最直接的物理后果就是bytesperline和sizeimage的关系变了。这里的推导没有魔法但很容易被「height 就是行数」这个直觉带偏。3.1 三种布局的字节计算方式假设分辨率声明为 1920x1080像素格式是打包的 YUV422UYVY每个像素 2 字节逐行模式NONEbytesperline 1920 × 2 3840sizeimage 3840 × 1080 4147200。这是标准算法。整帧隔行INTERLACED 系、SEQ 系行数还是 1080因为两个场的行加起来正好等于整帧行数顶场 540 行 底场 540 行。所以sizeimage和逐行模式完全相同也是 4147200。区别只在于这些行的物理顺序而顺序不影响总字节数。半帧模式TOP/BOTTOM/ALTERNATE这里就变了。一块 buffer 只装 540 行但每一行仍然是完整的 1920 像素sizeimage 3840 × 540 2073600正好是整帧的一半。bytesperline不变仍然是 3840。最后这一点是新手最容易搞错的地方有人以为半帧模式下bytesperline也减半结果算出来 960×540图像被横向压扁一半还以为是驱动 bug。3.2 一个真实的算错案例某项目上做过一次模拟视频采集需求是把 720x576i 的 PAL 信号采下来送硬件编码器。A 同学按逐行思路写了代码/* 错误示例 */ fmt.fmt.pix.width 720; fmt.fmt.pix.height 576; fmt.fmt.pix.pixelformat V4L2_PIX_FMT_UYVY; fmt.fmt.pix.field V4L2_FIELD_NONE; ioctl(fd, VIDIOC_S_FMT, fmt); /* 然后自己算 buffer 大小 */ size_t sz fmt.fmt.pix.bytesperline * fmt.fmt.pix.height; /* 720*2*576 */驱动实际返回的是V4L2_FIELD_ALTERNATE每块 buffer 只有 288 行sizeimage是 414720 而不是 829440。应用按自己算的尺寸去 mmap、去解析后半段全是未定义的脏内存。表现出来是画面下半部随机花屏且每次重启位置都不一样。修正方式其实很简单而且是个通用原则永远不要自己推导 buffer 尺寸。REQBUFS之后用QUERYBUF拿驱动填好的length那才是权威值struct v4l2_requestbuffers req {0}; req.count 4; req.type V4L2_BUF_TYPE_VIDEO_CAPTURE; req.memory V4L2_MEMORY_MMAP; if (ioctl(fd, VIDIOC_REQBUFS, req) 0) { /* 处理错误 */ } for (unsigned int i 0; i req.count; i) { struct v4l2_buffer buf {0}; buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; buf.index i; if (ioctl(fd, VIDIOC_QUERYBUF, buf) 0) { /* 处理错误 */ } /* buf.length 是驱动给的真实长度直接用它 mmap */ void *p mmap(NULL, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, buf.m.offset); /* 记录 p 和 buf.length */ }如果你确实需要预估尺寸比如提前算好 DMA 缓冲那就用TRY_FMT结果里的sizeimage而不是自己乘。sizeimage有时会比理论值大对齐填充以它为准最保险。注意半帧模式下fmt.fmt.pix.height报的仍然是整帧高度1080不是 540。驱动在sizeimage里体现半帧在height里保持整帧几何这两个地方不矛盾。但也确实有驱动把height也折半返回遇到这种情况以sizeimage / bytesperline反推出的行数做校验别信单一字段。4. 驱动侧怎么写set_fmt 的校验与中断里的填值如果你只写应用层这一章可以快速浏览但建议还是看一眼因为很多「应用层怎么调都不对」的问题根源在这里。4.1 set_fmt 里的 field 协商逻辑一个健壮的vidioc_s_fmt_vid_cap大致要干这几件事把应用请求的field和硬件实际支持的能力集比对能支持的照单全收不支持的话要么降级替换、要么返回-EINVAL。这里有个设计取舍值得说清楚。V4L2 内核框架层面有一套兜底如果驱动在set_fmt里返回-EINVAL框架可能会退一步用V4L2_FIELD_ANY重新试一次。这带来一个隐患——应用明明指定了某种场模式却被静默改掉而应用没重新读G_FMT就直接往下走。所以驱动侧更稳妥的做法是尽量协商成功并返回真实值而不是动不动就-EINVAL。伪代码大概长这样static int mydev_s_fmt_vid_cap(struct file *file, void *priv, struct v4l2_format *f) { struct mydev *dev video_drvdata(file); struct v4l2_pix_format *pix f-fmt.pix; u32 supported dev-caps.field_mask; /* 硬件能给的集合 */ /* 逐项校验分辨率、像素格式不通过就调整 */ if (pix-field V4L2_FIELD_ANY) { /* 请求侧占位符替换成硬件默认 */ pix-field dev-default_field; } else if (!(supported FIELD_BIT(pix-field))) { /* 明确请求了不支持的值 */ return -EINVAL; } /* 按最终 field 重算 bytesperline / sizeimage */ mydev_calc_sizes(dev, pix); /* 把配置真正下到硬件寄存器 */ mydev_hw_configure(dev, pix); return 0; }关键在倒数第二步sizeimage必须在field定下来之后算。我见过把尺寸计算放在前面、field调整放在后面的实现结果返回的sizeimage和最终field对不上应用 mmap 之后直接越界。4.2 采集中断里怎么决定 buffer 的 field对于模拟解码或 HDMI 接收这类硬件场序信息通常藏在数据流里。BT.656/BT.1120 的 SAV/EAV 码里有一个 F 位Field bit硬件解码后一般会置到某个状态寄存器里或者直接给出一个中断/标志位。驱动在填 buffer 的时候static void mydev_fill_buffer(struct mydev *dev, struct v4l2_buffer *vb) { u32 status readl(dev-regs REG_FIELD_STATUS); if (dev-cur_field_mode V4L2_FIELD_ALTERNATE) { vb-field (status F_BIT) ? V4L2_FIELD_BOTTOM : V4L2_FIELD_TOP; } else if (dev-cur_field_mode V4L2_FIELD_INTERLACED_TB) { vb-field V4L2_FIELD_INTERLACED_TB; } else { vb-field dev-cur_field_mode; } vb-sequence dev-sequence; vb-timestamp ktime_get_ns(); }有个细节值得注意F 位的极性在不同硬件上可能相反有的芯片 F1 表示顶场有的表示底场。这个不能靠猜得看手册或者拿一张有竖直运动物体的测试图实测。测法很简单让画面里一条水平白条缓慢上下移动抓连续两场看哪一场的白条位置更靠上——靠上的是时间上更早的场。4.3 媒体控制器链路上的 field 一致性如果用的是 media controller 架构field会在整条链路上传播sensor → CSI 接收 → ISP → 视频节点。每个 pad 上的v4l2_mbus_framefmt都有自己的field。实际项目里最容易出问题的是链路中间某个节点把field重置成NONE。比如 ISP 的 sink pad 收到INTERLACED但 source pad 输出时默认填了NONE应用在/dev/videoX上就永远看不到隔行信息即使硬件确实在送两个场。排查方法是用media-ctl打印拓扑逐个 pad 看格式media-ctl -p输出里每个 pad 的 fmt 会带field字段。如果发现某个节点前后不一致就去查那个子设备的set_fmt实现大概率是没把field透传下去。这类问题在多层 ISP 的方案上挺常见尤其是各家自己写的 pipeline 代码field往往是最先被忽略的字段。5. 用户态实操从探查到抓帧验证理论讲完落到能跑的命令和代码上。这一章的内容你可以直接抄。5.1 先用工具摸清设备底细不要一上来就写代码。先确认设备支持什么# 看设备能力、驱动名、支持的格式 v4l2-ctl -d /dev/video0 --info v4l2-ctl -d /dev/video0 --list-formats-ext--list-formats-ext的输出会列出每种格式支持的分辨率和帧率。重点看两处一是分辨率里有没有 720x576、1920x1080 这类「i」制式常见的尺寸二是抓一帧当前格式v4l2-ctl -d /dev/video0 --get-fmt-video输出里会有一行Field: None或者Field: Alternate、Field: Interlaced。这就是设备当前的field状态。想改的话# 新版本 v4l2-ctl 支持在 set-fmt-video 里直接带 field v4l2-ctl -d /dev/video0 \ --set-fmt-videowidth720,height576,pixelformatUYVY,fieldalternate # 老版本用独立参数 v4l2-ctl -d /dev/video0 --set-fmt-video-field7field的数值就是枚举值0ANY、1NONE、2TOP、3BOTTOM、4INTERLACED、5SEQ_TB、6SEQ_BT、7ALTERNATE、8INTERLACED_TB、9INTERLACED_BT。改完之后再--get-fmt-video确认一遍看驱动是不是真的接受了你要的值。这一步花不了两分钟但能省掉后面几个小时的困惑。5.2 一段能直接用的配置代码下面这段是完整的格式设置加校验流程重点在于每一步都检查返回值#include linux/videodev2.h #include sys/ioctl.h #include stdio.h #include string.h static const char *field_name(enum v4l2_field f) { switch (f) { case V4L2_FIELD_ANY: return ANY; case V4L2_FIELD_NONE: return NONE; case V4L2_FIELD_TOP: return TOP; case V4L2_FIELD_BOTTOM: return BOTTOM; case V4L2_FIELD_INTERLACED: return INTERLACED; case V4L2_FIELD_SEQ_TB: return SEQ_TB; case V4L2_FIELD_SEQ_BT: return SEQ_BT; case V4L2_FIELD_ALTERNATE: return ALTERNATE; case V4L2_FIELD_INTERLACED_TB: return INTERLACED_TB; case V4L2_FIELD_INTERLACED_BT: return INTERLACED_BT; default: return UNKNOWN; } } int setup_capture(int fd, unsigned w, unsigned h, enum v4l2_field want) { 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 -1; } fmt.fmt.pix.width w; fmt.fmt.pix.height h; fmt.fmt.pix.pixelformat V4L2_PIX_FMT_UYVY; fmt.fmt.pix.field want; if (ioctl(fd, VIDIOC_S_FMT, fmt) 0) { perror(VIDIOC_S_FMT); return -1; } printf(requested%s got%s %ux%u stride%u size%u\n, field_name(want), field_name(fmt.fmt.pix.field), fmt.fmt.pix.width, fmt.fmt.pix.height, fmt.fmt.pix.bytesperline, fmt.fmt.pix.sizeimage); /* 这两处偏差必须当作错误处理不能忽略 */ if (fmt.fmt.pix.field V4L2_FIELD_ANY) { fprintf(stderr, driver returned ANY, thats a driver bug\n); return -1; } if (fmt.fmt.pix.width ! w || fmt.fmt.pix.height ! h) { fprintf(stderr, resolution adjusted by driver\n); } return 0; }几个要点解释一下。G_FMT那一步不能省。V4L2 的v4l2_format里还有colorspace、priv、flags等字段如果整个结构体清零后直接S_FMT等于把这些都重置成默认值。有些驱动会因此把色彩空间设错后面做 CSC 时颜色偏。打印出got那一行是我个人强制要求所有项目都加的调试输出。真出问题的时候这一行往往是第一个能看出端倪的地方。最后那两个判断是硬性检查。驱动返回ANY或者悄悄改了分辨率这两种情况都必须让上层知道否则后面的尺寸计算全建立在错误假设上。5.3 抓帧、拼图、肉眼判场序配置对不对最终要靠画面说话。最直接的方法是把原始数据抓出来转成图片# 抓 10 帧原始数据 v4l2-ctl -d /dev/video0 \ --stream-mmap4 --stream-count10 --stream-to/tmp/frames.raw # 转成 PNG注意 pix_fmt 要和设备一致 ffmpeg -f rawvideo -pix_fmt yuyv422 -s 720x576 \ -i /tmp/frames.raw -frames:v 1 /tmp/frame0.png如果是半帧模式ALTERNATE这里会暴露一个陷阱--stream-to拼出来的连续数据每块 buffer 只有 288 行但 ffmpeg 按 576 行去解析结果是把两场当成一帧。这恰好可以用来判断场序——如果两场顺序正确拼出来的图在运动物体边缘应该只有「时间差造成的轻微错位」如果顺序反了会看到明显的上下分离或者锯齿。想更严谨一点可以把偶数行和奇数行分别抽出来存成两张图# 抽出顶场偶数行 ffmpeg -f rawvideo -pix_fmt yuyv422 -s 720x576 -i /tmp/frames.raw \ -vf selectnot(mod(n,2)),setptsN/25/TB -frames:v 1 /tmp/top.png # 抽出底场奇数行 ffmpeg -f rawvideo -pix_fmt yuyv422 -s 720x576 -i /tmp/frames.raw \ -vf selectmod(n,2),setptsN/25/TB -frames:v 1 /tmp/bot.png两张图分别看运动物体的位置。传统定义里顶场在时间上更早所以如果物体在向下运动顶场里的物体应该比底场更靠上。如果反了说明场序错回头去检查S_FMT里那次INTERLACED_TB到底有没有被驱动接受。另外还有一个非视觉的判断方法看时间戳间隔。半帧模式下相邻两个 buffer 的时间戳差应该约等于场周期的一半。720x576i25 的帧周期是 40ms场周期是 20ms那么 buffer 间隔应该是 20ms 左右。如果实测是 40ms说明驱动实际给的是整帧ALTERNATE只是个幌子。6. 排查实录与问题速查表这一章是踩坑总结症状和原因之间的对应关系基本都是实际遇到过的。6.1 四类典型症状的归因症状一静止画面正常运动物体边缘出现梳齿。这是最经典的「把隔行当逐行处理」。原因就是field设成了NONE或者驱动声明了NONE但实际给的是隔行数据。判断方法把画面冻结在一帧上放大看运动边缘梳齿的间距正好是 2 行。修复思路是让整条链路包括fmt和buf.field如实反映隔行状态然后在合适的位置做去隔行。症状二画面整体上下抖动幅度约 1 个像素行。典型的场序反了。顶场当底场用画面在垂直方向上会有半行的偏移叠加起来就是抖动。这种症状很有欺骗性因为幅度小很多人第一反应是「传感器抖动」或者「时钟抖动」去查 PLL 查了半天。快速验证法拿一张水平横线测试图如果横线在动但画面整体在细微地上下跳基本就是场序问题。症状三画面下半部花屏或者每隔一块 buffer 出现一次脏数据。buffer 尺寸算小了。要么是按整帧算的尺寸去装半帧浪费但不会坏要么是按半帧算的尺寸去装整帧越界。前者表现为下半部是上次的残留后者直接内存越界可能把相邻 buffer 踩坏。回到第 3 章的方法用QUERYBUF的length和TRY_FMT的sizeimage交叉验证。症状四ioctl(VIDIOC_S_FMT)返回成功但G_FMT读回来的 field 变了。驱动做了静默降级。有些驱动在set_fmt里发现请求的field不支持不返回错误而是自己改成一个能支持的值。这本身不算 bugV4L2 允许协商但应用必须接受协商结果。处理方式S_FMT之后一律以驱动返回值为准重新配置后续所有参数不要保留自己请求时的假设。6.2 问题速查表现象可能原因快速验证处理方向运动边缘梳齿隔行数据当逐行用冻结画面放大看边缘检查 fmt.field 与 buf.field画面小幅上下抖动顶底场序反了水平横线测试图换 INTERLACED_TB / BT 并实测下半部花屏sizeimage 算错对比 sizeimage 与自行计算值改用 QUERYBUF 的 lengthS_FMT 成功但 field 变了驱动静默降级打印 S_FMT 前后 field以返回值为准重算参数时间戳间隔翻倍ALTERNATE 实为整帧打印相邻 buffer ts 差查驱动实际出图模式链路中间 field 丢失subdev 未透传media-ctl -p 逐 pad 看修子设备的 set_fmt帧率只有一半每场一个 buffer 当整帧算统计 DQBUF 频率按场计数而非按帧计数编码后码率暴涨隔行内容直接编码对比静态和动态场景码率编码前做去隔行6.3 几个只有踩过才知道的细节别信height信sizeimage和length。半帧模式下height报整帧高度这件事不同驱动的处理并不统一。有的按文档报 1080有的报 540。与其纠结不如用sizeimage / bytesperline反推实际行数再用length兜底。buf.field和fmt.field不一致是合法的。尤其在ALTERNATE模式下fmt.field是ALTERNATE每块buf.field是TOP或BOTTOM。应用必须每块 buffer 都读一次buf.field不能缓存在一个全局变量里。sequence在 ALTERNATE 模式下的语义要实测。有的驱动一场一个 sequence 号递增有的驱动同一帧的两个场共用一个 sequence。这直接影响你怎么把两场配对。配错的表现是画面周期性闪烁因为有 50% 的概率把不同帧的场凑到一起。半帧模式的 buffer 数量要给够。整帧模式下 4 块 buffer 够用半帧模式下同样的帧率意味着 buffer 周转速度快一倍4 块很容易不够表现为DQBUF阻塞或丢帧。我一般直接给 8 块起步。测试一定要用有运动的画面。静态测试图会把所有场序问题都掩盖掉。最省事的测试源是一个缓慢横向移动的竖条或者一个钟摆。如果手头只有静态图可以在镜头前晃一支笔。7. 去隔行到底该放在哪一层field配对了紧接着的问题就是「谁来消掉这两个场」。这里面有个分工决策选错了会带来不必要的带宽开销或者画质损失。如果硬件链路里有专门的去隔行模块有些 ISP 或者 FPGA 里有那采集端应该让驱动输出V4L2_FIELD_INTERLACED之类的整帧模式把两个场都拿进来交给硬件去合成。这样应用层只面对逐行帧代码最简单延迟也最低。如果硬件没有这能力那采集端配成V4L2_FIELD_ALTERNATE一场一块 buffer应用自己配对后用软件或 GPU 做去隔行。这样灵活但应用复杂度上去了要维护场的配对状态要处理丢场的情况缓冲队列也要加深。还有一种做法是「不开去隔行直接按场输出」用非线性拉伸或者只取一场的方式。CCTV 这类场景里常见——只取顶场垂直分辨率减半但帧率不变运动看起来很流畅。这种方案在监控回放里其实观感不错代价是静态细节损失。我个人的取舍标准是看最终显示设备的刷新率和信号源场频的关系。如果信号源是 50i、显示端是 50Hz做场合并bob 或者 weave最省事延迟也最低如果显示端是 60Hz那就得考虑帧率转换去隔行的质量就变得关键了这时候软件算法比如运动自适应通常比简单的行插值效果好很多。顺带说一个容易忽略的点如果下游编码器是 H.264/HEVC并且支持隔行编码frame_mbs_only_flag0那么把隔行内容原样送进去比先去隔行再编码能省不少码率细节也保留得更好。很多编码器的隔行支持默认是关的配置的时候要显式打开。最后再分享一个我自己的习惯任何涉及field的新项目第一步都是写一个二十行的小程序只做G_FMT→ 打印 →S_FMT各种 field 值 → 每次打印返回值。这个程序不采集、不处理纯试探。跑一遍下来驱动到底支持什么、会怎么降级、返回什么奇怪值全都清清楚楚。花在这上面的二十分钟通常能抵掉后面调图像时的一整个下午——毕竟图像类的问题你看到的异常和真正的原因之间往往隔着好几层抽象。