简介针对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裸图转JPEGC语言方案从哪下手YUV裸图在视频采集、摄像头预览和嵌入式屏幕驱动里几乎每天都要打交道它没有封装头宽高和采样格式全靠调用方自行维护。而JPEG是端侧存储和上传最常用的压缩格式C语言要实现这个转换表面看只是把数据搬进编码库但实际操作中需要面对YUV平面重排、扫描线格式、色彩空间范围、libjpeg参数初始化顺序等一系列问题。很多人第一次写完得到的图片要么偏绿偏紫要么文件损坏无法解码。这个方案面向已经在写文件操作、基本指针操作的C程序员也包含嵌入式开发者读完你就能自己实现一版可上线的yuv2jpeg工具并理解质量因子、色度采样和色彩空间三个关键参数对输出文件的影响。2. YUV格式与JPEG压缩原理以及libjpeg-turbo选型先锁定一下“YUV裸图转JPEG”里两个容易被混为一谈的概念。YUV裸图是未压缩的采样数据JPEG是压缩后的文件格式从前者到后者的路径中第一件事不是编码而是搞清楚原始YUV的分量摆放方式。采样格式不同直接决定了解析时每个平面的大小和偏移量。2.1 YUV420、YUV422、YUV444的数据排列差异YUV家族里最常见的是YUV420它把色度信息在水平和垂直方向各减半采样。以I420YUV420 planar为例文件先存放完整Y平面紧跟着是宽度、高度都减半的Cb平面最后是同样减半的Cr平面。对1280×720分辨率来说Y平面有921600字节Cb和Cr各230400字节一帧总计1382400字节。YUV422则在水平方向减半垂直方向不减所以Cb、Cr平面大小是宽半、高全YUV444三个分量等分辨率没有任何下采样。下面这张表能快速看出差异采样格式分量尺寸每像素比特一帧大小公式YUV444Y: w×h, Cb: w×h, Cr: w×h24w*h*3YUV422Y: w×h, Cb: (w/2)×h, Cr: (w/2)×h16w*h*2YUV420Y: w×h, Cb: (w/2)×(h/2), Cr: (w/2)×(h/2)12w*h*3/2这张表还有一个实际用途拿到一个YUV裸图文件后用文件大小除以宽高能反推出采样格式。比如文件大小是w*h*3/2那么基本可以确认是YUV420。不过I420和NV12都是这个大小区别只在色度平面是否交错表里这一层看不出来代码里需要用参数区分。除了planar格式还有YUYV、UYVY这类packed格式数据在行内按交错方式排列解析方式又不同。本文代码明确针对I420实现但同样的重排思路可以平移到YUV422和YUV444只要把循环里ux、uy的采样倍数调整为对应关系即可。2.2 JPEG压缩的DCT、量化、Huffman为什么保留YCbCrJPEG编码器的工作流程可以概括为把每像素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方向2x2Cb/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文件如果传FALSElibjpeg会进入只写扫描数据的模式最后不会自动补齐文件末尾的标记段普通看图软件会认为文件损坏。逐行写入时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 90quality参数范围0100越大体积越大。代码把宽高定成必选是因为YUV裸图本身不携带这些信息调用方必须从采集模块或文件命名规则里拿到。如果宽高和实际数据不匹配read_yuv420会因frame_size计算错误而读取失败或者编码出来的图片会变成拉伸变形的条纹。4. JPEG压缩参数调节与性能优化第3章的代码能跑通只是第一步真正的工程参数调节要理解libjpeg里几个关键设置。4.1 quality取值与jpeg_set_qualityjpeg_set_quality(cinfo, quality, TRUE)第三参数控制是否使用基线JPEG量化表。保持TRUE时输出文件能被所有解码器识别FALSE会放宽量化表上限在低质量区域可能省下几个KB但部分老设备解不了。所以除非有明确的兼容性测试不然极少需要设成FALSE。quality不是线性控制压缩率的旋钮。下面列的是常见应用里的质量档位经验值实际效果以目标设备上的主观观察为准quality相对体积典型场景90-100大医疗影像、编辑中间帧75-85中网页图片、照片存储55-70小监控预览、移动端缩略图40以下很小测试压缩极限画质明显劣化同一张720p的YUV420图quality90时JPEG往往在300KB以上quality70时降到120KB左右但人眼在普通屏幕上可能很难分辨差异。因此选质量参数的基准是“在目标显示尺寸下看不出明显块效应”而不是追求绝对无损。4.2 色度采样因子正确设置4:2:0、4:2:2、4:4:4libjpeg中采样因子用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即0255而很多摄像头和视频解码器输出的是limited rangeY在16235范围内。如果直接把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 YUV420quality85的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调用顺序是整个转换里最不容打破的纪律参数设得再准顺序错了也一样白费。本文还有配套的精品资源点击获取
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裸图转JPEGC语言方案从哪下手YUV裸图在视频采集、摄像头预览和嵌入式屏幕驱动里几乎每天都要打交道它没有封装头宽高和采样格式全靠调用方自行维护。而JPEG是端侧存储和上传最常用的压缩格式C语言要实现这个转换表面看只是把数据搬进编码库但实际操作中需要面对YUV平面重排、扫描线格式、色彩空间范围、libjpeg参数初始化顺序等一系列问题。很多人第一次写完得到的图片要么偏绿偏紫要么文件损坏无法解码。这个方案面向已经在写文件操作、基本指针操作的C程序员也包含嵌入式开发者读完你就能自己实现一版可上线的yuv2jpeg工具并理解质量因子、色度采样和色彩空间三个关键参数对输出文件的影响。2. YUV格式与JPEG压缩原理以及libjpeg-turbo选型先锁定一下“YUV裸图转JPEG”里两个容易被混为一谈的概念。YUV裸图是未压缩的采样数据JPEG是压缩后的文件格式从前者到后者的路径中第一件事不是编码而是搞清楚原始YUV的分量摆放方式。采样格式不同直接决定了解析时每个平面的大小和偏移量。2.1 YUV420、YUV422、YUV444的数据排列差异YUV家族里最常见的是YUV420它把色度信息在水平和垂直方向各减半采样。以I420YUV420 planar为例文件先存放完整Y平面紧跟着是宽度、高度都减半的Cb平面最后是同样减半的Cr平面。对1280×720分辨率来说Y平面有921600字节Cb和Cr各230400字节一帧总计1382400字节。YUV422则在水平方向减半垂直方向不减所以Cb、Cr平面大小是宽半、高全YUV444三个分量等分辨率没有任何下采样。下面这张表能快速看出差异采样格式分量尺寸每像素比特一帧大小公式YUV444Y: w×h, Cb: w×h, Cr: w×h24w*h*3YUV422Y: w×h, Cb: (w/2)×h, Cr: (w/2)×h16w*h*2YUV420Y: w×h, Cb: (w/2)×(h/2), Cr: (w/2)×(h/2)12w*h*3/2这张表还有一个实际用途拿到一个YUV裸图文件后用文件大小除以宽高能反推出采样格式。比如文件大小是w*h*3/2那么基本可以确认是YUV420。不过I420和NV12都是这个大小区别只在色度平面是否交错表里这一层看不出来代码里需要用参数区分。除了planar格式还有YUYV、UYVY这类packed格式数据在行内按交错方式排列解析方式又不同。本文代码明确针对I420实现但同样的重排思路可以平移到YUV422和YUV444只要把循环里ux、uy的采样倍数调整为对应关系即可。2.2 JPEG压缩的DCT、量化、Huffman为什么保留YCbCrJPEG编码器的工作流程可以概括为把每像素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方向2x2Cb/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文件如果传FALSElibjpeg会进入只写扫描数据的模式最后不会自动补齐文件末尾的标记段普通看图软件会认为文件损坏。逐行写入时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 90quality参数范围0100越大体积越大。代码把宽高定成必选是因为YUV裸图本身不携带这些信息调用方必须从采集模块或文件命名规则里拿到。如果宽高和实际数据不匹配read_yuv420会因frame_size计算错误而读取失败或者编码出来的图片会变成拉伸变形的条纹。4. JPEG压缩参数调节与性能优化第3章的代码能跑通只是第一步真正的工程参数调节要理解libjpeg里几个关键设置。4.1 quality取值与jpeg_set_qualityjpeg_set_quality(cinfo, quality, TRUE)第三参数控制是否使用基线JPEG量化表。保持TRUE时输出文件能被所有解码器识别FALSE会放宽量化表上限在低质量区域可能省下几个KB但部分老设备解不了。所以除非有明确的兼容性测试不然极少需要设成FALSE。quality不是线性控制压缩率的旋钮。下面列的是常见应用里的质量档位经验值实际效果以目标设备上的主观观察为准quality相对体积典型场景90-100大医疗影像、编辑中间帧75-85中网页图片、照片存储55-70小监控预览、移动端缩略图40以下很小测试压缩极限画质明显劣化同一张720p的YUV420图quality90时JPEG往往在300KB以上quality70时降到120KB左右但人眼在普通屏幕上可能很难分辨差异。因此选质量参数的基准是“在目标显示尺寸下看不出明显块效应”而不是追求绝对无损。4.2 色度采样因子正确设置4:2:0、4:2:2、4:4:4libjpeg中采样因子用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即0255而很多摄像头和视频解码器输出的是limited rangeY在16235范围内。如果直接把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 YUV420quality85的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调用顺序是整个转换里最不容打破的纪律参数设得再准顺序错了也一样白费。本文还有配套的精品资源点击获取
