课程导论与系统架构：实时数据流处理与多摄像头同步
各位同学，欢迎来到这门课。我是你们这趟技术旅程的向导。
先说说我为什么想做这门课。过去十年，我一直在跟嵌入式视觉系统打交道。从最早的单摄像头车牌识别，到后来给自动驾驶做环视拼接，再到工业质检线上同时处理 8 路 4K 相机——我踩过的坑，说实话，比你们想象的多得多。
有一次在产线上，4 个摄像头采集同一块电路板的图像，结果因为触发信号没对齐，每帧差了 3 毫秒。3 毫秒听起来不多对吧？但在高速运动场景下，这直接导致焊点检测的误报率飙升到 30%。嗯，从那以后，我再也不敢轻视同步问题了。
这门课的第一章，我们先搭好地基。搞清楚什么是实时数据流，为什么多摄像头同步是个硬骨头，以及整个课程的知识脉络怎么走。
1.1 实时数据流处理：不只是“快”那么简单
实时数据流处理，说白了就是数据一边来，你一边处理，而且必须在规定时间内出结果。这个“规定时间”就是硬约束。
我见过很多刚入行的工程师，以为只要 CPU 跑得快就算实时。其实不然。实时性是一个系统级的属性，它取决于：
- 采集延迟：从传感器曝光到数据进入内存的时间
- 传输延迟：数据在总线或网络上的搬运时间
- 处理延迟：算法执行的时间
- 输出延迟：结果写回或显示的时间
这四个环节，任何一个掉链子，整个系统就“非实时”了。
核心指标：端到端延迟
在视频处理场景下，通常要求端到端延迟控制在 33ms 以内（对应 30fps 的一帧周期）。如果超过这个值，画面就会产生“滞后感”，对于自动驾驶或远程手术这类应用，这是不可接受的。
我个人习惯把实时数据流系统分成三类，方便做架构选型：
| 类型 | 延迟要求 | 典型场景 | 我踩过的坑 |
|---|---|---|---|
| 硬实时 | < 1ms | 电机控制、激光雷达触发 | 曾经用 Linux 做硬实时，结果调度抖动直接导致丢帧 |
| 软实时 | 1ms - 100ms | 视频监控、工业视觉检测 | 偶尔丢一帧可以接受，但不能连续丢 |
| 准实时 | 100ms - 1s | 数据记录、离线分析 | 这种反而好做，用队列缓冲就行 |
1.2 多摄像头同步：为什么非做不可？
你想想看，如果两个摄像头拍同一个场景，一个比另一个慢了半帧，那它们的数据在时间轴上就是错位的。做拼接、做融合、做跟踪，结果全都会乱套。
多摄像头同步的必要性，我总结为三个层面：
- 空间一致性：多个视角的图像必须对应同一时刻，才能正确计算三维信息。比如双目视觉的视差图，时间不同步，深度就是错的。
- 时间一致性：在视频分析中，我们需要知道每个事件发生的精确时间。如果摄像头之间时间基准不统一，事件排序就会出错。
- 数据完整性：在记录或回放时，所有通道的数据必须按同一时间轴对齐，否则后期分析根本没法做。
我曾经犯过的错： 在做多路视频拼接时，用了软件时间戳来对齐。结果发现不同摄像头的时钟漂移不一样，跑了 10 分钟后，时间差已经累积到 200ms。画面拼接处出现了明显的“鬼影”。后来我改用硬件触发信号，才彻底解决这个问题。
同步的粒度也很关键。我一般按精度需求分几个等级：
- 帧级同步：误差在 1 帧以内（比如 33ms），适合监控场景
- 行级同步：误差在 1 行扫描时间以内（比如 30μs），适合工业检测
- 像素级同步：误差在 1 个像素时钟以内（比如 100ns），适合高速测量
选哪个等级，取决于你的应用。别一上来就追求像素级同步，成本和复杂度会翻好几倍。
1.3 课程整体架构：一张图看懂全局
这门课一共 30 章，我把它分成了四个模块。下面这张图可以帮你快速建立全局认知：
这张图是我花了不少心思设计的。你看，四个模块之间是有依赖关系的。我建议你按顺序学，尤其是前两个模块，它们是后面所有内容的基础。
我的学习建议： 每学完一个模块，停下来做个小的实践项目。比如学完基础篇，就试着用单摄像头搭一个实时采集管道，测量一下端到端延迟。这样到了同步篇，你才能真切感受到“不同步”带来的问题。
1.4 本章小结
这一章我们聊了三件事：
- 实时数据流处理的核心是“在规定时间内完成”，延迟是硬指标
- 多摄像头同步不是可选项，而是多视角系统的刚需
- 课程按“基础→同步→处理→实战”四个模块展开，环环相扣