1. 从像素到数据流理解YUV的底层逻辑刚入行做音视频开发那会儿最让我头疼的就是各种YUV格式。拿到一个视频帧数据明明都是YUV怎么有的文件大有的文件小怎么有的解码出来颜色怪怪的有的在手机上显示就正常后来才明白这背后全是YUV不同“格式”在作祟。今天我就把自己这些年踩过的坑、总结的经验掰开揉碎了跟大家聊聊YUV的各种格式特别是YUV420P、YUV420SP、NV12、NV21这些高频出现的“明星”。无论你是做Android相机开发、视频编解码还是图像处理搞懂这些格式就等于拿到了处理视频数据的钥匙。简单来说YUV是一种颜色编码方式它和咱们更熟悉的RGB走的是两条路。RGB是直接描述红、绿、蓝三个颜色通道的强度而YUV则把亮度信息Y和颜色信息UV分离开。这么做的最大好处就是人类视觉对亮度敏感对颜色没那么敏感。基于这个特性我们就可以对UV分量进行“抽稀”也就是下采样在几乎不损失主观画质的前提下大幅减少数据量。这就是为什么视频压缩比如H.264, H.265普遍采用YUV格式尤其是YUV420系列格式作为原始数据的原因——它天生就为压缩做好了准备。那么YUV后面的“420”、“422”、“444”这些数字又是什么意思呢这指的是色度分量UV相对于亮度分量Y的采样比例。比如YUV444就是Y、U、V三个分量1:1:1全采样一个像素点对应一组YUV数据量最大色彩也最保真常见于专业影视后期。而YUV420则是每4个Y亮度像素共享一组UV颜色信息。具体来说在水平和垂直方向上色度分量都只采样亮度分量的一半。这样一来数据量直接减少到YUV444的一半计算一下假设Y分量占1UV在444下各占1共3份在420下U和V各在水平和垂直方向减半即各占1/4加起来占0.5所以总数据量为1 0.25 0.25 1.5份。我们今天重点要掰扯的YUV420P和YUV420SP都属于这个“经济实惠”的YUV420大家族区别就在于这些分量数据在内存里是怎么“排队”的。2. 家族图谱YUV420P与YUV420SP的核心分野理解了YUV420的采样原理我们就要面对下一个实际问题这些采样后的Y、U、V数据在内存或文件里该怎么排列这就引出了“打包”Packed和“平面”Planar两种主要的存储格式。你可以把内存想象成一条长长的流水线YUV数据就是需要被摆放的货物。“平面”格式相当于把同类货物集中堆放先放完所有的Y亮度再放所有的U蓝色色差最后放所有的V红色色差。而“打包”格式则是把相关联的货物紧挨着放更注重局部顺序。2.1 YUV420P清晰规整的“平面”格式YUV420P这个“P”代表的就是“Planar”平面格式。它是YUV420采样下最直观、最规整的一种存储方式。它的数据排列遵循严格的顺序先存储一整帧所有的Y分量接着存储所有的U分量最后存储所有的V分量。三个分量在内存中是三个连续且独立的大数组。假设我们有一帧分辨率为Width x Height的图像。Y分量大小为Width * Height字节。因为每个像素都需要一个亮度值。U分量大小为(Width/2) * (Height/2)字节。由于是420采样UV在宽和高上都减半。V分量大小与U分量相同也是(Width/2) * (Height/2)字节。所以一帧YUV420P图像的总数据量是Width * Height * 1.5字节。例如一张1920x10801080P的图片其YUV420P数据大小就是1920 * 1080 * 1.5 3,110,400字节约等于2.97MB。它的优点非常明显结构清晰处理方便由于三个分量完全分离如果你想单独对亮度Y进行锐化处理或者只提取色度UV进行分析操作起来非常直接只需在对应的内存块进行即可无需考虑交织问题。通用性强很多传统的图像处理库、编解码器的内部处理或某些输入输出格式都默认或倾向于使用平面格式因为算法逻辑更简洁。易于理解对于学习和调试来说YUV420P的布局是最容易可视化和理解的。但缺点也同样突出内存访问可能不连续对于需要同时用到Y、U、V数据的操作比如色彩空间转换回RGB由于三个分量存放在相距较远的内存区域可能会造成缓存命中率降低影响性能。这在性能敏感的实时处理场景需要留意。某些硬件不原生支持一些针对视频播放或相机采集优化过的硬件如移动设备的GPU、显示控制器其设计更倾向于接下来要讲的打包格式对平面格式的支持可能需要额外的软件转换带来开销。2.2 YUV420SP与它的双子星NV12与NV21YUV420SP这里的“SP”代表“Semi-Planar”半平面格式。它是平面和打包格式的一种折中也是目前在移动平台Android、iOS和许多视频编解码硬件上最流行、最受支持的一种格式。它把Y分量单独存放一个平面而把U和V分量交错打包在一起形成另一个平面。具体来说YUV420SP又主要分为两种子格式NV12和NV21。它们可以看作是孪生兄弟核心结构一样只是“UV”的排列顺序相反。NV12格式常见于Windows、Intel平台平面1Y Plane先存储所有Width * Height个Y分量。平面2UV Interleaved Plane紧接着存储所有交织在一起的U和V分量。注意这个平面的大小是Width * (Height/2)字节。它是如何交织的呢在这个平面里数据以两个字节为一组进行排列每组内是[U, V, U, V, ...]的顺序。对于每个2x2的像素块4个Y对应一组[U, V]值。在内存中UV平面先是一行U、V、U、V...接着下一行继续。NV21格式Android相机默认输出格式平面1Y Plane与NV12完全相同存储所有Y分量。平面2VU Interleaved Plane与NV12的唯一区别在于交织顺序。它存储的是[V, U, V, U, ...]的顺序。也就是说每个2字节组是V在前U在后。为什么SP格式如此受硬件青睐内存访问更高效对于渲染和显示操作GPU或显示控制器通常需要快速将YUV转换为RGB。NV12/NV21的布局Y单独UV交织非常匹配这些硬件的纹理采样方式。它们可以很容易地将Y平面当作一个亮度纹理将UV交织平面当作一个双通道的色度纹理来读取效率很高。节省内存带宽相较于YUV420P需要三次独立的内存读取Y、U、VNV12/NV21通常只需要两次Y一次UV交织平面一次减少了内存访问次数。事实上的移动端标准Android的Camera API默认输出NV21iOS的Camera采集通常也是类似格式。大部分移动GPU对NV12/NV21有直接的硬件加速支持。注意这里有一个非常关键的实操点。当你从Android相机获取Image对象使用Camera2 API或处理预览回调数据时默认格式往往是NV21。但很多图像处理库如OpenCV的默认YUV输入格式可能是YUV420P。如果你不经过转换直接处理必然得到色彩错乱的结果。我早期就曾在这里栽过大跟头调试了半天才发现是格式没对应上。3. 实战中的格式抉择与转换知道了理论我们最终还是要落到代码和操作上。在实际项目中你会在哪些环节碰到这些格式又该如何处理呢3.1 典型来源与应用场景YUV420P常见于FFmpeg解码输出使用libswscale进行缩放或格式转换时常指定AV_PIX_FMT_YUV420P作为输出。某些视频文件原始数据如一些未压缩的YUV测试序列文件.yuv通常约定俗成使用YUV420P格式存储。软件编码器输入一些纯软件的编码器库可能更接受平面格式的数据作为输入。图像算法处理中间态在做一些复杂的、需要独立访问色度分量的图像分析时平面格式更方便。NV12/NV21常见于Android Camera预览Camera2API的ImageReader或旧版Camera的预览回调。iOS Camera采集通过AVCaptureVideoDataOutput获取的CMSampleBuffer其底层像素格式通常是kCVPixelFormatType_420YpCbCr8BiPlanarFullRange本质上就是NV12。硬件编解码器无论是MediaCodecAndroid、VideoToolboxiOS还是Intel的Quick Sync Video其输入的原始帧和输出的解码帧普遍支持NV12作为首选格式因为硬件管线就是按这个优化的。GPU纹理与渲染在OpenGL ES或Vulkan中渲染YUV视频通常将Y平面和UV交织平面分别绑定到不同的纹理单元NV12/NV21的布局天生适合这种操作。3.2 格式转换绕不开的实操环节格式转换是音视频开发中的家常便饭。下面以最常见的NV21 (YUV420SP) 转 RGB以及NV21 转 YUV420P为例说明其中的要点。1. NV21 转 RGB用于显示或图像处理这是移动端最频繁的操作之一因为相机采集的是NV21而屏幕显示需要RGB。有几种实现方式使用渲染API高效在Android上你可以用OpenGL ES编写一个着色器Shader在GPU上直接完成YUV到RGB的转换和渲染。这是性能最好的方式因为数据无需从GPU内存读回CPU。// 片段着色器示例 (简化版用于NV21即Y平面 VU交织平面) precision mediump float; uniform sampler2D u_TextureY; // Y平面纹理 uniform sampler2D u_TextureUV; // UV交织平面纹理 (VU顺序) varying vec2 v_TexCoord; void main() { float y texture2D(u_TextureY, v_TexCoord).r; vec2 uv texture2D(u_TextureUV, v_TexCoord).rg; // 这里rg对应V和U float v uv.r; float u uv.g; // YUV to RGB 转换公式 (ITU-R BT.601 或 BT.709需与数据范围匹配) float r y 1.402 * (v - 0.5); float g y - 0.344136 * (u - 0.5) - 0.714136 * (v - 0.5); float b y 1.772 * (u - 0.5); gl_FragColor vec4(r, g, b, 1.0); }使用系统APIAndroid提供了YuvImage类可以将NV21数据压缩成JPEG但直接转RGB不太方便。更高效的是使用RenderScript或最新的Vulkan计算着色器但复杂度较高。使用第三方库便捷OpenCV的cvtColor函数非常强大。// C (OpenCV) 示例 cv::Mat nv21Mat(height * 3 / 2, width, CV_8UC1, nv21Data); // 将NV21数据包装成Mat cv::Mat bgrMat; cv::cvtColor(nv21Mat, bgrMat, cv::COLOR_YUV2BGR_NV21); // 注意颜色顺序是BGR实操心得OpenCV的COLOR_YUV2BGR_NV21这个枚举值其内部预期的是VU交织的顺序正好对应Android的NV21。如果你误用了COLOR_YUV2BGR_NV12颜色会完全不对。这是一个经典的坑。2. NV21 转 YUV420P用于特定处理或编码有时算法或编码器要求平面格式输入就需要转换。// 伪代码逻辑清晰展示过程 void NV21_to_YUV420P(unsigned char* nv21, unsigned char* yuv420p, int width, int height) { int frameSize width * height; int uvSize frameSize / 4; // U或V分量的大小 // 1. 拷贝Y平面 (完全一样) memcpy(yuv420p, nv21, frameSize); // yuv420p[0...frameSize-1] Y unsigned char* uvPlane nv21 frameSize; // NV21的UV交织平面起始位置 unsigned char* uPlane yuv420p frameSize; // YUV420P的U平面起始位置 unsigned char* vPlane uPlane uvSize; // YUV420P的V平面起始位置 // 2. 从交织的VU平面中分离出U和V for (int i 0; i uvSize; i) { // NV21交织顺序是 VU, VU, VU... vPlane[i] uvPlane[2 * i]; // 取偶数索引位是V uPlane[i] uvPlane[2 * i 1]; // 取奇数索引位是U } }这个过程本质上是数据重组将交织的数据“解编织”成两个独立的平面。注意循环的边界是uvSize即U或V分量的像素数因为交织平面每两个字节对应一组VU。4. 深度辨析与性能考量4.1 NV12 vs NV21不仅仅是顺序问题NV12和NV21在数据量、内存布局上完全一致唯一的区别就是UV的交织顺序。那为什么还要区分呢这主要是历史沿革和平台生态决定的。NV12更像是PC和英特尔生态下的“标准”很多Windows平台的SDK、Intel的媒体SDK默认支持它。NV21则是Android生态的“亲儿子”从底层驱动到上层API都为其做了优化。对开发者的影响关键在于“匹配”。你的处理管线必须知道源头是什么格式。例如如果你用Android相机采集得到NV21然后直接丢给一个预期NV12的硬件编码器颜色会错乱红蓝对调。同样一个Windows上的视频处理库输出NV12你直接在Android的SurfaceView上显示而不做转换也会出问题。转换技巧NV12和NV21互转极其简单本质上就是交换交织平面中每两个字节的顺序。void swapNV12_NV21(unsigned char* uvPlane, int uvPlaneSize) { // uvPlane 是交织平面的起始指针大小是 width * height / 2 for (int i 0; i uvPlaneSize; i 2) { unsigned char temp uvPlane[i]; uvPlane[i] uvPlane[i 1]; uvPlane[i 1] temp; } // 执行后NV12变NV21NV21变NV12 }4.2 性能与内存的权衡选择哪种格式往往是性能、便利性和兼容性权衡的结果。考量维度YUV420P (Planar)YUV420SP (NV12/NV21)点评CPU处理便利性高。分量独立易于单独处理或抽取。中。Y分量独立易处理但UV交织分离需要额外步骤。做纯软件的颜色调整、分析YUV420P更顺手。GPU渲染/显示效率低。需要三个纹理或更复杂的采样。高。天然匹配双平面纹理采样硬件加速支持好。只要是涉及屏幕显示或GPU处理SP格式是首选。硬件编解码支持部分支持可能需内部转换。广泛支持通常是首选输入/输出格式。用硬件编解码器MediaCodec, VideoToolbox时尽量喂给它NV12。内存访问局部性可能较差。Y/U/V数据相距较远。较好。Y和UV分别集中访问模式更连续。对于缓存不友好的CPUSP格式可能略有优势。数据交换通用性较高是很多算法和测试的“中间语言”。较高尤其是跨移动和PC平台时需注意NV12/NV21区别。FFmpeg等工具链对两者支持都很好转换成本低。一个真实的性能对比案例在开发一个Android视频通话应用时我们需要对前置摄像头采集的NV21帧做人脸贴纸效果。最初方案是在CPU上将NV21转成RGB然后用图形库处理再转回NV21送给编码器帧率只能到15fps。后来优化为1使用RenderScript直接在YUV空间进行简单色彩调整避免RGB转换2复杂的贴图渲染改用OpenGL ES接收NV21的Y和UV平面作为纹理在着色器里完成YUV到RGB的转换和渲染最终输出纹理直接作为编码器输入通过Surface。优化后帧率稳定在30fps。这个案例的核心就是减少不必要的格式转换尤其是CPU上的转换并充分利用GPU对SP格式的原生支持。5. 开发中的常见“坑”与排查指南即使理解了原理实际编码时还是会遇到各种诡异问题。下面是我总结的几个高频“坑点”和排查思路。5.1 颜色错乱红蓝颠倒、色彩怪异这是YUV格式问题中最典型的表现。症状图像整体偏蓝或偏红或者颜色完全失真。可能原因及排查UV顺序搞反这是最大的嫌疑。检查你的数据源格式是NV12还是NV21再检查你的处理或显示代码预期的格式。重点核对OpenCV的cvtColor枚举值、GLSL着色器中的UV采样顺序、以及任何自定义转换代码中的数组索引。YUV范围弄错YUV数据有“有限范围”Limited Range也叫TV RangeY16~235, UV16~240和“全范围”Full Range PC Range YUV0~255之分。如果你用全范围的公式去处理有限范围的数据颜色会发灰、对比度不足。务必确认数据源的范围并选用正确的转换矩阵BT.601/709公式也分范围版本。分量错位误将U平面数据当作V平面使用或者YUV三个平面的数据指针计算错误。仔细检查内存拷贝或指针运算的偏移量。5.2 图像扭曲、绿屏或马赛克症状图像出现错行、撕裂、大面积绿色或彩色块。可能原因及排查分辨率/步长Stride问题很多时候图像数据在内存中的“宽度”步长并不等于图像的“像素宽度”。特别是摄像头采集或解码器输出的数据为了内存对齐步长可能是大于等于宽度的某个值如16的倍数。如果你在处理时直接按像素宽度去计算行偏移就会错位。必须使用API提供的stride或rowStride参数而不是width。数据大小计算错误误将YUV444的数据大小公式用于YUV420。牢记YUV420的数据量是width * height * 1.5。分配缓冲区时大小不足会导致内存越界进而引发各种不可预知的问题。UV分量下采样理解错误在手动处理UV分量时错误地以为UV分量大小是width/2 * height或width * height/2。正确的是(width/2) * (height/2)。这个错误会导致UV数据被过度拉伸或压缩。5.3 性能瓶颈症状处理视频帧时CPU占用过高帧率上不去。可能原因及优化在CPU端进行频繁的YUV-RGB转换这是性能杀手。尽可能在GPU端进行转换和渲染。如果必须在CPU端处理考虑使用NEONARM或SSEx86指令集进行优化。不必要的格式转换链例如摄像头NV21 - 转RGB - 算法处理 - 转YUV420P - 编码器。审视整个管线看能否消除中间转换。也许算法可以直接支持YUV处理或者编码器可以直接接受NV21。内存拷贝过多尽量避免在流程中来回拷贝完整的帧数据。使用零拷贝机制如Android的ImageReader直接获取ByteBuffer或使用Surface在GPU和编码器之间传递数据。5.4 工具辅助排查工欲善其事必先利其器。调试YUV问题有几个小工具特别好用二进制查看器/十六进制编辑器直接查看原始YUV数据文件确认文件大小是否符合预期并手动解析开头部分验证Y、U、V分量的排列顺序。例如一个YUV420P文件开头width*height字节应该是连续的亮度值变化相对平缓之后是色度值。FFmpeg它是处理YUV的瑞士军刀。转换格式ffmpeg -s 1920x1080 -pix_fmt nv21 -i input.nv21 -pix_fmt yuv420p output.yuv查看信息ffplay -f rawvideo -video_size 1920x1080 -pix_fmt yuv420p input.yuv可以直接播放原始YUV文件帮助你直观判断格式是否正确。生成测试图ffmpeg -f lavfi -i testsrcsize640x480:rate1 -vframes 1 -pix_fmt yuv420p test.yuv可以生成一个标准测试图用于验证你的处理流程。编写简单的验证程序自己写一个小程序将YUV文件中的Y分量单独提取出来保存为灰度图将UV分量转换为RGB色块图。通过观察生成的图片可以非常直观地判断各个分量是否正确。说到底处理YUV格式就像是在和数据的“排兵布阵”打交道。核心就两点一是脑子里要有一张清晰的“内存地图”知道Y、U、V这三个兵种各自站在队伍的什么位置二是要清楚你的“盟友”摄像头、编码器、渲染器他们习惯哪种阵型。把这两点吃透了无论遇到NV12、NV21还是YUV420P你都能一眼看穿它的底细轻松地让数据在不同的流程间正确流转。