C语言实现YUV转JPEG：libjpeg-turbo编码实践与参数详解

简介：针对C语言图像处理学习者，这份工具源码演示了YUV裸图到JPEG的完整转换流程，覆盖YUV4:2:0与YUV4:2:2格式解析、YUV转RGB色彩空间矩阵运算、基于libjpeg的DCT离散余弦变换与霍夫曼熵编码，并支持通过质量因子平衡图像大小与清晰度，适合后端开发、多媒体应用及图像压缩方向开发者参考。资源包共4个文件，包含2个C语言源文件、1个头文件和1个可直接运行的yuv2jpg可执行程序，整体仅15KB，结构精简，便于快速定位核心逻辑并二次修改。目前已有834人学习，说明该主题具有较高关注度。通过阅读源码可掌握YUV像素分量读取、RGB转换公式、JPEG文件标记（SOI、SOF、DQT、DHT、SOS）生成细节以及C语言内存分配与错误处理技巧，为后续集成到视频流处理、图片上传服务或嵌入式图像设备提供可复用基础。

1. YUV裸图转JPEG，C语言方案从哪下手

YUV裸图在视频采集、摄像头预览和嵌入式屏幕驱动里几乎每天都要打交道：它没有封装头，宽高和采样格式全靠调用方自行维护。而JPEG是端侧存储和上传最常用的压缩格式，C语言要实现这个转换，表面看只是把数据搬进编码库，但实际操作中需要面对YUV平面重排、扫描线格式、色彩空间范围、libjpeg参数初始化顺序等一系列问题。很多人第一次写完得到的图片要么偏绿偏紫，要么文件损坏无法解码。这个方案面向已经在写文件操作、基本指针操作的C程序员，也包含嵌入式开发者；读完你就能自己实现一版可上线的yuv2jpeg工具，并理解质量因子、色度采样和色彩空间三个关键参数对输出文件的影响。

2. YUV格式与JPEG压缩原理，以及libjpeg-turbo选型

先锁定一下“YUV裸图转JPEG”里两个容易被混为一谈的概念。YUV裸图是未压缩的采样数据，JPEG是压缩后的文件格式；从前者到后者的路径中，第一件事不是编码，而是搞清楚原始YUV的分量摆放方式。采样格式不同，直接决定了解析时每个平面的大小和偏移量。

2.1 YUV420、YUV422、YUV444的数据排列差异

YUV家族里，最常见的是YUV420，它把色度信息在水平和垂直方向各减半采样。以I420（YUV420 planar）为例，文件先存放完整Y平面，紧跟着是宽度、高度都减半的Cb平面，最后是同样减半的Cr平面。对1280×720分辨率来说，Y平面有921600字节，Cb和Cr各230400字节，一帧总计1382400字节。YUV422则在水平方向减半，垂直方向不减，所以Cb、Cr平面大小是宽半、高全；YUV444三个分量等分辨率，没有任何下采样。下面这张表能快速看出差异：

这张表还有一个实际用途：拿到一个YUV裸图文件后，用文件大小除以宽高，能反推出采样格式。比如文件大小是w*h*3/2，那么基本可以确认是YUV420。不过I420和NV12都是这个大小，区别只在色度平面是否交错，表里这一层看不出来，代码里需要用参数区分。

除了planar格式，还有YUYV、UYVY这类packed格式，数据在行内按交错方式排列，解析方式又不同。本文代码明确针对I420实现，但同样的重排思路可以平移到YUV422和YUV444，只要把循环里ux、uy的采样倍数调整为对应关系即可。

2.2 JPEG压缩的DCT、量化、Huffman，为什么保留YCbCr

JPEG编码器的工作流程可以概括为：把每像素8比特的YCbCr数据分成8×8块，对每个块做离散余弦变换（DCT），把空间域像素转为频率系数；再做量化，通过量化表把高频细节缩小或归零；最后对量化后的系数做Z字形扫描、游程编码和Huffman熵编码。DCT和量化是有损的关键步骤，而Huffman编码是无损的，它负责把已经压缩过的符号变得更紧凑。

C语言实现YUV转JPEG时，最不该做的一件事就是把YUV先转成RGB再交给编码器。JPEG内部本身就使用YCbCr，因为人眼对亮度变化敏感、对色度细节相对迟钝，所以编码器可以对Cb、Cr做更大程度的下采样。如果你的输入已经是YUV，那么直接以JCS_YCbCr颜色空间进入libjpeg，就能省掉一次无谓的RGB转换。这里需要区分两个名词：摄像头的YUV和JPEG的YCbCr在数学上高度相似，但不在一个色度标准下时，只差一个电平范围转换，而不是真正的色域转换。

2.3 选libjpeg-turbo，而不是自己写编码器

最稳妥的C语言实现方式是链接libjpeg或libjpeg-turbo。JPEG编码看起来好像不难，但真正写起来会发现位流写入、Huffman表构造、量化表的组织、MCU边界处理这些环节都隐藏着字节级细节。手写编码器通常要上千行才能做到稳定，而libjpeg经过几十年验证，接口稳定，错误处理完整，并且libjpeg-turbo在x86、ARM上都支持SIMD加速。在视频或连续帧转换场景下，SIMD带来的DCT加速能减少30%以上编码耗时，这是手写代码很难追上的。

因此在项目里一般选择libjpeg-turbo作为底层。它的API和libjpeg 6b完全兼容，只需要在代码中包含jpeglib.h，链接时加-ljpeg，在多数Linux发行版上安装libjpeg-turbo8-dev或libjpeg-dev即可。嵌入式平台如果没有系统包管理器，可以从官方源码交叉编译，API不变。下面的实现全部基于这套接口。

3. C语言读取YUV420裸图并编码为JPEG

这一章直接给可以编译的代码。整个程序分成读取YUV文件、重排扫描线、调libjpeg编码三个步骤，每步都用独立函数隔开，方便在工程里复用。

3.1 读取YUV420文件到内存平面

读取函数不做格式解析，只把文件内容完整读入堆内存，然后用size_t返回实际字节数。这里刻意不把“读一帧”和“解析一帧”混在一起，因为后续如果要改成循环读多帧，只用维护文件句柄和读取偏移量即可。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <jpeglib.h> #include <jerror.h> // 读取一整帧YUV420数据到堆内存，返回实际字节数 static unsigned char* read_yuv420(const char* path, int width, int height, size_t* size) { FILE* f = fopen(path, "rb"); if (!f) return NULL; // YUV420一帧大小：Y平面全尺寸，Cb/Cr各四分之一 size_t frame_size = (size_t)width * height * 3 / 2; unsigned char* buf = (unsigned char*)malloc(frame_size); if (!buf) { fclose(f); return NULL; } size_t got = fread(buf, 1, frame_size, f); fclose(f); if (got != frame_size) { free(buf); return NULL; } *size = got; return buf; }

frame_size的计算依赖YUV420的“Y全分辨率、U/V四分之一分辨率”特性，所以调用前必须确认宽高是偶数。这里用size_t计算可以避免在4K等大分辨率下int乘法溢出。实际工程里，fread可能只读回部分数据，所以更严格的写法是循环累加，直到读满frame_size。

3.2 把平面YUV重排成交错YCbCr扫描线

libjpeg的jpeg_write_scanlines接收的输入是每个像素按Y、Cb、Cr排列的交错缓冲，也就是说一行数据一行的内存布局是[Y0,Cb0,Cr0,Y1,Cb1,Cr1,...]。而I420的U、V平面是低分辨率存储，因此需要把每个U、V样本复制到对应的2×2像素区域。下面代码用最近邻方式简单处理：第y行第x个像素，使用U平面上(y/2, x/2)位置的值。

static int yuv420_to_jpeg(const char* outpath, const unsigned char* yuv_buf, int width, int height, int quality) { // 4:2:0要求宽高为偶数，否则平面大小无法整除 if ((width & 1) || (height & 1)) { fprintf(stderr, "YUV420 requires even width and height\n"); return -1; } struct jpeg_compress_struct cinfo; struct jpeg_error_mgr jerr; FILE* outfile = fopen(outpath, "wb"); if (!outfile) return -1; // 初始化libjpeg压缩对象和错误处理 cinfo.err = jpeg_std_error(&jerr); jpeg_create_compress(&cinfo); jpeg_stdio_dest(&cinfo, outfile); // 输入尺寸和颜色空间：YCbCr三分量 cinfo.image_width = width; cinfo.image_height = height; cinfo.input_components = 3; cinfo.in_color_space = JCS_YCbCr; jpeg_set_defaults(&cinfo); jpeg_set_quality(&cinfo, quality, TRUE); // 显式指定4:2:0色度采样：Y方向2x2，Cb/Cr各1x1 cinfo.comp_info[0].h_samp_factor = 2; cinfo.comp_info[0].v_samp_factor = 2; cinfo.comp_info[1].h_samp_factor = 1; cinfo.comp_info[1].v_samp_factor = 1; cinfo.comp_info[2].h_samp_factor = 1; cinfo.comp_info[2].v_samp_factor = 1; jpeg_start_compress(&cinfo, TRUE); // I420平面布局：Y平面之后依次是U、V平面 const unsigned char* Y = yuv_buf; const unsigned char* U = yuv_buf + (size_t)width * height; const unsigned char* V = U + (size_t)(width / 2) * (height / 2); // 每行分配一个YCbCr交错缓冲，避免整帧大块内存 unsigned char* row_buf = (unsigned char*)malloc((size_t)width * 3); if (!row_buf) { jpeg_destroy_compress(&cinfo); fclose(outfile); return -1; } JSAMPROW row_pointer[1]; row_pointer[0] = row_buf; for (int y = 0; y < height; y++) { for (int x = 0; x < width; x++) { // 亮度Y直接对应Y平面坐标 row_buf[x * 3 + 0] = Y[y * width + x]; // 色度U、V做最近邻重采样 int ux = x >> 1; int uy = y >> 1; row_buf[x * 3 + 1] = U[uy * (width >> 1) + ux]; row_buf[x * 3 + 2] = V[uy * (width >> 1) + ux]; } // 逐行写入JPEG扫描线 jpeg_write_scanlines(&cinfo, row_pointer, 1); } free(row_buf); jpeg_finish_compress(&cinfo); jpeg_destroy_compress(&cinfo); fclose(outfile); return 0; }

这段代码需要注意几个参数。image_width和image_height是原始图像的像素尺寸；input_components设为3是因为每个像素需要Y、Cb、Cr三个值；in_color_space设为JCS_YCbCr是告诉libjpeg输入已经是YCbCr，不要再做RGB转换。jpeg_set_quality放在jpeg_set_defaults之后、jpeg_start_compress之前，量化表才会按目标质量重建。comp_info数组是jpeg_set_defaults分配的，所以必须在这之后改采样因子。row_buf每行重新填充，jpeg_write_scanlines每次写一行，这样即使图像高度很大，内存占用也只随宽度增加。

3.3 初始化libjpeg压缩对象并逐行写JPEG

上面的yuv420_to_jpeg函数把libjpeg生命周期完整串起来了：创建压缩对象、设置参数、开始压缩、写扫描线、结束压缩、销毁对象。这个顺序不能颠倒，尤其注意jpeg_start_compress的第二个参数传TRUE，表示要输出一个完整的JPEG文件；如果传FALSE，libjpeg会进入只写扫描数据的模式，最后不会自动补齐文件末尾的标记段，普通看图软件会认为文件损坏。

逐行写入时，jpeg_write_scanlines的返回值是实际写入的行数，正常为1。如果上一行写入失败，返回值会是0，此时应当退出循环并检查cinfo的err处理链。libjpeg默认的错误处理是jpeg_std_error(&jerr)，但遇到错误会直接调用exit，在库函数里这样做并不友好，生产环境可以自定义error_exit方法捕获异常，但示例代码从简。

3.4 main函数与gcc编译命令

主函数把命令行参数映射到上述两个调用。宽高是必选参数，质量可选，缺省用85。这样可以避免在文件头里储存宽高带来的歧义。

int main(int argc, char** argv) { // 参数格式：input.yuv output.jpg width height [quality] if (argc < 5) { fprintf(stderr, "Usage: %s input.yuv output.jpg width height [quality]\n", argv[0]); return 1; } int width = atoi(argv[3]); int height = atoi(argv[4]); int quality = argc > 5 ? atoi(argv[5]) : 85; size_t yuv_size = 0; unsigned char* yuv_buf = read_yuv420(argv[1], width, height, &yuv_size); if (!yuv_buf) { fprintf(stderr, "Failed to read YUV frame\n"); return 1; } int ret = yuv420_to_jpeg(argv[2], yuv_buf, width, height, quality); free(yuv_buf); return ret; }

编译命令：

gcc -O2 -o yuv2jpeg yuv2jpeg.c -ljpeg

运行：

./yuv2jpeg frame_1280x720.yuv out.jpg 1280 720 90

quality参数范围0～100，越大体积越大。代码把宽高定成必选，是因为YUV裸图本身不携带这些信息，调用方必须从采集模块或文件命名规则里拿到。如果宽高和实际数据不匹配，read_yuv420会因frame_size计算错误而读取失败，或者编码出来的图片会变成拉伸变形的条纹。

4. JPEG压缩参数调节与性能优化

第3章的代码能跑通只是第一步，真正的工程参数调节要理解libjpeg里几个关键设置。

4.1 quality取值与jpeg_set_quality

jpeg_set_quality(&cinfo, quality, TRUE)第三参数控制是否使用基线JPEG量化表。保持TRUE时输出文件能被所有解码器识别；FALSE会放宽量化表上限，在低质量区域可能省下几个KB，但部分老设备解不了。所以除非有明确的兼容性测试，不然极少需要设成FALSE。

quality不是线性控制压缩率的旋钮。下面列的是常见应用里的质量档位经验值，实际效果以目标设备上的主观观察为准：

同一张720p的YUV420图，quality=90时JPEG往往在300KB以上，quality=70时降到120KB左右，但人眼在普通屏幕上可能很难分辨差异。因此选质量参数的基准是“在目标显示尺寸下看不出明显块效应”，而不是追求绝对无损。

4.2 色度采样因子：正确设置4:2:0、4:2:2、4:4:4

libjpeg中采样因子用comp_info数组表达，comp_info[0]对应亮度，comp_info[1]和comp_info[2]对应两个色度分量。前面代码里把Y设为2×2、Cb和Cr设为1×1，等价于4:2:0采样，与输入YUV420匹配。如果输入是YUV422，需要把comp_info[1]的h_samp_factor和comp_info[2]的h_samp_factor都改成2，同时v_samp_factor保持1。而YUV444输入则把所有采样因子设为1。

之所以要让采样因子和输入格式对齐，是因为libjpeg会按这个因子对输入的全分辨率YCbCr数据做下采样。假如输入是YUV444，却设置了4:2:0，编码器会对色度做额外的一半下采样，输出JPEG解码出来的色度分辨率会低于原始数据，表现为彩色边缘模糊。反过来，如果输入是YUV420却设置4:4:4，则需要把缺失的色度样本自己填充成每像素都有CbCr，否则行缓冲区里会读到垃圾数据。

4.3 色彩空间JCS_YCbCr与JCS_RGB的选择

in_color_space可以设成JCS_RGB，但YUV裸图转JPEG时设成JCS_YCbCr才是正确选择。因为YUV420读取后本来就是Y、Cb、Cr分量，重排成交错格式后直接进编码器，不需要任何颜色转换。如果先转RGB再编码，会经历一次YCbCr→RGB和一次RGB→YCbCr，两次取整误差会叠加，尤其是暗部区域更容易出现色彩断层。

还有一个容易被忽略的点是JPEG内部的YCbCr是full range，即0～255，而很多摄像头和视频解码器输出的是limited range，Y在16～235范围内。如果直接把limited range数据塞给libjpeg，输出JPEG会看起来对比度不足。常见做法是在重排循环里先做一次线性映射，把[16,235]映射到[0,255]，U、V分量类似地处理。这样牺牲几个字节的压缩率，但显示效果更正常。

4.4 重排优化、SIMD和帧并行

第3章的逐像素重排代码最易成为瓶颈的是ux = x >> 1和uy = y >> 1对内存的随机访问。因为U、V平面比较小，缓存其实能装下，但每次像素都做除法定位，会增加整数运算量。一个简单的优化是改成每两个像素复制同一个U、V值，也就是在x循环内先取好U、V，再连续写两遍。这样对1280×720的一帧图可以减少一半的ux计算。

libjpeg-turbo已经用SIMD加速了DCT和量化，所以不要再试图手写向量化代码替代它。更实际的加速是让多个YUV帧并行编码：为每个线程创建独立的jpeg_compress_struct，共享同一个jpeg_error_mgr或各自分配一个，然后按帧序号合并文件。注意libjpeg的压缩对象不是线程安全的，绝对不要在多线程里调用同一个cinfo去jpeg_write_scanlines。用OpenMP可以简单地把循环并行化，编码结束后按帧序拼接输出流。

5. 验证JPEG输出与三个常见坑

最后落到收尾技巧，怎么确认生成的JPEG是对的，以及哪几个位置最容易翻车。

5.1 快速验证：文件大小和identify

转换后的第一件事不是打开看图软件，而是检查输出文件大小。假定输入140万字节的720p YUV420，quality=85的JPEG输出应在200KB上下。如果只有几KB，多半是宽高设置错误导致只编码了部分数据；如果接近原始大小，则jpeg_set_quality可能没有生效。再用identify -verbose out.jpg查看Colorspace，如果在JCS_YCbCr下显示成Gray，说明input_components被误改成1，需要回查代码。

5.2 扫描线对齐、U/V顺序、色彩范围

扫描线宽度不匹配是C语言实现里最难发现的bug。libjpeg的row_buf只要连续分配即可，不需要额外对齐，但如果你用了一个按行分配的二维数组，而第二维大小刚好多出几个像素，最后一列颜色就会错乱。建议统一用一维row_buf加偏移量访问，避免踩到栈对齐问题。

U/V顺序互换会让整张图片偏紫或偏青。I420的顺序是Y、Cb、Cr，而YV12的色度顺序是Y、Cr、Cb。read_yuv420只读字节流，不知道原始顺序，所以代码里应让调用方传入i420或yv12参数，而不是固定一种。如果发现输出整体偏色，先交换U、V指针位置，这会比调试像素逻辑快得多。

色彩范围问题上一章提过，这里再给一个判断技巧：取生成JPEG的纯黑区域，用解码器读出Y值，如果大于20，说明输入的黑电平并没有到0。可以在主函数里临时增加一个--full-range开关，默认关闭，让用户根据YUV源实际情况决定是否做[16,235]到[0,255]的映射。

5.3 用亮度差分验证编码正确性

如果要做自动化测试，可以比较原YUV和JPEG解码结果的亮度分量。把生成的JPEG用libjpeg解码回RGB并转成Y，与原YUV的Y平面逐像素求平均绝对误差，正常质量85下这个误差一般小于3。误差明显偏大，先检查重排循环里U、V索引是否写错；误差表现为某个区域块状，则可能是采样因子设错了。

最后一个实用技巧：把jpeg_finish_compress调用放在jpeg_destroy_compress之前，并且始终检查它的返回值。jpeg_finish_compress负责冲刷位流并写入JPEG尾部标记，漏掉它会导致文件损坏。libjpeg的API调用顺序是整个转换里最不容打破的纪律，参数设得再准，顺序错了也一样白费。

本文还有配套的精品资源，点击获取