简介YUV_Viewer 是一款面向图像处理、视频编码学习者和开发者的YUV数据查看工具主要用于打开并显示采集到的YUV422与YUV420图像数据便于调试视频处理算法、检查图像质量或开展编码实验。压缩包共16个文件、约553KB包含C源码与头文件、Visual Studio工程及解决方案、示例YUV素材、可执行程序和说明文档工程文件保留实现结构样例素材便于直接对照查看可执行程序则方便快速验证效果。已有381人学习下载。借助这些内容读者可直观观察不同采样格式的实际画面并结合源码分析色彩空间转换、参数调整、缩放滚动等处理思路对于需要排查YUV采样、色度布局或画面异常的问题也能获得可参考的工程样本适合作为YUV色彩空间入门与视频数据处理实践的参考资料。1. 双击打不开的 .yuv先补上那份丢失的「说明书」有人丢过来一个 2.9 GB 的 sample.yuv双击没反应拖进播放器报「不支持的格式」改成 .mp4 后缀依然一片黑。文件没坏裸 YUV 本来就没有文件头——宽高、帧率、色度排布、位深全不在文件里只有一长串按固定顺序排好的采样。想查看 YUV 文件工具做的第一件事不是解码而是让你把参数手工补回去告诉它 1920×1080、I420、25 fps它才能每 3110400 字节切一帧地读下去。YUV_Viewer 干的就是这件事把没有自描述能力的字节流还原成能逐帧翻看的画面。它适合调 ISP 链路、验证编码器输入输出、排查采集丢帧的人也适合刚接手一份裸数据、连第一帧长什么样都不知道的新手。2. 一帧到底多少字节I420/NV12/YUYV/P010 的存储账本打开文件之前先把「一帧多大」算出来这是后面所有操作的基准。算错了帧边界就全错画面不是斜的就是花的算对了哪怕色彩参数没调好至少能看出内容是不是你要的那段。2.1 三种排布planar、semi-planar、packedYUV 里的 Y 是全分辨率亮度U/V 是色度按人眼对色度不敏感的特性降采样。4:2:0 表示每 2×2 个像素共用一组 UV所以色度平面在宽高两个方向都只有一半4:2:2 只在水平方向减半4:4:4 不降采样。理解这一点字节数就不用背了。I420也叫 YU12是三平面排布字节偏移可以直接写出来Y 占[0, W*H)U 占[W*H, W*H*5/4)V 占[W*H*5/4, W*H*3/2)。访问像素 (x, y) 时亮度索引是y*Wx色度索引是(y/2)*(W/2)(x/2)。NV12 只把 U、V 换成交错存放Y 平面之后每两个字节是一组 UV第 k 组在W*H2k和W*H2k1。YUYV 是打包格式四个字节Y0 U Y1 V描述两个像素一行下来字节数正好是宽度的两倍。格式采样排布单帧字节数8bit常见出处I420 / YU124:2:0Y U V 三平面W×H×3/2编码器输入、多数参考软件YV124:2:0Y V U 三平面W×H×3/2部分采集卡、老工具默认NV124:2:0Y UV 交错W×H×3/2硬件编码、系统相机NV214:2:0Y VU 交错W×H×3/2部分移动端链路YUYV / YUY24:2:2打包 Y0 U Y1 VW×H×2USB 摄像头UYVY4:2:2打包 U Y0 V Y1W×H×2采集卡直出I4444:4:4Y U V 三平面W×H×3无损中间格式、调色这张表里最坑的是前四行I420 和 YV12 字节数完全相同NV12 和 NV21 也是。格式选错时帧数对得上、时长对得上、画面结构也完全正常只有颜色反了。所以「帧数算出来是整数」只能证明宽高和采样方式没错证明不了色度顺序没错这两件事要分开验证。2.2 位深P010 的 16 位容器与「看起来像噪声」的 10 位数据10bit 内容的常见存放方式是 P010每个采样占 2 字节按 16 位小端字存放有效 10 位放在高位、低 6 位补 0也有实现放在低位这点必须实测确认。单帧字节数是 W×H×3正好是 I420 的两倍。I010 是三平面版本P016 则是 16 位全有效。把 P010 当 I420 打开是很典型的翻车现场文件字节数除以 1.5 倍帧长得到的帧数正好是真值的一半再翻倍于是你看到「帧数挺多但每帧只有半张脸」。更隐蔽的是把 10bit 当 8bit 读——取到的要么是全是低位的零要么只剩高字节的一部分信息画面暗得只剩轮廓、细节像沙粒噪点。判断方法很简单把值右移 6 位后按(v-64)*255/(940-64)映射到 0–255画面正常就是高位对齐不正常就试不右移的读法。10bit 的 limited range 是 64–940不是 16–235这一步映射错了会整体发灰。2.3 反推参数用整除性把候选范围缩小拿到一份来历不明的文件与其一个一个试不如先让文件大小替你筛。定长帧的好处是文件总字节数必然是帧长的整数倍除不尽的参数基本可以排除。# guess_params.py —— 不知道格式时用整除性排除错误组合 import os SIZE os.path.getsize(sample.yuv) # 换成你的文件路径 CANDS { I420: lambda w, h: w * h * 3 // 2, # 4:2:0 8bit NV12: lambda w, h: w * h * 3 // 2, # 与 I420 字节数相同无法靠整除区分 YUYV: lambda w, h: w * h * 2, # 4:2:2 打包 I444: lambda w, h: w * h * 3, # 与 P010 字节数相同同样无法区分 P010: lambda w, h: w * h * 3, # 4:2:0 16bit 容器 } RES [(640, 480), (1280, 720), (1920, 1080), (2560, 1440), (3840, 2160)] for name, fn in CANDS.items(): for w, h in RES: fb fn(w, h) if SIZE % fb 0 and SIZE // fb 0: print(f{name:5s} {w}x{h:4d} - {SIZE // fb:6d} 帧, 单帧 {fb} 字节)跑完你会得到一串候选然后按两条经验砍一是帧数要落在合理区间几秒钟的测试片不该算出 20 万帧二是看内容判断采样方式4:2:0 的画面在文字边缘、红色色块边缘会有明显的半分辨率色度溢出4:4:4 则没有。这段代码只做排除法不做确认最终还是要靠画面。还有一种情况会让整除性失效采集端按对齐后的行宽存图。宽度按 16 字节对齐很常见1366 会被存成 1376 甚至 1408。这时你要按对齐后的宽度填参数画面右侧会多出几条脏边但不会再斜。宽度本身已经对齐的1920、1280、3840不会有这个问题所以很多人只在特定分辨率上踩坑更难定位。帧率不影响切帧只影响播放速度。调试阶段建议先设 1 fps 或直接逐帧一上来就 30 fps 播放异常帧一闪就过去了。3. 在 YUV_Viewer 里调出第一帧四个参数与三种色彩组合工具界面通常就是「打开文件 → 选格式 → 填宽高 → 设帧率 → 应用」这一条链但没有哪个参数是可以随便填的默认值。这一章按你实际操作的顺序拆。3.1 最小信息集四个输入决定你能不能看到画面第一步永远是只看第 0 帧不要直接点播放。播放状态下画面在动你没法判断是参数错还是内容本身在动。载入文件后先看工具报出的文件大小和总帧数和 2.3 算出来的结果对一下除不尽就先回去查宽高。格式先选最可能的那一个编码器链路多半是 I420 或 NV12USB 摄像头多半是 YUYV硬件编码器输出常见 NV12 或 P010。选完不要急着下结论按 3.3 的方法验证颜色。宽高按实际画面填注意是存储宽高而不是显示宽高。有些链路会在 1080p 上下各裁几行做稳定文件里存的是 1080显示却是 1072这时候要填 1080。帧率先随便填一个接近的值比如 25 或 30只用于判断运动是否连贯不影响画面是否正确。四步做完还是黑屏或纯色先别怀疑工具去看文件头几个字节是不是全 0——空文件、写入失败、路径指向了另一个同名文件这几种情况我都遇到过。3.2 逐帧步进与拖拽定位把「花屏出现在第几帧」变成坐标定长帧最大的好处是随机访问是 O(1) 的第 n 帧的偏移就是n × 单帧字节数一次 seek 就能到位。查看器的进度条能瞬移靠的就是这个性质而不是解码缓存。定位异常帧的流程我一般这么走先拖进度条粗定位到出问题的区段再切到逐帧模式用前后翻页键把范围缩到 ±5 帧记下第一帧异常的序号 n。然后换算时间戳t n / fps拿这个时间去对采集端或编码端的日志。比起「大概在第 30 秒左右花了一下」一个精确的帧号能让对接的人少猜半小时。找到之后立刻导出这一帧存成图片。查看器一般都有单帧保存导出的图直接贴进问题单比文字描述有效得多。注意导出时把当前用的格式、宽高、色彩参数一起记在文件名或备注里否则过两天你自己都复现不出来。3.3 色彩参数601/709 与 limited/full 的四象限色度顺序对了之后画面还是可能不对问题出在矩阵系数和取值范围上。标准清晰度内容≤576p一般用 BT.601高清内容一般用 BT.709这个对应关系是经验值不是铁律屏幕录制和部分摄像头走 full range。limited range 的 BT.601 系数是R 1.164(Y-16) 1.596(V-128)G 1.164(Y-16) - 0.391(U-128) - 0.813(V-128)B 1.164(Y-16) 2.018(U-128)。BT.709 的差别在色度项R的系数变成 1.793G变成 -0.213 和 -0.533B变成 2.112。组合画面表现判断依据601 内容按 709 解红色过艳肤色偏橙红纯红块明显溢出人脸像晒伤709 内容按 601 解红色发闷肤色偏黄绿蓝天偏青红色不够亮limited 内容按 full 解整体发灰、黑不下去黑底是深灰白是浅灰对比度低full 内容按 limited 解暗部死黑、亮部过曝阴影细节全丢高光一片白四种组合里最常见的是第三种黑底发灰。因为大部分链路输出的是 limited range而不少查看器默认按 full 解释。看到「画面像蒙了一层雾」先改这一项不要急着调亮度。4:2:0 的色度上采样方式最近邻还是双线性会让彩色边缘出现块状过渡那不是错误是采样本身的信息损失。真要确认就导出一帧转成 4:4:4 再看块状还在就是内容里本来就有。4. 不装 GUI 也能查三个脚本把看图变成可批量执行的动作界面适合看不适合批量。要在一段 3000 帧的码流里找异常或者要在没有图形环境的机器上验证一份数据脚本更靠谱。下面三段都是我反复用过的只依赖 Python 标准库。4.1 单帧导出把 I420 的第 n 帧写成 BMP# yuv2bmp.py —— I420 单帧导出只用标准库 import sys def clamp(x): return 0 if x 0 else (255 if x 255 else int(x)) def yuv420_to_bgr(y_plane, u_plane, v_plane, w, h): cw w // 2 rows [] for j in range(h): row bytearray() yrow j * w urow (j // 2) * cw # 每两行共用一行色度 for i in range(w): Y y_plane[yrow i] U u_plane[urow i // 2] - 128 V v_plane[urow i // 2] - 128 C 1.164 * (Y - 16) # limited range 的 BT.601 row bytes(( clamp(C 2.018 * U), # B clamp(C - 0.391 * U - 0.813 * V), # G clamp(C 1.596 * V), # R )) rows.append(row) return rows def write_bmp(path, w, h, bgr_rows): row_size (w * 3 3) ~3 # BMP 每行按 4 字节对齐 pad b\x00 * (row_size - w * 3) body bytearray() for row in reversed(bgr_rows): # BMP 行序自下而上 body row pad head bytearray(bBM) head (54 len(body)).to_bytes(4, little) head (0).to_bytes(4, little) (54).to_bytes(4, little) head (40).to_bytes(4, little) head w.to_bytes(4, little) h.to_bytes(4, little) head (1).to_bytes(2, little) (24).to_bytes(2, little) head (0).to_bytes(4, little) len(body).to_bytes(4, little) head (2835).to_bytes(4, little) * 2 (0).to_bytes(4, little) * 2 with open(path, wb) as p a hrefhttps://download.csdn.net/download/cxw3506/4693961 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p