音视频图片压缩

不一定“必须压缩”，但实际项目里，视频/图片经常需要压缩；音频看场景，很多时候可以不压缩。

核心判断标准只有一个：

采集数据量 ≤ 传输带宽 / 存储速度 / MCU处理能力
能扛住就不用压缩，扛不住就必须压缩。

1. RGB Image Sensor 采集到的数据是什么？

摄像头出来的原始数据可能是：

RAW Bayer // 传感器最原始数据，常见于摄像头内部 YUV422 // 很多摄像头模块直接输出 RGB565 // 16bit 像素，常用于 MCU / LCD RGB888 // 24bit 像素，数据量更大 JPEG // 有些摄像头模块内部自带 JPEG 压缩

注意：
摄像头采集到的是一帧一帧的图像。连续很多帧，才叫视频。

1 张图片 = 1 帧 30 张图片 / 秒 = 30fps 视频

2. 视频数据不压缩有多大？

假设摄像头是480×800，RGB565，30fps：

一帧大小 = 480 × 800 × 2 字节 = 768000 字节 ≈ 750 KB 30fps = 750 KB × 30 ≈ 22.5 MB/s ≈ 180 Mbps

这还只是RGB565。如果是 RGB888：

480 × 800 × 3 × 30 ≈ 34.5 MB/s ≈ 276 Mbps

所以如果你想把 RGB 图像实时传到遥控器、手机、上位机：

不压缩 RGB 视频：数据量非常大 压缩后视频：数据量会小很多

比如压成 MJPEG、H.264、H.265 之后，可能从几百 Mbps 降到几 Mbps，甚至更低。

3. 什么时候可以不压缩视频？

可以不压缩的情况：

摄像头 → MCU/SoC → 本地 LCD 显示

例如：

Camera RGB/YUV → ESP32-P4 / STM32 / Linux板 → LCD屏幕

这种场景数据不走无线网络，只在板子内部走并口、MIPI、DMA、PSRAM、显存，就可以不压缩。

但是如果是：

Camera → Wi-Fi → 遥控器/手机/电脑

那通常就要压缩。

4. 图片数据必须压缩吗？

单张图片也不一定必须压缩。

比如 480×800 RGB565：

一张图片 ≈ 750 KB

如果你只是偶尔拍一张，通过 Wi-Fi 发出去，可以不压缩，但是比较慢。

如果压缩成 JPEG，可能变成：

50 KB ~ 200 KB

这就小很多。

所以：

5. 音频数据必须压缩吗？

音频数据比图像小很多，所以很多嵌入式场景可以不压缩。

比如语音识别常用：

16kHz 采样率 16bit 单声道

数据量是：

16000 × 16bit × 1 = 256 kbps = 32 KB/s

这个数据量对 Wi-Fi 来说很小。

如果是高质量音频：

48kHz 16bit 双声道

数据量是：

48000 × 16bit × 2 = 1.536 Mbps = 192 KB/s

也不算特别大。

所以音频一般分情况：

6. 视频、图片、音频对比

7. 嵌入式项目里怎么选？

如果你做的是“小车/平衡车图传”

比如：

摄像头 → 主控 → Wi-Fi → 遥控器

建议：

低难度方案：MJPEG 效果更好方案：H.264 高级低延迟方案：H.264 + RTP/RTSP/WebRTC

如果你只是“拍照上传”

建议：

JPEG

如果你做“在线语音识别”

建议：

PCM 16kHz / 16bit / 单声道

因为很多语音识别服务本来就喜欢 PCM 原始音频。

如果你做“语音对讲”

建议：

Opus

Opus 对语音延迟和码率控制比较好。

8. 很关键的一点：压缩也要算力

压缩不是白送的。

不压缩： 优点：简单，延迟低 缺点：带宽大，存储大 压缩： 优点：数据小，适合传输/存储 缺点：占 CPU/硬件编码器，增加延迟，代码复杂

所以 MCU 项目里要看芯片有没有硬件编码能力。

比如：

普通 ESP32 / ESP32-S3： 不适合做高分辨率实时 H.264 编码 ESP32-P4： 图像能力更强，但是否能做你需要的编码，要看外设和 SDK 支持 RV1103 / RV1106 / RK3568： 更适合做摄像头视频采集、ISP、H.264/H.265 编码、AI视觉

结论

你可以这样记：

图片：可以不压缩，但上传/存储建议 JPEG 视频：实时传输基本必须压缩 音频：数据量小，语音识别可以直接 PCM，不一定压缩

对于你的图像采集传输项目，更现实的方案是：

摄像头采集 YUV/RGB ↓ 本地显示可以不压缩 ↓ 远程传输要压缩成 MJPEG / H.264 ↓ 通过 Wi-Fi / UDP / RTP / RTSP / WebRTC 发出去

音频识别则可以：

I2S 麦克风 / Codec ↓ PCM 16kHz 16bit 单声道 ↓ WebSocket / HTTP / UDP / TCP 上传到云端识别

视频压缩的必要性远远大于音频压缩。

对，无线传输前压缩，接收端通常还要解压/解码，否则接收端拿到的只是“压缩码流”，不能直接当 RGB 图像、PCM 音频来用。

更准确地说：

压缩 / 编码 → 无线传输 → 解压 / 解码 Encode → Transmit → Decode

1. 视频图像的典型流程

比如摄像头采集到 RGB/YUV 数据：

摄像头 ↓ RGB565 / RGB888 / YUV422 原始图像 ↓ JPEG / MJPEG / H.264 压缩编码 ↓ Wi-Fi / 4G / 以太网 / 图传 ↓ 接收端收到压缩数据 ↓ JPEG / H.264 解码 ↓ RGB / YUV ↓ LCD 显示 / APP显示 / 算法处理

也就是：

发送端：原始图像 → 压缩数据 接收端：压缩数据 → 原始图像

2. 举个具体例子：MJPEG 图传

假设你的小车摄像头每秒采集 30 张图。

发送端：

Camera 输出 YUV/RGB ↓ 每一帧压缩成 JPEG ↓ 通过 Wi-Fi 发出去

接收端：

收到一张 JPEG ↓ JPEG 解码 ↓ 变成 RGB565 / RGB888 ↓ 显示到 LCD 或手机屏幕

MJPEG 本质上就是：

JPEG图片 + JPEG图片 + JPEG图片 + JPEG图片 ...

所以接收端要一帧一帧解 JPEG。

3. 举个具体例子：H.264 视频

H.264 更像真正的视频压缩。

发送端：

Camera YUV ↓ H.264 编码器 ↓ H.264 码流 ↓ 网络发送

接收端：

收到 H.264 码流 ↓ H.264 解码器 ↓ YUV/RGB 图像 ↓ 显示

H.264 压缩率比 MJPEG 高很多，但是解码复杂度也更高。

4. 音频也是一样

比如麦克风采集到 PCM 原始音频：

I2S 麦克风 / Codec ↓ PCM 16kHz 16bit 单声道

如果你用 Opus 压缩：

发送端：

PCM 原始音频 ↓ Opus 编码 ↓ 无线传输

接收端：

收到 Opus 数据 ↓ Opus 解码 ↓ PCM 音频 ↓ 播放 / 语音识别 / 保存

但是如果你本来就直接传 PCM，那接收端就不需要解压，只需要按 PCM 格式播放或处理。

5. 什么时候不需要解压？

有几种情况可以不解压：

场景 1：只是保存文件

比如接收端收到 JPEG 图片后只是保存：

收到 JPEG → 存到 SD 卡

这种不用解压。

如果收到 H.264 视频流只是保存成文件：

收到 H.264 → 存成 .h264 / .mp4

也可以不立即解码。

场景 2：继续转发

比如：

摄像头设备 → 遥控器 → 手机

遥控器只是中转，不显示画面，那遥控器可以不解码，直接转发压缩码流。

场景 3：云端 API 支持压缩格式

比如某些语音识别服务支持 Opus、AAC、MP3，那你上传压缩音频后，云端自己解码，你的设备就不需要解码。

6. 如果要显示，就一定要解码

LCD 屏幕不能直接显示 JPEG/H.264。

LCD 最终需要的是像素数据，例如：

RGB565 RGB888 ARGB8888 YUV转RGB后的数据

所以：

JPEG/H.264/PNG/WebP 这些压缩格式 不能直接刷到 LCD 必须先解码成像素点

例如：

JPEG 文件 ↓ JPEG 解码 ↓ RGB565 ↓ SPI / RGB / MIPI / DMA ↓ LCD 显示

7. 压缩和解压谁更耗性能？

通常：

编码压缩 > 解码解压

也就是说，压缩端压力一般更大。

特别是 H.264/H.265：

H.264编码：很吃算力，最好有硬件编码器 H.264解码：也吃算力，但很多芯片/手机/电脑都有硬件解码

所以做图传时，发送端芯片很关键。

例如：

8. 你可以这样理解

压缩就像把一大箱衣服抽真空：

原始图像/音频 = 一大箱衣服 压缩编码 = 抽真空 无线传输 = 搬运 解码解压 = 打开真空袋 显示/播放 = 正常使用衣服

如果你只是运输和保存，可以不打开。
如果你要看、听、播放、分析，一般就要打开，也就是解码。

结论

你的理解是对的：

无线传输前压缩，收到后通常要解压/解码。

但要分用途：

要显示图像/播放声音/算法处理 → 必须解码 只是保存文件 → 可以不解码 只是中转转发 → 可以不解码 云端能识别压缩格式 → 设备端可以不解码

对于你这种“小车/平衡车图像传输到遥控器”的场景，典型流程是：

车端摄像头采集 ↓ 车端压缩成 MJPEG 或 H.264 ↓ Wi-Fi 发送 ↓ 遥控器接收 ↓ 遥控器解码 ↓ 遥控器屏幕显示

图片需要压缩，本质原因是：原始图片其实就是一大堆像素点，数据量很大。

比如一张480×800的图片：

分辨率 = 480 × 800 = 384000 个像素点

如果是RGB565：

每个像素 2 字节 图片大小 = 480 × 800 × 2 = 768000 字节 ≈ 750 KB

如果是RGB888：

每个像素 3 字节 图片大小 = 480 × 800 × 3 = 1152000 字节 ≈ 1.1 MB

这还只是一张图。如果你要无线传输、存储、上传，就会很占带宽和存储空间。

1. 为什么图片要压缩？

原因一：减少传输时间

比如你用 Wi-Fi、串口、蓝牙、4G 传图片。

一张原始 RGB565 图片大约：

480×800 RGB565 ≈ 750 KB

压缩成 JPEG 后可能只有：

50 KB ~ 200 KB

也就是说，数据量可能减少到原来的：

1/5、1/10，甚至更小

原来要传 750 KB，现在只传 100 KB，速度当然快很多。

原因二：减少存储空间

比如你存到 Flash、SD 卡、文件系统里。

如果不压缩：

1000 张 480×800 RGB565 图片 ≈ 750 MB

如果压缩成 JPEG，每张 100 KB：

1000 张 ≈ 100 MB

差距很大。

原因三：方便网络传输

网络上传输的不是“图片概念”，而是一堆字节。

原始图片：

RGB565 RGB565 RGB565 RGB565 ...

数据很大。

压缩图片：

JPEG 文件数据

数据小，适合通过：

TCP UDP HTTP MQTT WebSocket RTSP

这些协议传输。

原因四：很多应用本来就需要 JPEG/PNG 格式

比如手机、电脑、网页、服务器常用：

.jpg .png .webp

如果你直接传 RGB565，接收端还得知道：

宽度是多少？ 高度是多少？ 每个像素几个字节？ RGB565 是大端还是小端？ 一行有没有对齐填充？

而 JPEG、PNG 是标准图片格式，接收端更容易处理。

2. 图片不压缩可以吗？

可以。

比如下面这种场景就可以不压缩：

摄像头采集 RGB565 ↓ MCU / SoC ↓ DMA 直接刷 LCD

这种是本地显示，不经过无线传输，也不长期存储，直接把像素刷到屏幕上。

例如：

Camera → RGB565 → LCD

这种情况下，压缩反而麻烦，因为 LCD 不能直接显示 JPEG，你压缩完还得解码回来。

所以记住：

本地显示：可以不压缩 无线传输：建议压缩 存储图片：建议压缩 上传服务器：建议压缩

3. 图片压缩流程是什么样的？

以最常见的JPEG 压缩为例。

原始流程大概是：

摄像头采集 ↓ 得到 RGB / YUV 原始图像 ↓ 颜色空间转换 ↓ 图像分块 ↓ DCT 变换 ↓ 量化 ↓ 熵编码 ↓ 生成 JPEG 文件

看起来复杂，我给你按嵌入式角度拆开讲。

4. JPEG 压缩详细流程

第一步：摄像头输出原始图像

摄像头可能输出：

RGB565 RGB888 YUV422 YUV420 RAW Bayer

例如 RGB565：

像素1 像素2 像素3 像素4 ...

每个像素都是真实颜色数据。

第二步：RGB 转成 YCbCr

JPEG 一般不是直接压 RGB，而是转成：

Y = 亮度 Cb = 蓝色色度 Cr = 红色色度

也就是：

RGB → YCbCr

为什么要这样？

因为人眼对亮度变化敏感，对颜色细节没那么敏感。

也就是说，人眼更容易看出：

亮不亮 清不清楚 边缘锐不锐

但对颜色的小细节不太敏感。

所以 JPEG 会利用这个特点压缩颜色信息。

第三步：色度降采样

常见有：

4:4:4 不降采样，质量高，数据大 4:2:2 水平方向颜色减半 4:2:0 水平和垂直方向颜色都减半，常见

比如 4 个像素本来都有自己的颜色信息：

Y1 Cb1 Cr1 Y2 Cb2 Cr2 Y3 Cb3 Cr3 Y4 Cb4 Cr4

压缩时可能变成：

Y1 Y2 Y3 Y4 都保留 Cb / Cr 减少一部分

亮度信息多保留，颜色信息少保留。

这就是 JPEG 能压缩的原因之一。

第四步：分成 8×8 小块

JPEG 会把图片切成很多个：

8×8 像素块

比如：

整张图片 ↓ 8×8 小块 ↓ 8×8 小块 ↓ 8×8 小块 ...

后面的压缩就是对每个 8×8 小块处理。

第五步：DCT 变换

DCT 叫做离散余弦变换。

你可以先不用纠结数学细节，它的作用是：

把像素数据 变成 低频信息 + 高频信息

低频信息大概代表：

整体颜色 整体亮度 大面积平滑变化

高频信息大概代表：

细小纹理 边缘 噪声 很细的颜色变化

人眼对高频细节没那么敏感，所以 JPEG 后面会重点压缩这些高频信息。

第六步：量化

这是 JPEG 最关键、也是最容易损失画质的一步。

量化的意思是：

不重要的细节，直接减少精度，甚至丢掉

比如 DCT 后有一堆数：

120, 25, 8, 3, 1, 0, 0, 0

量化后可能变成：

12, 2, 1, 0, 0, 0, 0, 0

很多小细节被变成 0。

这一步之后，数据就非常容易压缩了。

JPEG 的“质量等级”主要就是控制量化强度：

质量高：丢得少，文件大 质量低：丢得多，文件小，但画质差

第七步：Zigzag 扫描

经过量化后，8×8 块里面很多高频数据变成 0。

JPEG 会按一种“之字形”顺序扫描：

从低频 → 高频

这样可以把很多 0 集中到后面，方便继续压缩。

第八步：RLE + Huffman 编码

这一步属于真正的“编码压缩”。

比如一串数据：

5, 0, 0, 0, 0, 0, 0, 0

可以表示成：

5 后面跟 7 个 0

这叫RLE 游程编码。

然后再用Huffman 编码，把常见的数据用短码表示，不常见的数据用长码表示。

最后生成：

JPEG 压缩数据

5. JPEG 总流程图

原始 RGB / YUV 图片 ↓ 颜色空间转换：RGB → YCbCr ↓ 色度降采样：4:2:2 / 4:2:0 ↓ 切成 8×8 小块 ↓ DCT 变换：空间像素 → 频率信息 ↓ 量化：丢掉不重要的高频细节 ↓ Zigzag 扫描 ↓ RLE 游程编码 ↓ Huffman 熵编码 ↓ JPEG 图片文件

6. 接收端解压缩流程

接收端刚好反过来：

JPEG 文件 ↓ Huffman 解码 ↓ RLE 解码 ↓ 反 Zigzag ↓ 反量化 ↓ IDCT 反变换 ↓ YCbCr 转 RGB ↓ 得到 RGB565 / RGB888 ↓ LCD 显示 / 图像处理

也就是：

压缩：RGB/YUV → JPEG 解压：JPEG → RGB/YUV

7. PNG 压缩和 JPEG 有啥区别？

JPEG 是有损压缩：

压缩后图片会丢一些细节 适合照片、摄像头图像

PNG 是无损压缩：

压缩后可以完全恢复原图 适合图标、UI、截图、文字图片

简单对比：

8. 嵌入式里图片压缩怎么做？

方案一：摄像头模块自己输出 JPEG

这是最省事的。

比如一些摄像头模组内部带 JPEG 编码器：

摄像头 ↓ 直接输出 JPEG 数据 ↓ MCU 只负责接收和发送

典型例子：

OV2640 可以直接输出 JPEG

这种对 MCU 压力小，非常适合 ESP32-CAM 这种方案。

方案二：主控芯片软件压缩 JPEG

流程：

摄像头输出 RGB/YUV ↓ MCU/SoC 内存保存一帧 ↓ CPU 软件 JPEG 编码 ↓ 发送 / 存储

缺点是：

占 CPU 占 RAM 速度慢 功耗高

普通 MCU 做高分辨率 JPEG 软件编码会比较吃力。

方案三：主控有硬件 JPEG 编码器

一些 SoC 有硬件 JPEG 编码模块：

Camera → DMA → JPEG Encoder → Memory → Wi-Fi/SD

这种效率高，适合实时图像传输。

9. 压缩图片和压缩视频区别

图片压缩，比如 JPEG：

每张图片单独压缩

视频压缩，比如 H.264：

不仅压缩一张图内部 还会压缩前后帧之间的重复内容

比如视频里背景不动，只有人动。

JPEG/MJPEG 会每一帧都完整压缩：

第1帧 JPEG 第2帧 JPEG 第3帧 JPEG

H.264 会利用前后帧关系：

第1帧：完整画面 第2帧：只记录变化部分 第3帧：只记录变化部分

所以：

JPEG/MJPEG：简单，延迟低，压缩率一般 H.264/H.265：复杂，压缩率高，适合视频

10. 对你的项目怎么选？

如果你是做：

摄像头 → 小车/平衡车 → 无线传输 → 遥控器显示

建议优先级是：

低难度方案

摄像头直接输出 JPEG ↓ Wi-Fi 发送 JPEG ↓ 遥控器接收 JPEG ↓ 解码显示

也就是 MJPEG 图传。

优点：

简单 容易调试 每帧都是独立图片 丢一帧不影响下一帧

缺点：

码率比 H.264 大 画质/带宽效率一般

更专业方案

摄像头输出 YUV ↓ H.264 硬件编码 ↓ Wi-Fi 发送 H.264 码流 ↓ 接收端 H.264 解码 ↓ 显示

优点：

带宽低 画质更好 适合实时视频

缺点：

编码复杂 需要硬件编码器 软件开发难度更高

结论

图片要压缩，是因为：

原始 RGB/YUV 图片太大 无线传输慢 存储占空间 网络带宽吃不消

图片压缩流程，拿 JPEG 来说就是：

RGB/YUV 原始图像 ↓ 颜色转换 ↓ 分块 ↓ DCT 变换 ↓ 量化丢掉不敏感细节 ↓ 熵编码 ↓ JPEG 文件

嵌入式里你可以这样记：

本地 LCD 显示：可以不压缩 拍照保存/上传：建议 JPEG 实时无线图传：MJPEG 或 H.264 普通 MCU：尽量用摄像头自带 JPEG Linux/视频 SoC：优先用 H.264/H.265

不能把 JPEG/MJPEG 压缩数据直接刷到普通 LCD 上显示。

普通 LCD 控制器最终要的是：

RGB565 RGB888 ARGB8888 YUV 转 RGB 后的数据

而 JPEG/MJPEG 是压缩后的码流，LCD 不认识。

1. JPEG 图片能不能直接显示？

要分“谁来显示”。

情况一：普通 MCU + 普通 LCD

比如：

ESP32 / STM32 / GD32 ↓ SPI LCD / RGB LCD / MIPI LCD

这种情况下，不能直接显示 JPEG。

因为你的 LCD 驱动通常是这种方式：

lcd_draw_bitmap(x1,y1,x2,y2,rgb565_buffer);

它要的是一块像素数据，例如：

0xF800 // 红色像素 RGB565 0x07E0 // 绿色像素 RGB565 0x001F // 蓝色像素 RGB565

但是 JPEG 文件里面不是像素点，而是压缩编码数据：

FF D8 FF E0 ... FF DA ... FF D9

LCD 控制器看不懂这个。

所以 JPEG 显示流程应该是：

JPEG 文件/数据 ↓ JPEG 解码器 ↓ RGB565 / RGB888 像素数据 ↓ LCD 显示

2. MJPEG 能不能直接显示？

MJPEG 也不能直接刷 LCD。

MJPEG 本质是：

JPEG 第1帧 JPEG 第2帧 JPEG 第3帧 JPEG 第4帧 ...

也就是很多张 JPEG 图片连续播放。

所以 MJPEG 显示流程是：

收到 MJPEG 数据流 ↓ 拆出一帧 JPEG ↓ JPEG 解码成 RGB565 / RGB888 ↓ 刷到 LCD ↓ 再拆下一帧 JPEG ↓ 再解码 ↓ 再显示

流程图：

MJPEG Stream ↓ 提取 JPEG Frame ↓ JPEG Decode ↓ RGB565 Framebuffer ↓ LCD Display

所以严格来说：

MJPEG 不能直接显示 MJPEG 要先拆帧，再 JPEG 解码，再显示

3. 为什么电脑/手机好像可以直接打开 JPEG？

因为电脑和手机的软件帮你解码了。

比如你双击一张.jpg图片：

JPEG 文件 ↓ Windows 图片查看器 / 浏览器 / 手机相册 ↓ 软件或硬件 JPEG 解码 ↓ 显卡/屏幕显示 RGB 像素

你感觉是“直接显示”，其实中间已经完成了解码。

4. 哪些设备可以“看起来直接显示 JPEG”？

有些高级显示模块、浏览器、播放器、手机 App 可以直接接收 JPEG/MJPEG。

但本质上是它们内部有解码器。

比如：

5. 结合你的 ESP32-S3 / RGB LCD 场景

你之前做的是：

ESP32-S3 ↓ ST7701S ↓ RGB565 / RGB 并口 LCD

这种屏幕不能直接显示 JPEG/MJPEG。

因为 ST7701S 这类 RGB 屏的输入本质是：

R[0:n] G[0:n] B[0:n] PCLK DE HSYNC VSYNC

它吃的是连续像素流，不吃 JPEG 文件。

所以你要显示 JPEG，应该是：

SD卡 / 网络 / 摄像头 获取 JPEG ↓ ESP32-S3 软件 JPEG 解码 ↓ 得到 RGB565 buffer ↓ esp_lcd_panel_draw_bitmap() ↓ ST7701S 显示

6. 如果是摄像头图传到遥控器

发送端：

摄像头 ↓ JPEG/MJPEG 编码 ↓ Wi-Fi 发送

接收端：

Wi-Fi 接收 ↓ 得到 JPEG/MJPEG 数据 ↓ JPEG 解码 ↓ RGB565 ↓ LCD 显示

也就是：

压缩是为了传输 解码是为了显示

7. JPEG 解码会占什么资源？

JPEG 解码需要：

CPU 算力 RAM 缓冲区 解码库 显示帧缓冲

对 MCU 来说，主要压力是：

分辨率越高，解码越慢 图片越大，RAM 越吃紧 帧率越高，CPU 压力越大

比如 480×800 JPEG：

解码后 RGB565 大小 = 480 × 800 × 2 ≈ 750 KB

如果你的设备没有足够 RAM，就不能一次性解完整帧，可以用分块解码/行解码：

JPEG ↓ 每次解码 8 行 / 16 行 / 一小块 ↓ 立刻刷到 LCD ↓ 继续解下一块

这样可以省内存。

8. 总结一句话

你可以这样记：

JPEG / MJPEG 是压缩格式，适合传输和存储； RGB565 / RGB888 是像素格式，适合 LCD 显示。

所以：

JPEG 图片不能直接刷普通 LCD MJPEG 视频也不能直接刷普通 LCD 必须先解码成 RGB565/RGB888/YUV，再显示

对于你的嵌入式项目，正确流程是：

JPEG/MJPEG 数据 ↓ JPEG 解码 ↓ RGB565 图像缓冲 ↓ LCD 显示