📺 B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/
📘 《Yocto项目实战教程》京东购买链接：Yocto项目实战教程
Jetson 视频流基础全解析：从摄像头到屏幕的完整链路（V4L2 + GStreamer 实战）
本文以 NVIDIA Jetson 平台 为实例，围绕 USB 摄像头的 YUYV（RAW） 与 MJPEG（压缩） 两种典型视频流，系统讲解 Linux 下视频流的完整链路与核心原理。文章目标并非让读者成为 GStreamer 专家，而是 建立正确、工程化的视频流认知：数据从哪里来、长什么样、如何被处理、为什么会有性能差异，以及在实际项目中如何做出合理选择。
1. 什么是“视频流”？
在嵌入式 Linux / Jetson 系统中，视频流并不是抽象概念，而是一种持续输出的结构化数据流：
-
由 一帧一帧图像数据（Frame） 组成
-
每一帧都具有明确的：
- 像素格式（Pixel Format / FourCC）
- 分辨率（Width × Height）
- 帧率（FPS）
在系统层面，视频流通常遵循如下路径：
摄像头硬件 → 内核驱动（V4L2） → 用户态管线（GStreamer） → 显示 / 编码 / 推流 / AI
是否能够“稳定显示”“跑到高分辨率”“不掉帧”，本质上都由这三个核心参数共同决定。
2. V4L2：视频流的入口
2.1 /dev/video0 是什么？
在 Linux 中，大多数 USB 摄像头都会被注册为 V4L2 Video Capture 设备节点，通常表现为：
/dev/video0
需要特别理解的一点是：
/dev/video0 并不代表某一种固定的视频格式，而是一个“能力集合”。
一个 V4L2 设备节点，往往同时支持多种输出格式、分辨率和帧率组合。
2.2 使用 v4l2-ctl 查看摄像头真实能力
在实际工程中，第一步永远不是写 GStreamer pipeline，而是确认 摄像头到底支持什么：
v4l2-ctl -d /dev/video0 --list-formats-ext
典型输出（示例）：
-
MJPEG（Motion-JPEG, compressed）
- 2560×1440 @30fps
- 1920×1080 @30fps
- 1280×720 @30fps
-
YUYV（YUV 4:2:2, RAW）
- 640×480 @30fps
- 更高分辨率下 FPS 明显下降
这一步直接揭示了一个非常重要的事实：
同一颗摄像头，在不同像素格式下，能支持的分辨率和 FPS 是完全不同的。
3. YUYV 与 MJPEG：两种完全不同的视频流
3.1 YUYV 是什么？
YUYV（也称 YUY2）是一种未压缩的 RAW 视频格式，属于 YUV 4:2:2 采样。
特性总结：
- 每一帧直接包含像素值
- 不需要解码步骤
- 数据量大
- 链路简单、延迟低
在工程中，可以记住一句话：
YUYV = 原始像素 = 数据量大 = 分辨率受限
3.2 MJPEG 是什么？
MJPEG（Motion JPEG）是一种帧内压缩视频格式，可以理解为：
“每一帧都是一张 JPEG 图片，按时间顺序连续输出。”
特性总结：
- 摄像头内部先进行 JPEG 压缩
- 传输的数据量显著减小
- 用户态需要进行 JPEG 解码
- 更容易支持高分辨率
记忆要点：
MJPEG = 摄像头先压缩 = 数据小 = 更容易上 2K/4K
4. 为什么 RAW（YUYV）支持的分辨率反而更低？
这是初学者最容易产生疑惑的地方，但原因非常简单：
4.1 数据量决定一切
以 YUYV（4:2:2）为例，通常可以粗略按 2 bytes / pixel 估算：
-
640×480 @30fps
- 单帧 ≈ 640×480×2 ≈ 0.6 MB
- 每秒 ≈ 18 MB/s
-
2560×1440 @30fps
- 单帧 ≈ 7 MB
- 每秒 ≈ 210 MB/s
这还不包括：
- USB 传输协议开销
- 内核缓冲
- 内存拷贝
- 用户态处理
结果就是：
在 RAW 模式下，摄像头/USB/驱动往往无法承受高分辨率 + 高 FPS，只能主动降低分辨率。
而 MJPEG 在摄像头端完成压缩后，传输的数据量大幅下降，因此可以支持更高分辨率。
5. GStreamer：把视频流“接起来”
在确认摄像头能力之后，GStreamer 的角色非常清晰：
把 V4L2 输出的视频流，按指定格式接入、处理，并送到目标模块。
下面通过两条最典型的 gst-launch 实战命令，讲清楚完整链路。
6. 实战一：YUYV（RAW）视频流显示
gst-launch-1.0 v4l2src device=/dev/video0 ! \
"video/x-raw,format=YUY2,width=640,height=480,framerate=30/1" ! \
nvvidconv ! nveglglessink
6.1 Pipeline 结构解析
v4l2src → RAW(YUYV) → nvvidconv → GPU/EGL 显示
各组件职责：
- v4l2src：从 /dev/video0 拉取视频帧
- video/x-raw,format=YUY2：强制指定摄像头输出 RAW YUYV
- nvvidconv：Jetson 平台的硬件图像转换模块（常走 VIC）
- nveglglessink：基于 EGL/GLES 的硬件显示输出
6.2 工程意义
-
无解码步骤，链路最短
-
延迟低、稳定
-
非常适合：
- 摄像头驱动验证
- Pipeline 调试
- 画面是否正常的快速确认
缺点也非常明确：
受限于 RAW 数据量，分辨率无法做高。
7. 实战二：MJPEG（压缩）视频流显示
gst-launch-1.0 v4l2src device=/dev/video0 ! \
"image/jpeg,width=2560,height=1440,framerate=30/1" ! \
jpegdec ! nvvidconv ! nveglglessink
7.1 Pipeline 结构解析
v4l2src → MJPEG 压缩帧 → jpegdec → RAW → nvvidconv → GPU/EGL 显示
各组件职责：
- image/jpeg：告诉管线这是 JPEG 压缩视频流
- jpegdec：JPEG 解码（Jetson 上可使用硬件 NVJPG）
- nvvidconv：格式/颜色空间/内存转换
- nveglglessink：显示输出
7.2 工程意义
- 支持更高分辨率（如 2K@30fps）
- 更符合实际产品展示需求
- 解码步骤不可避免，但 Jetson 可利用硬件加速
8. Jetson 平台的关键特性：硬件引擎分工
Jetson 并不是“所有视频处理都跑在 GPU 上”，而是采用 多硬件引擎协作架构：
- NVJPG：JPEG 编解码引擎（MJPEG 常用）
- VIC：颜色空间转换、缩放、合成
- NVDEC / NVENC：H.264/H.265 解码与编码
- GPU（GR3D）：渲染、计算
这也是为什么在很多 MJPEG 场景下：
分辨率更高，但 GPU 使用率反而不高。
因为工作被分配到了更合适的专用硬件模块。
9. 如何验证硬件引擎是否在工作？
9.1 使用 tegrastats
sudo tegrastats
关键观察项包括：
GR3D_FREQ：GPUNVJPG：JPEG 引擎VIC：图像转换引擎NVDEC / NVENC
在运行不同 pipeline 时，对比这些字段是否从 off / 0 变为活跃，是理解 Jetson 视频架构的关键一步。
10. 初学者如何在 YUYV 与 MJPEG 之间做选择？
10.1 选择原则
- 调试 / 验证 / 低延迟：优先 YUYV（低分辨率）
- 产品显示 / 录制 / 推流：优先 MJPEG（高分辨率）
- AI / 深度学习：根据后端需求（NV12/RGB），设计最短转换路径
10.2 工程思维
- 先用
v4l2-ctl看清摄像头能力 - 再用 GStreamer 选择最合适的数据形态
- 尽量减少不必要的格式转换和内存拷贝
- 用
tegrastats验证是否真正利用了 Jetson 硬件特性
11. 总结
-
视频流 = 分辨率 × FPS × 格式
-
RAW（YUYV）：简单、低延迟、但数据量巨大
-
MJPEG：压缩后传输轻、支持高分辨率，但需要解码
-
Jetson 的优势：大量视频处理可由专用硬件引擎完成
-
正确学习路径：
- 用 V4L2 看能力
- 用 GStreamer 搭最短 Pipeline
- 用 tegrastats 理解硬件分工
掌握这些基础后，无论是显示、编码、推流还是 AI 处理，视频流都不再是“黑盒”，而是一个可分析、可优化、可控的工程系统。
📺 B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/
📘 《Yocto项目实战教程》京东购买链接：Yocto项目实战教程
扫一扫
1969
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
