音视频图片压缩

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

核心判断标准只有一个：

采集数据量 ≤ 传输带宽 / 存储速度 / 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

这就小很多。

所以：

场景	是否建议压缩
拍一张图，存在本地 Flash/SD 卡	建议 JPEG
拍一张图，通过串口发	强烈建议压缩
拍一张图，通过 Wi-Fi 发	建议压缩
摄像头直接给 LCD 显示	可以不压缩
连续视频传输	基本需要压缩

---

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

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

比如语音识别常用：

16kHz 采样率
16bit
单声道

数据量是：

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

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

如果是高质量音频：

48kHz
16bit
双声道

数据量是：

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

也不算特别大。

所以音频一般分情况：

场景	建议格式
在线语音识别	PCM 16k/16bit/mono，通常不用压缩
对讲机/远程语音	Opus / AAC / PCM 都可以
音乐播放/传输	AAC / MP3 / Opus 更合适
蓝牙耳机音乐	SBC / AAC / LDAC / LC3 等编码
本地录音短时间保存	PCM/WAV 可以
长时间录音存储	建议压缩

---

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

类型	原始数据量	是否经常压缩	常见压缩格式
图片	中等	经常压缩	JPEG、PNG、WebP
视频	非常大	基本必须压缩	MJPEG、H.264、H.265
音频	较小	看场景	Opus、AAC、MP3、SBC、LC3
语音识别音频	很小	不一定	PCM / Opus

---

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解码：也吃算力，但很多芯片/手机/电脑都有硬件解码

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

例如：

芯片/平台	适合做什么
普通 MCU	低分辨率 JPEG / 原始小图
ESP32-S3	小分辨率 JPEG/MJPEG 勉强可以
ESP32-P4	图像采集和显示更强，但要看编码支持
RV1103/RV1106	更适合摄像头 + H.264/H.265 + AI
RK3568	Linux多媒体能力强，适合复杂应用
手机/电脑	解码能力很强

---

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、截图、文字图片

简单对比：

格式	是否有损	适合场景
JPEG	有损	摄像头照片、图传、自然图像
PNG	无损	图标、UI、截图、透明背景
BMP	不压缩	简单但文件大
WebP	可有损/无损	Web 图片
RAW/RGB	不压缩	本地显示、算法处理

---

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。

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

比如：

设备/软件	能否直接给 JPEG	本质
普通 SPI LCD	不能	只收 RGB 像素
普通 RGB LCD，例如 ST7701S	不能	只收 RGB 数据流
LVGL 普通 image 控件	默认不一定能	需要 JPEG decoder
浏览器 <img src="xxx.jpg">	可以	浏览器内部解码
手机 App 显示 JPEG	可以	App/系统内部解码
某些智能串口屏	可能可以	模块内部解码
Linux 显示系统	可以	系统/库/硬件解码

---

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 显示