Jetson 视频流基础全解析：从摄像头到屏幕的完整链路（V4L2 + GStreamer 实战）

📺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 v4l2srcdevice=/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 v4l2srcdevice=/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

sudotegrastats

关键观察项包括：

• GR3D_FREQ：GPU
• NVJPG：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 的优势：大量视频处理可由专用硬件引擎完成

• 正确学习路径：

  1. 用 V4L2 看能力
  2. 用 GStreamer 搭最短 Pipeline
  3. 用 tegrastats 理解硬件分工

掌握这些基础后，无论是显示、编码、推流还是 AI 处理，视频流都不再是“黑盒”，而是一个可分析、可优化、可控的工程系统。

📺B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/

📘《Yocto项目实战教程》京东购买链接：Yocto项目实战教程