简介在视频播放与监控上屏开发中YUV色彩空间转换是决定性能的关键环节。以YV12为代表的4:2:0平面格式若在CPU中逐像素转换为RGB会导致高占用与帧率下降。基于D3D纹理上传与像素着色器Shader的GPU渲染方案将Y/V/U平面分别填入纹理在GPU中完成颜色矩阵变换可大幅降低CPU负载并稳定帧率。本文从YV12平面布局与D3D纹理上传细节入手深入讲解Shader实现YUV转RGB的矩阵原理、有限/全范围调整及常见花屏排查为播放器、监控客户端等视频渲染场景提供可落地的工程实践。1. 基于 D3D 渲染 YV12 视频为什么 GPU 上屏成了播放器的必选项把 1080p60 的 YV12 视频帧在 CPU 里逐像素转 RGB32 再上屏CPU 占用 30% 起60fps 的流只能跑 24fps改成 D3D 纹理加 Shader让 GPU 做 YUV→RGB 转换后CPU 占用掉到个位数帧率也稳了。这就是基于 D3D 的 YV12 视频渲染要解决的问题解码器吐出的是 YUV 4:2:0 平面数据你不应该在内存里手动转 RGB而该把 Y、V、U 三个平面分别填进 D3D 纹理在像素着色器里完成颜色变换直接上屏。这套做法适合播放器内核、监控客户端、视频分析平台的上屏开发核心就落在三点YV12 平面布局、D3D 纹理上传、Shader 颜色转换。下文按布局、上传、转换、排错、验证的顺序展开每个环节都可以直接照抄。2. YV12 帧布局与 D3D 纹理上传三个平面的顺序和步长细节2.1 YV12 的平面排列V 在 U 前面别按 I420 填YV12 属于 YUV 4:2:0 平面格式一帧先放整块亮度 YW×H再放整块色度 VW/2×H/2最后放整块色度 UW/2×H/2。总大小正好是 W×H×3/2跟 I420也叫 YU12完全一样这恰恰是陷阱的来源I420 的内存顺序是 Y→U→V两者只有 U/V 两块互换接口上格式标记一错后面全部白干。最常见的现场是解码器标记的是 YV12对接代码按老项目的 I420 习惯拆平面结果画面整体发绿发紫人脸跟瘀青一样。// YV12 帧平面拆分先确认解码器给的像素格式标记 // Y 平面偏移 0V 平面偏移 W*HU 平面偏移 W*H (W/2)*(H/2) const uint8_t* pY frame; const uint8_t* pV frame width * height; const uint8_t* pU frame width * height (width / 2) * (height / 2); // I420 则是 pU 在前、pV 在后别混用 size_t frameSize width * height * 3 / 2; // 两种格式总大小相同逻辑说明这段代码只做一件事按格式标记算出三个平面的起始地址。4:2:0 的色度平面宽高都是亮度的一半所以 V/U 的尺寸必须用 width/2、height/2 去算不能拿总长度减来减去。帧总大小两个格式相同靠 size 判断格式不可靠必须看解码器暴露的像素格式字段。我一般会在一开始打一行日志把 pix_fmt 和宽高打出来再决定走哪套拆分逻辑这个习惯能省掉半小时的猜谜时间。参数上还有个容易忽略的点4:2:0 要求宽高都是偶数但解码器为了对齐宏块经常把 1080 的帧展开成 1088 行H.264 的 16×16 宏块对齐linesize 也可能比 width 大。这时候按 width×height 去算偏移会漏掉填充行画面内容下移或者底部花掉。所以拆分平面时行数要区分可见高度和缓冲高度上传时只传可见区域的图片内容。注意色度平面的偏移不能直接用 height 乘要用解码帧实际的 linesize 数组去定位否则带填充行的流会在下半屏出现错位。2.2 用 D3DFMT_L8 建纹理LockRect 的 pitch 才是数据步长Y/V/U 三个平面都是 8bit 单通道数据D3D9 里最直接的对应格式是 D3DFMT_L88 位亮度纹理。一个平面一张纹理不需要把 YUV 拼成一张图再上传拼图在内存里多一次拷贝分辨率一上来就吃亏。创建参数如下表这几个参数后面排错时会反复提到。参数取值说明FormatD3DFMT_L88 位单通道正好装一个平面UsageD3DUSAGE_DYNAMIC每帧整面更新避免驱动阻塞PoolD3DPOOL_DEFAULT与 DYNAMIC 搭配纹理留在显存MipLevels1平面数据不需要 mipmap也少碰一层 NPOT 限制// 创建三个平面纹理 IDirect3DTexture9* texY nullptr; IDirect3DTexture9* texV nullptr; IDirect3DTexture9* texU nullptr; g_device-CreateTexture(width, height, 1, D3DUSAGE_DYNAMIC, D3DFMT_L8, D3DPOOL_DEFAULT, texY, nullptr); g_device-CreateTexture(width / 2, height / 2, 1, D3DUSAGE_DYNAMIC, D3DFMT_L8, D3DPOOL_DEFAULT, texV, nullptr); g_device-CreateTexture(width / 2, height / 2, 1, D3DUSAGE_DYNAMIC, D3DFMT_L8, D3DPOOL_DEFAULT, texU, nullptr);上传代码才是重头因为纹理 pitch 和源 linesize 都不等于像素宽// 单平面上传按行拷行距各自取锁定的 Pitch 和源的 linesize void UploadPlane(IDirect3DTexture9* tex, const uint8_t* src, int srcPitch, int w, int h) { D3DLOCKED_RECT locked {}; if (tex-LockRect(0, locked, nullptr, D3DLOCK_DISCARD) ! D3D_OK) { return; } uint8_t* dst (uint8_t*)locked.pBits; for (int row 0; row h; row) { memcpy(dst row * locked.Pitch, src row * srcPitch, w); } tex-UnlockRect(0); } // 调用Y/V/U 各传一次srcPitch 取解码帧对应平面的 linesize UploadPlane(texY, pY, frameLinesize[0], width, height); UploadPlane(texV, pV, frameLinesize[1], width / 2, height / 2); UploadPlane(texU, pU, frameLinesize[2], width / 2, height / 2);逻辑说明LockRect 返回的 locked.Pitch 是纹理内部行距GPU 为了带宽对齐会把每行拉长到 32 或 64 字节对齐所以 Pitch 几乎总是大于纹理宽。源数据的 linesize 同理解码库的平面行距跟 frame width 也经常不一致。第一次写的人往往直接 memcpy(width×height)结果画面整体斜向错位一行比一行偏看起来像被斜着剪开的百叶窗这是 YV12 渲染里最容易翻车的地方。按行拷、每行截断到实际可见字节数是最稳写法。参数说明D3DLOCK_DISCARD 告诉驱动整面重写、旧内容不用保留配合动态纹理能让驱动直接换一块缓冲而不是等 GPU 读完再解锁这是视频场景里降 CPU 等待的关键。如果不加这个 flag且 GPU 上一帧还在采样同一张纹理LockRect 会阻塞到 GPU 用完为止帧率曲线直接变成锯齿状。另外用 D3DPOOL_MANAGED 池也能跑但每次锁定驱动可能在系统内存和显存之间做同步拷贝高频更新场景明显更慢。2.3 双缓冲上传把上传和渲染错开即使加了 DISCARD个别驱动在边界场景下仍会节流。更稳的做法是每平面准备两张纹理奇偶帧轮流写渲染绑定的永远是当前帧写好的那组。延迟一帧对播放器无感换来的是上传永远不会撞上 GPU 正在采样的表面。// 双缓冲平面纹理slot 用帧号最低位交替 int slot frameIndex 1; UploadPlane(texY[slot], pY, frameLinesize[0], width, height); UploadPlane(texV[slot], pV, frameLinesize[1], width / 2, height / 2); UploadPlane(texU[slot], pU, frameLinesize[2], width / 2, height / 2); // 渲染时绑定 texY[slot] / texV[slot] / texU[slot] // 三张平面必须用同一个 slot否则 Y 是上一帧、U/V 是这一帧边缘会出现彩色拖影 g_device-SetTexture(0, texY[slot]); g_device-SetTexture(1, texV[slot]); g_device-SetTexture(2, texU[slot]);逻辑说明播放器里视频解码和渲染通常不在同一线程解码线程把帧拷到共享内存渲染线程拿引用后上传。双缓冲放在渲染线程内部作用是让渲染线程自己不在上传和绘制之间互等。代价是固定多一帧延迟播放场景完全可接受收益比各种锁优化直接得多。参数说明slot 取 frameIndex 1三张平面共用同一个 slot 是硬约束。如果 Y 用了 slot 0 而 U/V 用了 slot 1画面亮度和颜色来自不同帧动态场景下边缘拖影一眼就能看出来属于双缓冲最常见的低级错误。3. Shader 把 YUV 转成 RGBBT.601 矩阵、半像素偏移与颜色范围3.1 最小可用像素着色器三张纹理加一个矩阵纹理上传到位后转换交给 GPU。核心是一个像素着色器在相同 UV 坐标下采样三张纹理做 YUV→RGB 矩阵运算。GPU 的纹理采样器天然完成色度上采样——V/U 纹理只有亮度平面的四分之一分辨率但 UV 坐标范围同样是 0..1采样器自动做双线性插值等于把色度放大回全分辨率。手动在 CPU 做色度插值既慢又多一道 buffer完全没必要。// YV12 - RGB 像素着色器PS 2.0 以上可用 sampler2D SamY : register(s0); // 亮度平面 sampler2D SamV : register(s1); // 色度 V 平面 sampler2D SamU : register(s2); // 色度 U 平面 struct VS_OUTPUT { float4 pos : POSITION; float2 uv : TEXCOORD0; }; float4 PS_YV12_RGB(VS_OUTPUT input) : COLOR0 { float y tex2D(SamY, input.uv).r; float v tex2D(SamV, input.uv).r - 0.5f; float u tex2D(SamU, input.uv).r - 0.5f; // BT.601 矩阵全范围输入适用 float r y 1.402f * v; float g y - 0.344f * u - 0.714f * v; float b y 1.772f * u; return float4(r, g, b, 1.0f); }逻辑说明色度采样后先减 0.5因为 8bit 色度的 128 表示无色差归一化后正好是 0.5减掉才有正负号。矩阵系数是 BT.601 的经典形式R 通道只受 VCr影响B 通道只受 UCb影响G 通道受两者共同影响且系数为负。这段 shader 对全范围输入精确对有限范围输入要先做 3.2 的范围扩展两个版本我建议都编译好运行时按流的 color_range 切换。渲染提交部分很简单顶点着色器输出一个全屏四边形UV 覆盖 0..1// 渲染一帧绑定三个平面纹理绘制全屏四边形 g_device-SetTexture(0, texY[slot]); g_device-SetTexture(1, texV[slot]); g_device-SetTexture(2, texU[slot]); g_device-SetPixelShader(shaderYV12); g_device-DrawPrimitive(D3DPT_TRIANGLESTRIP, 0, 2);纹理采样状态上我的习惯是亮度平面开点采样保持字幕边缘锐利色度平面开线性采样做插值。如果三张都开线性文字边缘容易有一层彩色晕圈全屏放大后尤其明显。关于半像素偏移多数 PC 播放路径其实不需要额外处理平面格式下 GPU 的双线性采样已经把色度对齐到合理位置。但个别老采集卡或特殊编码器会有约一个色度像素的偏移现象是纯色块边缘一侧挂彩边这时候把 V/U 的采样坐标按色度纹理宽度做半个纹素的平移即可// 半像素修正只在确认色度偏移时启用不要默认开 float2 chromaUV input.uv; chromaUV.x - 0.5f / (float)chromaTexWidth;3.2 全范围与有限范围画面发灰的根源是 16 不是 08bit 视频有两种电平约定有限范围TV/limitedY 落在 16~235UV 落在 16~240黑电平是 16全范围PC/fullY 落在 0~255黑电平是 0。H.264 的 8bit 编码大多走有限范围JPEG、MJPEG 和部分采集卡走全范围。如果输入是有限范围却套全范围公式黑场被算成 16/255≈0.063 而不是 0画面发灰对比度像被压过一道。// 有限范围输入先把 Y 从 16..235 拉伸回 0..1再把色度 16..240 归零到 ±0.5 float4 PS_YV12_RGB_Limited(VS_OUTPUT input) : COLOR0 { float y tex2D(SamY, input.uv).r; float v tex2D(SamV, input.uv).r; float u tex2D(SamU, input.uv).r; y (y - 16.0f / 255.0f) * (255.0f / 219.0f); u (u - 0.5f) * (255.0f / 224.0f); v (v - 0.5f) * (255.0f / 224.0f); float r y 1.402f * v; float g y - 0.344f * u - 0.714f * v; float b y 1.772f * u; return float4(r, g, b, 1.0f); }逻辑说明(y - 16/255) × (255/219) 把有限范围的 16 映射到 0、235 映射到 1色度用 255/224 缩放保证 16 和 240 分别落到 ±0.5。两个公式系数看着差别不大视觉上是「能看」和「能播」的区别。解码库一般会输出 color_range 字段TV/PCH.264 走 TV 的多但总有个别编码器标记错误或干脆不标。我的做法是把 color_range 做成运行时参数shader 用 uniform 切换宁可多传一个整数也不写死。这个字段最好从上屏模块拿不要从解码器猜DXVA 硬解拿到的视频帧经常不带范围信息只能在接入端补一个配置。3.3 BT.601 与 BT.709矩阵按分辨率切YUV→RGB 的矩阵系数取决于色彩标准标清480i/576i、DVD 级别走 BT.601高清720p/1080p 起步走 BT.709。两者对 R/B 通道的增益差异有十几个百分点用错整个画面色调都会偏红色和肤色区域最明显。通道BT.601标清BT.709高清Ry 1.402 * vy 1.575 * vGy - 0.344 * u - 0.714 * vy - 0.187 * u - 0.468 * vBy 1.772 * uy 1.856 * u实际切法很简单流分辨率大于等于 720p 用 709否则用 601解码器带 colorspace 或 VUI 信息时优先读它。很多硬解路径拿到的 NV12 帧不带这些信息所以判断必须放在上屏模块里自己处理不能指望解码器替你决定。4. 常见问题与排查花屏、偏绿、发灰的根源都在细节里这一章把我在真机上调 YV12 渲染踩过的坑按现象列出来每条按「现象 → 原因 → 解决」记临时排查直接对号入座。4.1 画面斜向撕裂一行一行错位现象画面像被斜着切开行与行之间逐步偏移右侧边缘有彩色杂色竖条拖动窗口时更明显。原因上传时对整帧做了一次性 memcpy没按行处理纹理 pitch 和源 linesize 都比像素宽大每行起始位置逐渐累积偏移。解决换成 UploadPlane 逐行拷贝锁定后每行只拷实际可见的 width 字节源和目标的行距各自用 locked.Pitch 和 linesize不要相信任何一方的默认值。4.2 整体偏绿偏紫肤色发青现象轮廓、亮度都正常但整体颜色像开了劣质滤镜白墙偏绿、肤色偏紫。原因YV12 和 I420 的 U/V 顺序搞反U 纹理里装的是 V 数据V 纹理里装的是 U 数据。解决先打印解码格式标记确认是 Y→V→U 还是 Y→U→V再按 2.1 的偏移拆平面。这里最容易的迷惑点是两个格式帧大小完全相同传错也不报错只能靠格式字段和参考帧判断。4.3 黑色不黑整体发灰现象视频黑色部分灰蒙蒙白色也不是纯白对比度像被压过。原因输入是有限范围Y 16~235却用了全范围矩阵黑电平被算成 0.063 而不是 0。解决换用 3.2 的 Limited 版本 shader并且把 color_range 做成可配置项。排查时先看黑场像素值如果回读出来是 0.06 左右而不是接近 0基本就是范围矩阵的问题。4.4 播放掉帧GPU 占用曲线像锯齿现象静止画面正常一动窗口或切台就掉帧GPU 占用在 20% 到 80% 之间来回跳。原因每帧锁定静态纹理驱动要等 GPU 释放旧缓冲或者锁定没带 D3DLOCK_DISCARD触发了一次多余的系统内存拷贝。解决纹理创建加 D3DUSAGE_DYNAMIC锁定加 D3DLOCK_DISCARD仍有波动就上 2.3 的双缓冲把上传和绘制完全错开。这个问题的隐蔽性在于它不是必现只有 GPU 负载高的时候才暴露。4.5 纹理创建失败只在部分机器上出现现象同一套代码在开发机正常换到老显卡或集显上 CreateTexture 返回无效参数或显存不足。原因D3D9 对非 2 次幂NPOT纹理的支持是条件能力1920×1080 这类分辨率在部分驱动上不允许普通用途的 NPOT 纹理常见限制包括 CLAMP 寻址、不能带 mipmap、要求动态用法。解决创建时查询设备 caps确认 NONPOW2CONDITIONAL 的约束纹理统一用 D3DUSAGE_DYNAMIC 并关掉 mipmap极端不支持的平台把纹理垫到 2048×1088 的 2 次幂尺寸UV 按实际分辨率比例缩放显示区域以外的部分不采到即可。5. 输出校验与进阶用参考帧锁定渲染正确性再顺手支持 NV12调完渲染第一件事不是看真机画面而是用参考帧验证。做法手工生成一帧已知的 YV12 彩条白、黄、青、绿、品红、红、蓝、黑按约定范围打包好喂给渲染模块再把渲染目标回读到系统内存检查关键像素的 RGB 是否与预期一致。这一步能同时验证平面顺序、颜色范围、颜色矩阵——彩条从左到右顺序对说明 U/V 没反白条是纯白说明范围没问题红条 R 接近满值而 G/B 接近零说明矩阵系数对。// 渲染目标回读仅用于验证不要放进播放热路径 IDirect3DSurface9* back nullptr; IDirect3DSurface9* staging nullptr; g_device-GetRenderTarget(0, back); D3DSURFACE_DESC desc; back-GetDesc(desc); g_device-CreateOffscreenPlainSurface( desc.Width, desc.Height, desc.Format, D3DPOOL_SYSTEMMEM, staging, nullptr); g_device-GetRenderTargetData(back, staging); D3DLOCKED_RECT locked; staging-LockRect(locked, nullptr, D3DLOCK_READONLY); // 取像素(x, y) 处 RGB ((uint8_t*)locked.pBits) y * locked.Pitch x * 4 staging-UnlockRect();逻辑说明GetRenderTargetData 把显存表面拷贝到系统内存中转表面CPU 才能读像素。验证用的彩条文件放在测试数据目录下每次换解码库、换显卡驱动、换分辨率都强制跑一遍这个自检比用眼睛在真机上猜颜色可靠得多。进阶部分NV12Y 平面加交错 UV在硬解里很常见把渲染模块从 YV12 扩到 NV12 不需要改纹理框架只差 UV 平面的拆法。NV12 的 UV 是交错的U、V 各占一个字节交替排列我一般用两个 L8 纹理加一次 CPU 解交错把它拆开成本很低shader 完全复用追求零拷贝再考虑用 V8U8 格式直接装交错后的 UV 数据。从那以后我每次换解码器、换分辨率、换驱动都先跑一遍参考帧回读再谈显示效果颜色不对就先查平面顺序再查范围矩阵不再用肉眼猜。这个习惯让我省掉了大量来回调试的时间希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 18:02:29 · 阅读 1.2k 基于D3D的YV12视频渲染：GPU纹理与Shader实现高性能上屏
简介在视频播放与监控上屏开发中YUV色彩空间转换是决定性能的关键环节。以YV12为代表的4:2:0平面格式若在CPU中逐像素转换为RGB会导致高占用与帧率下降。基于D3D纹理上传与像素着色器Shader的GPU渲染方案将Y/V/U平面分别填入纹理在GPU中完成颜色矩阵变换可大幅降低CPU负载并稳定帧率。本文从YV12平面布局与D3D纹理上传细节入手深入讲解Shader实现YUV转RGB的矩阵原理、有限/全范围调整及常见花屏排查为播放器、监控客户端等视频渲染场景提供可落地的工程实践。1. 基于 D3D 渲染 YV12 视频为什么 GPU 上屏成了播放器的必选项把 1080p60 的 YV12 视频帧在 CPU 里逐像素转 RGB32 再上屏CPU 占用 30% 起60fps 的流只能跑 24fps改成 D3D 纹理加 Shader让 GPU 做 YUV→RGB 转换后CPU 占用掉到个位数帧率也稳了。这就是基于 D3D 的 YV12 视频渲染要解决的问题解码器吐出的是 YUV 4:2:0 平面数据你不应该在内存里手动转 RGB而该把 Y、V、U 三个平面分别填进 D3D 纹理在像素着色器里完成颜色变换直接上屏。这套做法适合播放器内核、监控客户端、视频分析平台的上屏开发核心就落在三点YV12 平面布局、D3D 纹理上传、Shader 颜色转换。下文按布局、上传、转换、排错、验证的顺序展开每个环节都可以直接照抄。2. YV12 帧布局与 D3D 纹理上传三个平面的顺序和步长细节2.1 YV12 的平面排列V 在 U 前面别按 I420 填YV12 属于 YUV 4:2:0 平面格式一帧先放整块亮度 YW×H再放整块色度 VW/2×H/2最后放整块色度 UW/2×H/2。总大小正好是 W×H×3/2跟 I420也叫 YU12完全一样这恰恰是陷阱的来源I420 的内存顺序是 Y→U→V两者只有 U/V 两块互换接口上格式标记一错后面全部白干。最常见的现场是解码器标记的是 YV12对接代码按老项目的 I420 习惯拆平面结果画面整体发绿发紫人脸跟瘀青一样。// YV12 帧平面拆分先确认解码器给的像素格式标记 // Y 平面偏移 0V 平面偏移 W*HU 平面偏移 W*H (W/2)*(H/2) const uint8_t* pY frame; const uint8_t* pV frame width * height; const uint8_t* pU frame width * height (width / 2) * (height / 2); // I420 则是 pU 在前、pV 在后别混用 size_t frameSize width * height * 3 / 2; // 两种格式总大小相同逻辑说明这段代码只做一件事按格式标记算出三个平面的起始地址。4:2:0 的色度平面宽高都是亮度的一半所以 V/U 的尺寸必须用 width/2、height/2 去算不能拿总长度减来减去。帧总大小两个格式相同靠 size 判断格式不可靠必须看解码器暴露的像素格式字段。我一般会在一开始打一行日志把 pix_fmt 和宽高打出来再决定走哪套拆分逻辑这个习惯能省掉半小时的猜谜时间。参数上还有个容易忽略的点4:2:0 要求宽高都是偶数但解码器为了对齐宏块经常把 1080 的帧展开成 1088 行H.264 的 16×16 宏块对齐linesize 也可能比 width 大。这时候按 width×height 去算偏移会漏掉填充行画面内容下移或者底部花掉。所以拆分平面时行数要区分可见高度和缓冲高度上传时只传可见区域的图片内容。注意色度平面的偏移不能直接用 height 乘要用解码帧实际的 linesize 数组去定位否则带填充行的流会在下半屏出现错位。2.2 用 D3DFMT_L8 建纹理LockRect 的 pitch 才是数据步长Y/V/U 三个平面都是 8bit 单通道数据D3D9 里最直接的对应格式是 D3DFMT_L88 位亮度纹理。一个平面一张纹理不需要把 YUV 拼成一张图再上传拼图在内存里多一次拷贝分辨率一上来就吃亏。创建参数如下表这几个参数后面排错时会反复提到。参数取值说明FormatD3DFMT_L88 位单通道正好装一个平面UsageD3DUSAGE_DYNAMIC每帧整面更新避免驱动阻塞PoolD3DPOOL_DEFAULT与 DYNAMIC 搭配纹理留在显存MipLevels1平面数据不需要 mipmap也少碰一层 NPOT 限制// 创建三个平面纹理 IDirect3DTexture9* texY nullptr; IDirect3DTexture9* texV nullptr; IDirect3DTexture9* texU nullptr; g_device-CreateTexture(width, height, 1, D3DUSAGE_DYNAMIC, D3DFMT_L8, D3DPOOL_DEFAULT, texY, nullptr); g_device-CreateTexture(width / 2, height / 2, 1, D3DUSAGE_DYNAMIC, D3DFMT_L8, D3DPOOL_DEFAULT, texV, nullptr); g_device-CreateTexture(width / 2, height / 2, 1, D3DUSAGE_DYNAMIC, D3DFMT_L8, D3DPOOL_DEFAULT, texU, nullptr);上传代码才是重头因为纹理 pitch 和源 linesize 都不等于像素宽// 单平面上传按行拷行距各自取锁定的 Pitch 和源的 linesize void UploadPlane(IDirect3DTexture9* tex, const uint8_t* src, int srcPitch, int w, int h) { D3DLOCKED_RECT locked {}; if (tex-LockRect(0, locked, nullptr, D3DLOCK_DISCARD) ! D3D_OK) { return; } uint8_t* dst (uint8_t*)locked.pBits; for (int row 0; row h; row) { memcpy(dst row * locked.Pitch, src row * srcPitch, w); } tex-UnlockRect(0); } // 调用Y/V/U 各传一次srcPitch 取解码帧对应平面的 linesize UploadPlane(texY, pY, frameLinesize[0], width, height); UploadPlane(texV, pV, frameLinesize[1], width / 2, height / 2); UploadPlane(texU, pU, frameLinesize[2], width / 2, height / 2);逻辑说明LockRect 返回的 locked.Pitch 是纹理内部行距GPU 为了带宽对齐会把每行拉长到 32 或 64 字节对齐所以 Pitch 几乎总是大于纹理宽。源数据的 linesize 同理解码库的平面行距跟 frame width 也经常不一致。第一次写的人往往直接 memcpy(width×height)结果画面整体斜向错位一行比一行偏看起来像被斜着剪开的百叶窗这是 YV12 渲染里最容易翻车的地方。按行拷、每行截断到实际可见字节数是最稳写法。参数说明D3DLOCK_DISCARD 告诉驱动整面重写、旧内容不用保留配合动态纹理能让驱动直接换一块缓冲而不是等 GPU 读完再解锁这是视频场景里降 CPU 等待的关键。如果不加这个 flag且 GPU 上一帧还在采样同一张纹理LockRect 会阻塞到 GPU 用完为止帧率曲线直接变成锯齿状。另外用 D3DPOOL_MANAGED 池也能跑但每次锁定驱动可能在系统内存和显存之间做同步拷贝高频更新场景明显更慢。2.3 双缓冲上传把上传和渲染错开即使加了 DISCARD个别驱动在边界场景下仍会节流。更稳的做法是每平面准备两张纹理奇偶帧轮流写渲染绑定的永远是当前帧写好的那组。延迟一帧对播放器无感换来的是上传永远不会撞上 GPU 正在采样的表面。// 双缓冲平面纹理slot 用帧号最低位交替 int slot frameIndex 1; UploadPlane(texY[slot], pY, frameLinesize[0], width, height); UploadPlane(texV[slot], pV, frameLinesize[1], width / 2, height / 2); UploadPlane(texU[slot], pU, frameLinesize[2], width / 2, height / 2); // 渲染时绑定 texY[slot] / texV[slot] / texU[slot] // 三张平面必须用同一个 slot否则 Y 是上一帧、U/V 是这一帧边缘会出现彩色拖影 g_device-SetTexture(0, texY[slot]); g_device-SetTexture(1, texV[slot]); g_device-SetTexture(2, texU[slot]);逻辑说明播放器里视频解码和渲染通常不在同一线程解码线程把帧拷到共享内存渲染线程拿引用后上传。双缓冲放在渲染线程内部作用是让渲染线程自己不在上传和绘制之间互等。代价是固定多一帧延迟播放场景完全可接受收益比各种锁优化直接得多。参数说明slot 取 frameIndex 1三张平面共用同一个 slot 是硬约束。如果 Y 用了 slot 0 而 U/V 用了 slot 1画面亮度和颜色来自不同帧动态场景下边缘拖影一眼就能看出来属于双缓冲最常见的低级错误。3. Shader 把 YUV 转成 RGBBT.601 矩阵、半像素偏移与颜色范围3.1 最小可用像素着色器三张纹理加一个矩阵纹理上传到位后转换交给 GPU。核心是一个像素着色器在相同 UV 坐标下采样三张纹理做 YUV→RGB 矩阵运算。GPU 的纹理采样器天然完成色度上采样——V/U 纹理只有亮度平面的四分之一分辨率但 UV 坐标范围同样是 0..1采样器自动做双线性插值等于把色度放大回全分辨率。手动在 CPU 做色度插值既慢又多一道 buffer完全没必要。// YV12 - RGB 像素着色器PS 2.0 以上可用 sampler2D SamY : register(s0); // 亮度平面 sampler2D SamV : register(s1); // 色度 V 平面 sampler2D SamU : register(s2); // 色度 U 平面 struct VS_OUTPUT { float4 pos : POSITION; float2 uv : TEXCOORD0; }; float4 PS_YV12_RGB(VS_OUTPUT input) : COLOR0 { float y tex2D(SamY, input.uv).r; float v tex2D(SamV, input.uv).r - 0.5f; float u tex2D(SamU, input.uv).r - 0.5f; // BT.601 矩阵全范围输入适用 float r y 1.402f * v; float g y - 0.344f * u - 0.714f * v; float b y 1.772f * u; return float4(r, g, b, 1.0f); }逻辑说明色度采样后先减 0.5因为 8bit 色度的 128 表示无色差归一化后正好是 0.5减掉才有正负号。矩阵系数是 BT.601 的经典形式R 通道只受 VCr影响B 通道只受 UCb影响G 通道受两者共同影响且系数为负。这段 shader 对全范围输入精确对有限范围输入要先做 3.2 的范围扩展两个版本我建议都编译好运行时按流的 color_range 切换。渲染提交部分很简单顶点着色器输出一个全屏四边形UV 覆盖 0..1// 渲染一帧绑定三个平面纹理绘制全屏四边形 g_device-SetTexture(0, texY[slot]); g_device-SetTexture(1, texV[slot]); g_device-SetTexture(2, texU[slot]); g_device-SetPixelShader(shaderYV12); g_device-DrawPrimitive(D3DPT_TRIANGLESTRIP, 0, 2);纹理采样状态上我的习惯是亮度平面开点采样保持字幕边缘锐利色度平面开线性采样做插值。如果三张都开线性文字边缘容易有一层彩色晕圈全屏放大后尤其明显。关于半像素偏移多数 PC 播放路径其实不需要额外处理平面格式下 GPU 的双线性采样已经把色度对齐到合理位置。但个别老采集卡或特殊编码器会有约一个色度像素的偏移现象是纯色块边缘一侧挂彩边这时候把 V/U 的采样坐标按色度纹理宽度做半个纹素的平移即可// 半像素修正只在确认色度偏移时启用不要默认开 float2 chromaUV input.uv; chromaUV.x - 0.5f / (float)chromaTexWidth;3.2 全范围与有限范围画面发灰的根源是 16 不是 08bit 视频有两种电平约定有限范围TV/limitedY 落在 16~235UV 落在 16~240黑电平是 16全范围PC/fullY 落在 0~255黑电平是 0。H.264 的 8bit 编码大多走有限范围JPEG、MJPEG 和部分采集卡走全范围。如果输入是有限范围却套全范围公式黑场被算成 16/255≈0.063 而不是 0画面发灰对比度像被压过一道。// 有限范围输入先把 Y 从 16..235 拉伸回 0..1再把色度 16..240 归零到 ±0.5 float4 PS_YV12_RGB_Limited(VS_OUTPUT input) : COLOR0 { float y tex2D(SamY, input.uv).r; float v tex2D(SamV, input.uv).r; float u tex2D(SamU, input.uv).r; y (y - 16.0f / 255.0f) * (255.0f / 219.0f); u (u - 0.5f) * (255.0f / 224.0f); v (v - 0.5f) * (255.0f / 224.0f); float r y 1.402f * v; float g y - 0.344f * u - 0.714f * v; float b y 1.772f * u; return float4(r, g, b, 1.0f); }逻辑说明(y - 16/255) × (255/219) 把有限范围的 16 映射到 0、235 映射到 1色度用 255/224 缩放保证 16 和 240 分别落到 ±0.5。两个公式系数看着差别不大视觉上是「能看」和「能播」的区别。解码库一般会输出 color_range 字段TV/PCH.264 走 TV 的多但总有个别编码器标记错误或干脆不标。我的做法是把 color_range 做成运行时参数shader 用 uniform 切换宁可多传一个整数也不写死。这个字段最好从上屏模块拿不要从解码器猜DXVA 硬解拿到的视频帧经常不带范围信息只能在接入端补一个配置。3.3 BT.601 与 BT.709矩阵按分辨率切YUV→RGB 的矩阵系数取决于色彩标准标清480i/576i、DVD 级别走 BT.601高清720p/1080p 起步走 BT.709。两者对 R/B 通道的增益差异有十几个百分点用错整个画面色调都会偏红色和肤色区域最明显。通道BT.601标清BT.709高清Ry 1.402 * vy 1.575 * vGy - 0.344 * u - 0.714 * vy - 0.187 * u - 0.468 * vBy 1.772 * uy 1.856 * u实际切法很简单流分辨率大于等于 720p 用 709否则用 601解码器带 colorspace 或 VUI 信息时优先读它。很多硬解路径拿到的 NV12 帧不带这些信息所以判断必须放在上屏模块里自己处理不能指望解码器替你决定。4. 常见问题与排查花屏、偏绿、发灰的根源都在细节里这一章把我在真机上调 YV12 渲染踩过的坑按现象列出来每条按「现象 → 原因 → 解决」记临时排查直接对号入座。4.1 画面斜向撕裂一行一行错位现象画面像被斜着切开行与行之间逐步偏移右侧边缘有彩色杂色竖条拖动窗口时更明显。原因上传时对整帧做了一次性 memcpy没按行处理纹理 pitch 和源 linesize 都比像素宽大每行起始位置逐渐累积偏移。解决换成 UploadPlane 逐行拷贝锁定后每行只拷实际可见的 width 字节源和目标的行距各自用 locked.Pitch 和 linesize不要相信任何一方的默认值。4.2 整体偏绿偏紫肤色发青现象轮廓、亮度都正常但整体颜色像开了劣质滤镜白墙偏绿、肤色偏紫。原因YV12 和 I420 的 U/V 顺序搞反U 纹理里装的是 V 数据V 纹理里装的是 U 数据。解决先打印解码格式标记确认是 Y→V→U 还是 Y→U→V再按 2.1 的偏移拆平面。这里最容易的迷惑点是两个格式帧大小完全相同传错也不报错只能靠格式字段和参考帧判断。4.3 黑色不黑整体发灰现象视频黑色部分灰蒙蒙白色也不是纯白对比度像被压过。原因输入是有限范围Y 16~235却用了全范围矩阵黑电平被算成 0.063 而不是 0。解决换用 3.2 的 Limited 版本 shader并且把 color_range 做成可配置项。排查时先看黑场像素值如果回读出来是 0.06 左右而不是接近 0基本就是范围矩阵的问题。4.4 播放掉帧GPU 占用曲线像锯齿现象静止画面正常一动窗口或切台就掉帧GPU 占用在 20% 到 80% 之间来回跳。原因每帧锁定静态纹理驱动要等 GPU 释放旧缓冲或者锁定没带 D3DLOCK_DISCARD触发了一次多余的系统内存拷贝。解决纹理创建加 D3DUSAGE_DYNAMIC锁定加 D3DLOCK_DISCARD仍有波动就上 2.3 的双缓冲把上传和绘制完全错开。这个问题的隐蔽性在于它不是必现只有 GPU 负载高的时候才暴露。4.5 纹理创建失败只在部分机器上出现现象同一套代码在开发机正常换到老显卡或集显上 CreateTexture 返回无效参数或显存不足。原因D3D9 对非 2 次幂NPOT纹理的支持是条件能力1920×1080 这类分辨率在部分驱动上不允许普通用途的 NPOT 纹理常见限制包括 CLAMP 寻址、不能带 mipmap、要求动态用法。解决创建时查询设备 caps确认 NONPOW2CONDITIONAL 的约束纹理统一用 D3DUSAGE_DYNAMIC 并关掉 mipmap极端不支持的平台把纹理垫到 2048×1088 的 2 次幂尺寸UV 按实际分辨率比例缩放显示区域以外的部分不采到即可。5. 输出校验与进阶用参考帧锁定渲染正确性再顺手支持 NV12调完渲染第一件事不是看真机画面而是用参考帧验证。做法手工生成一帧已知的 YV12 彩条白、黄、青、绿、品红、红、蓝、黑按约定范围打包好喂给渲染模块再把渲染目标回读到系统内存检查关键像素的 RGB 是否与预期一致。这一步能同时验证平面顺序、颜色范围、颜色矩阵——彩条从左到右顺序对说明 U/V 没反白条是纯白说明范围没问题红条 R 接近满值而 G/B 接近零说明矩阵系数对。// 渲染目标回读仅用于验证不要放进播放热路径 IDirect3DSurface9* back nullptr; IDirect3DSurface9* staging nullptr; g_device-GetRenderTarget(0, back); D3DSURFACE_DESC desc; back-GetDesc(desc); g_device-CreateOffscreenPlainSurface( desc.Width, desc.Height, desc.Format, D3DPOOL_SYSTEMMEM, staging, nullptr); g_device-GetRenderTargetData(back, staging); D3DLOCKED_RECT locked; staging-LockRect(locked, nullptr, D3DLOCK_READONLY); // 取像素(x, y) 处 RGB ((uint8_t*)locked.pBits) y * locked.Pitch x * 4 staging-UnlockRect();逻辑说明GetRenderTargetData 把显存表面拷贝到系统内存中转表面CPU 才能读像素。验证用的彩条文件放在测试数据目录下每次换解码库、换显卡驱动、换分辨率都强制跑一遍这个自检比用眼睛在真机上猜颜色可靠得多。进阶部分NV12Y 平面加交错 UV在硬解里很常见把渲染模块从 YV12 扩到 NV12 不需要改纹理框架只差 UV 平面的拆法。NV12 的 UV 是交错的U、V 各占一个字节交替排列我一般用两个 L8 纹理加一次 CPU 解交错把它拆开成本很低shader 完全复用追求零拷贝再考虑用 V8U8 格式直接装交错后的 UV 数据。从那以后我每次换解码器、换分辨率、换驱动都先跑一遍参考帧回读再谈显示效果颜色不对就先查平面顺序再查范围矩阵不再用肉眼猜。这个习惯让我省掉了大量来回调试的时间希望帮到你。本文还有配套的精品资源点击获取