企业官网建设流程全解析

我做过一个"上帝视角"相关的项目，起因非常简单：某个园区里装了二十多路监控，值班室墙上是四台显示器做九宫格轮播，出点小事要来回切换画面找好几个摄像头才能拼出完整经过。我心里一直有个疑问——为什么不能把所有这些画面合成一张图，让我像上帝一样俯视整个园区？

这个想法就是 gods-eye-view 的雏形：不是把视频流简单堆在一起，而是通过计算机视觉算法，把多路来源（固定摄像头、无人机）的画面在空间上对齐、融合，输出一张统一的、带地理参照的全局视图。看到任何位置，我一眼就能知道那是哪里、发生了什么。

我花了大概三周时间把这个系统跑通，中间踩了不少坑，也积累了大量实操经验。这篇文章我打算把完整思路、架构选型、核心算法、性能优化和部署中踩过的坑都摊开讲一遍。项目本身不算复杂，但涉及的环节很全——视频流接入、特征匹配、透视变换、实时编码、无人机推流、坐标映射——几乎每个环节都有值得展开的细节。如果你正在做视频监控、态势感知、园区可视化或者无人机航拍相关的东西，这篇文章应该能帮你省不少时间。

1. 项目根源：多路小窗为什么替代不了"上帝视角"

1.1 多路拼接和简单的多画面分割是两码事

在动手之前，我必须先说清楚一个容易混淆的概念。市面上的NVR录像机都有多画面分割功能，把16路画面缩略图铺在同一个屏幕上，那叫"多画面预览"。但它不是"上帝视角"——因为每一路画面仍然是独立的摄像机视图，它们之间没有空间关系，你看不出路A的路口和路B的停车场谁在谁的东南方、相距多远。

gods-eye-view 要解决的是"空间统一"的问题。它把多路视频画面当成同一个大场景在不同位置的局部采样，通过特征点匹配计算它们之间的几何变换关系，最终把每个画面"投影"到同一个俯视平面上。结果是一张连续的大图：路面是连续的、建筑是连续的，哪怕它们来自完全不同的摄像头。

我在项目里验证过一个很直观的场景：两个摄像头分别拍摄一条长路的东段和西段，中间有部分重叠区域。用传统多画面分割，你需要看两路画面再脑补"它们其实是同一条路"；而gods-eye-view 输出的一张大图上，这条路是连通的，有人从东段走到西段，我在同一张图里就能跟踪他的完整移动轨迹。

1.2 三个典型落地场景，决定了我为什么选这套技术栈

我梳理了最需要"上帝视角"的三个场景，它们对技术方案的要求各不相同：

• 园区/厂区安防监控：几十路固定摄像头覆盖公共区域，需要全局态势感知。核心诉求是低延迟、多路并发、720P以上的清晰度、以及长期稳定运行。这个场景拼的是"固定摄像头之间的空间关系"，只需要在部署时标定一次。
• 无人机航拍直播：单架无人机在天空飞行，地面站需要实时的全景图。核心诉求是单路高分辨率视频的低延迟推流、以及无人机位置信息和图像的叠加展示。这个场景不涉及多路拼接，但要让"上帝视角"真正动起来。
• 农业/水利巡查：无人机巡检大片农田或河道，需要把多段航拍影像离线拼接成完整作业区域的俯视图。核心诉求是高精度拼接、畸变矫正、以及处理大面积无重叠区域的影像组织。

我做项目的过程中，这三个场景分别对应了三种技术需求：多摄像头实时拼接、无人机RTMP推流接入、大影像离线拼接。实际开发时，我把基础框架搭成了一套统一管线，再针对场景做配置切换。

1.3 我最终选型的技术清单

这里列一下项目的核心技术栈，后面每一章还会展开讲为什么选它们：

整套东西跑在工业级Debian主机上，显卡用了一块NVIDIA T1000，后面会提到具体的性能数字。

2. 整体架构：视频流从接入到输出的完整链路

2.1 采集层设计，RTSP拉流与推流的取舍

摄像头接入是整个管线的最前端，也是最容易出幺蛾子的地方。大多数IPC默认支持RTSP协议，地址一般是rtsp://user:pass@ip:554/Streaming/Channels/101这种格式。我用FFmpeg做拉流，命令很简单但有个容易忽略的坑：RTSP的TCP和UDP模式。

ffmpeg -rtsp_transport tcp -i "rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101" -f rawvideo -pix_fmt bgr24 -s 1280x720 -an pipe:1

这个-rtsp_transport tcp很关键。UDP模式在弱网环境下丢包严重，画面会出现马赛克和花屏；TCP模式牺牲一点延迟换来稳定，在局域网内完全感知不到差别。我在园区实测过，几十路摄像头都走TCP，延迟也就增加了几十毫秒，可以忽略。

拉流这块要特别注意：不要每个摄像头单独启一个ffmpeg进程再拿去拼接，这样解码资源会被白白浪费。更好的做法是在一个进程里用FFmpeg的多线程解码，或者用GStreamer的多路uridecodebin。我第二版架构里是C++程序直接调用FFmpeg库接口，每路一个解码线程，数据通过队列交给拼接线程池。

2.2 处理层架构，拼接引擎是怎么组织的

拼接引擎的核心流程可以拆成五个阶段：读取帧 → 特征提取 → 特征匹配 → 计算单应性 → 投影融合。

这个流程在静态摄像头场景下有个重要的性质：摄像头装好之后不动，单应性矩阵基本是固定的。所以项目采用了两阶段策略——

• 初始化阶段：启动时对每路摄像头抓取一帧关键帧，做全量特征提取和匹配，寻找最优单应性矩阵并缓存。
• 运行阶段：直接复用缓存的变换参数，对每一帧做透视变换和融合。性能开销从"特征匹配+变换"降为"纯变换+融合"，实测帧率提升了一个数量级。

运行阶段还可以进一步优化：OpenCV的warpPerspective会为每一帧分配临时矩阵，如果图像大、帧率高，频繁malloc就是性能杀手。项目里我预分配了所有中间矩阵，实测分配次数从每分钟几十万次降为0，拼接帧率提升约30%。

2.3 展示层设计：大图如何输出给值班室和浏览器

拼接完成的大图，最初我直接cv::imshow在本地窗口里，但这只适合开发调试。真实部署时值班室看的是一台Web大屏，所以输出链路的最终形态是：拼接线程产出BGR帧 → 送入FFmpeg编码器（H.264）→ 封装成RTMP流 → 推送到本机SRS媒体服务器 → 浏览器通过WebSocket/HTTP-FLV播放。

这条链路加上RTSP拉流延迟、拼接延迟、编码延迟、SRS转发延迟、浏览器缓冲延迟，最终端到端延迟大约在500毫秒到1秒之间。对于安防监控场景完全可接受，但对于无人机这种需要"所见即所得"的场景还不够。我在无人机部分会讲怎么把延迟压到200毫秒以内。

3. 多路视频拼接的命门：特征匹配和对齐

3.1 特征点提取的选型，SIFT、ORB还是光流？

特征提取是拼接算法的第一步。OpenCV里最常用的有两个：SIFT（尺度不变特征变换）和ORB（定向快速旋转简报）。我在项目中做了实际对比测试：

纯数据上看，SIFT精度最高、鲁棒性最好，适合复杂场景；ORB速度极快，适合移动端或低算力设备。

我最终的策略是分场景：固定摄像头的初始化阶段用SIFT（反正只算一次，慢一点无妨），无人机动态拼接时用ORB（需要在每帧实时计算单应性）。但ORB在低纹理区域（大片草地、纯色墙面）经常匹配不到足够特征点，这是个老难题。后面第5章我会讲一个用GPS先验信息辅助匹配的方案，相当于给ORB一个"建议搜索区域"，成功率能提升一大截。

特征匹配之后要去除误匹配（野点），这一步必须用RANSAC（随机采样一致性算法）。OpenCV的findHomography内部就集成了RANSAC，核心参数是ransacReprojThreshold，默认是3像素。实际测试中，1080P画面建议设到5像素，太严格会损失正确匹配，太宽松会混入误匹配导致单应性矩阵漂移。

3.2 单应性矩阵与透视变换，把"各自视角"统一到"全局视角"

单应性矩阵是拼接算法的数学模型。它描述的是同一平面在两个不同视角下的投影变换关系，一个3×3的矩阵，可以通过至少4对匹配点求解。

假设某个点在摄像头A画面中的像素坐标是 (x1, y1)，在摄像头B画面中是 (x2, y2)，它们满足：

[x2] [h11 h12 h13] [x1] [y2] = [h21 h22 h23] [y1] [1 ] [h31 h32 h33] [1 ]

这个公式看起来简单，但有个重要的前提条件：所有匹配点对应的实际空间点必须近似共面。在园区监控场景，地面是最大的一个平面，绝大部分会用到俯视图映射；但你不可能让画面里的墙面、立杆、行人同时对齐得很好。所以做拼接时有几个实用原则：

1. 选择垂直于摄像头方向的主平面作为基准（一般是地面）；
2. 不同高度的物体（人、树、车顶）在拼接缝附近会出现"重影"或"错位"，这是正常的物理现象；
3. 安装摄像头时尽量让主视角朝向下方的地面区域，减少高层物体干扰。

我调试时有一个哲学家式顿悟：单应性矩阵求的不是立体空间的真实变换，而是平面投影的最优近似。理解了这一点，很多"为什么拼接边缘有错位"的问题都有了答案。

透视变换用OpenCV实现很简单：

import cv2 import numpy as np H, _ = cv2.findHomography(src_pts, dst_pts, cv2.RANSAC, 5.0) # 把摄像头A的画面变换到全局视角坐标系 warped = cv2.warpPerspective(frame_a, H, (global_width, global_height))

但warpPerspective只是单张画面的变换，真正的拼接还需要把A、B两路画面放到同一个全局画布上。做法是：以A为参考坐标系，计算B到A的单应性，然后把B变换后放到画布对应区域，重叠部分做融合。多路摄像头依次注册到全局坐标系，就得到了一张完整大图。

3.3 曝光补偿与接缝融合，让拼接边界"消失"

即使单应性矩阵算得很准，直接拼接的结果也多半惨不忍睹——两个摄像头白平衡设置不同、曝光参数不同、朝向相反导致的光照差异，会让拼接缝像一道刀疤一样横在画面上。这里有两个补救手段：

第一个是曝光补偿。OpenCV的stitching模块里用的是增益补偿（Gain Compensation）的思路：统计重叠区域的像素均值差异，对每路画面计算一个全局增益系数，让重叠区域的亮度尽量一致。单应性矩阵和增益系数都是离线标定阶段就能算好的，运行阶段只需要乘一个系数，几乎不占性能。

第二个是多频段融合（Multi-band Blending）。原理是把重叠区域分解成不同频率的图层，对高频细节（纹理）用渐入渐出的小半径加权，对低频亮度用小半径加权，从而在保留细节的同时平滑过渡。这个算法效果确实好，但计算量比较大，适合离线拼接；实时监控场景我推荐用更轻量的渐入渐出融合（alpha blending），在重叠区域做一个距离加权，宽度按30~50像素处理，视觉上基本无感。

这里务必强调一点：融合算法解决的是"看起来自然"的问题，而不是"几何对齐"的问题。如果单应性矩阵不准，融合只会让错位变得模糊，而不是消失。所以做融合优化之前，先确保几何对齐做得足够好，不要颠倒顺序。

4. 实时视频流拼接的性能优化，从卡顿到流畅的关键

4.1 性能瓶颈究竟在哪里

一个典型的任务：6路1080P@25fps的RTSP流拼接成一张3000×1500的大图，再编码推流。最初的朴素实现结果惨不忍睹——CPU占用拉满，拼接帧率只有8fps，延迟超过2秒。我用perf分析之后发现瓶颈分布很清晰：

性能优化从此开始了。核心思路是：能硬件做的不让CPU做，能少拷贝的绝不多拷贝，能并行的必须并行。

4.2 硬件解码：NVDEC带来的质变

第一板斧是把CPU软解换成NVIDIA硬件解码（NVDEC）。用FFmpeg的h264_cuvid或者新架构下的cudahwaccel，原始YUV帧直接留在显存里，后续处理全部用CUDA，避免GPU→CPU→GPU的数据拷贝。

以6路1080P为例，纯CPU软解大约占用4~6个完整核心；换NVDEC之后每路解码的CPU占用率几乎降到0，GPU专用解码引擎只用了不到30%。这一步对整个系统的性能提升是最巨大的，甚至比GPU拼接更明显。

使用命令行做验证很简单：

ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i rtsp://... -f null -

如果输出显示decoding: h264_cuvid，说明已经走了硬件解码。在C++工程里，我会推荐用FFmpeg的AV_HWDEVICE_TYPE_CUDA硬件设备上下文，代码稍微复杂一点，但性能收益非常直接。

4.3 多线程流水线与零拷贝路径

第二板斧是把整个管线从"串行处理"改成"多级流水线"。

传统做法是每帧依次走完"解码→变换→融合→编码"，一个摄像头卡一帧，整个系统就卡。流水线设计是：

[拉流解码线程×N] → [帧队列] → [拼接线程池×M] → [编码线程]

• 每路摄像头一个独立解码线程，产出帧放入环形缓冲队列；
• 拼接线程池从所有队列拿到同一时间片的帧，执行变换和融合；
• 编码线程把拼接结果送入H.264编码器。

这里有个时序同步问题：不同摄像头的网络延迟不同，A可能已经拿到第100帧，B才拿到第95帧。如果机械地等待所有路都到"同一帧号"再拼接，延迟会被最慢的通道拖死。我的解决方案是：用时间戳排序，设定一个最大等待窗口（比如80毫秒），到窗口就拼接当前最新的帧，不再等待落后者。这样每个摄像头画面落后量不会超过一帧，肉眼看不出不同步。

第三板斧是全程零拷贝：拉流解码后保持在显存中的CUDA帧，用OpenCV的UMat包裹；透视变换用CUDA版本的cv::cuda::warpPerspective；融合用自定义CUDA kernel；编码前再让FFmpeg直接读显存数据。保证每个环节之间都是指针传递，没有memcpy。实测这条路能把端到端延迟压进400毫秒以内。

4.4 最终实测数据

优化完成后的性能我做了精确测试。同样的6路1080P输入，在T1000 + Debian环境下的表现：

这个性能已经能够满足安防监控和大部分无人机场合的需求。顺便说一句，如果不在乎延迟，只是需要高帧率，更大的算力卡（如RTX 3060以上）可以轻松跑到6路1080P@60fps，拼接画面丝般顺滑。

5. 让"上帝视角"真正升空：无人机视频接入与动态拼接

5.1 无人机画面怎么进入系统

固定摄像头解决了"园区上帝视角"，但走出园区之后，最灵活的"上帝视角"载体就是无人机。我这边主要用大疆的机型做验证，接入方式有两种：

• 大疆司空/云平台方案：大疆机场或带屏遥控器可以直接推流到第三方RTMP服务器。司空平台的转发会经过云端，延迟通常在1到3秒，适合巡查后回看，不适合操控飞行。
• 自建RTMP链路：用大疆的直播功能把视频流直接推到自建的SRS/Nginx-RTMP服务器，地面站在局域网内转发，端到端延迟可以压到200毫秒左右。这是我项目里实际采用的模式。

大疆无人机推流地址格式一般是rtmp://<服务器IP>/live/dji，在DJI Pilot App中设置好之后，地面的FFmpeg进程直接拉这个地址，走正常的解码管线就行了。链路里有一个细节：路上一定要加Transcode（转码）环节，把无人机的4K高码率视频降为1080P/2Mbps，否则高码率流在局域网内虽然不卡，但经过Wi-Fi中继后容易丢包。

5.2 无人机位置与视频画面的空间映射

视频流接入只是第一步。真正的"上帝视角"要求画面能和空间位置对应起来——也就是你在全局图上看到无人机画面，同时知道它在哪个经纬度。

这部分我用了MAVLink协议获取无人机状态信息。MAVLink是无人机通信的标准协议，通过串口或UDP输出位置、姿态、速度等遥测数据。在飞控里开启HITL（硬件在环）模拟或直接接真实飞控，都能拿到经度、纬度、相对高度、航向角、云台俯仰角等字段。

拿到经纬度和姿态之后，要做一次坐标系转换：经纬度 → 局部平面坐标（UTM或高斯投影） → 叠加在地图画布上的像素坐标。这一步并不复杂，用GeographicLib或pyproj就能实现，但有个容易忽略的坑：无人机的GPS坐标是相机光心（或飞控中心）的坐标，不是画面中心的坐标。相机通常安装在无人机底部或云台上，和飞控中心之间隔着几十厘米到一米多，如果直接拿飞控坐标标注画面位置，在低空大比例尺场景下会明显偏出几十个像素。需要做一次相机外参平移校正。

5.3 无人机画面和固定画面对应关系：单次标定还是持续计算

我最初的想法是把无人机画面也参与固定摄像头画面的特征匹配，实现"无人机视角"与"固定摄像头视角"的无缝拼接融合。但做下来发现，这事远没有想象中简单，核心原因是：单应性矩阵的前提是相机固定或者目标和相机之间位置关系稳定。无人机一直在动，每时每刻和地面固定摄像头的相对位姿都在变化，单应性矩阵必须实时重估计。

重估计本身倒不难，难在"实时"两个字。ORB特征提取+匹配在消费级显卡上大约需要30~50毫秒，勉强能达到15fps，算力紧张。更麻烦的是，无人机在空中看到的地面视角和固定摄像头看到的倾斜视角差异很大，特征点重叠非常有限，经常匹配失败。

项目里我最终用了另一种更稳定的方案：不做无人机和固定摄像头的特征拼接，而是通过GPS做"画面锚定"。把无人机画面作为一个实时更新的图层，根据GPS坐标+高度+云台姿态把画面缩放、旋转后覆盖到全局图的对应位置，类似AR贴图。虽然画面上物体不完全贴合地面地图，但它的位置对应是准的，能一眼看出"无人机画面覆盖的是哪块区域"。这套方案鲁棒性远高于特征拼接，而且不需要大量算力，实测飞行场景下稳定运行。

如果你确实需要做"动态视频的像素级拼接"，我建议不要走通用的特征拼接路子，而是用视觉惯性里程计（VIO）或者GPS+姿态辅助的办法，先算出无人机相对地面的精确位姿，再投影到地面网格上，效果比特征匹配稳定得多。

6. 实测部署踩过的几个坑，每个都是真金白银换来的

6.1 网络抖动导致的画面撕裂

第二周测试时遇到一个诡异的问题：固定摄像头画面拼接后偶尔出现一道横向撕裂，像是画面被"扯"了一下。排查了半天，最后发现原因是RTSP流的网络抖动导致某一帧解码不完整，warpPerspective拿到了一帧残缺图，拼接到全局图上就变成撕裂。

这个问题的解决方案是：在解码线程和拼接线程之间加一个帧完整性校验。FFmpeg解码返回的帧带AVFrame.pkt_dts字段，我用来判断这一帧是不是完整帧。常规做法是解码器只有在拿到下一个关键帧时才会输出完整的可显示帧，如果发现输出帧不连续，就从关键帧开始重新同步。实际代码中，我在队列里做了时间戳乱序排序和丢帧策略：连续丢3帧以上就丢弃不完整的帧，避免坏帧进入拼接管线。

6.2 大分辨率拼接的内存爆炸问题

第一次尝试把6路1080P拼成4000×2000大图时，程序跑了十几分钟就OOM崩溃。排查后发现warpPerspective每帧会分配一块 4000×2000×3 的临时缓冲区，约24MB，加上每路画面各自的变换临时区、融合缓冲区、编码输入缓冲区，内存累加起来非常可观。

解决思路有三个方向，我都做了：

1. 零拷贝共享内存：用OpenCV的Mat显式管理缓冲池，所有中间帧从预分配池中取，用完放回，不再反复malloc/free。
2. 降低中间精度：浮点运算的中间结果用16位存，减少临时缓冲区体积。这块最终我放在CUDA kernel里做，效果最明显。
3. 分块拼接：4000×2000大图不一次性整块变换，而是拆成4块瓦片分别变换、再贴回大图。块与块之间留几像素重叠，避免边缘接缝。

最终内存从单帧峰值约300MB降到80MB，稳定运行几天不会涨。

6.3 光照骤变导致拼接失败

有个很有意思的实验现象：白天光照正常时，两路摄像头画面拼得完美；傍晚夕阳一照，地面阴影拉长、强逆光使得某些摄像头画面整体发白，特征匹配初始化偶尔会失败，运行阶段也会因为亮度变化过大导致增益补偿失效，拼接缝又出现了。

这部分没有银弹。我的实用经验是两条腿走路：

• 初始化阶段尽量挑选光照稳定的时段，比如上午10点到下午2点拍关键帧算单应性。这个时段的特征最丰富、阴影最短，单应性矩阵最可靠。
• 运行阶段用缓冲池叠加模式：如果某一帧特征匹配失败，用上一帧的单应性矩阵做变换（因为摄像头没动，矩阵理论上是不变的）；连续失败超过10秒再重新触发全量特征匹配初始化。实测这套策略在天气突变场景下也能保持画面连续。

6.4 无人机推流卡顿的根子在哪

无人机项目调试时最让人抓狂的问题是推流卡顿。飞控状态显示链路信号很好，但地面端画面就是每隔几秒卡一次。后来抓包分析发现，原因不在视频流，而在时间戳抖动。无人机端的编码器码率自适应算法在画面复杂时瞬间拉高码率，超过了Wi-Fi链路的有效带宽，导致帧缓冲堆积，播放端就表现为周期性卡顿。

解决方式很直接：在SRS服务器或FFmpeg转推环节设置码率硬上限，把视频码率限制在2Mbps以内，同时开启GOP（关键帧间隔）限制为2秒，这样播放端最多等待2秒就能恢复同步。实测无人机端到端延迟从之前的500~800ms降到200ms以内，稳定飞行半个多小时没有明显卡顿。

7. 从gods-eye-view到数字孪生：项目还能往哪些方向延伸

7.1 把GIS和地图引擎加进来

目前这套系统输出的是"以摄像头为参考系的全局大图"，没有真实地理坐标。但很多客户（尤其是园区管理、消防应急）需要的是"图上画一个框，能直接拿到经纬度范围"。

这个升级其实不难：只要你在地面选取3个以上已知经纬度的控制点，在全局大图上标记出它们对应的像素坐标，然后用一次仿射变换就能算出大图上任意像素点对应的经纬度。我实现了这个功能之后，值班员可以直接在Leaflet地图上叠加实时拼接画面，还能把摄像头位置、周界、消防通道等图层一起叠加，地图的基础能力立刻让gods-eye-view升级为可交互的态势底图。

这个方向顺利落地的话，系统就从"一张大图看全局"进化成"一张大图看全局+精确定位+指挥调度"，价值完全不一样。

7.2 智慧农业里的实际用法

农业方向的应用其实非常适合gods-eye-view技术。固定摄像头在作物生长季覆盖几百亩田地的关键点位，无人机定期飞一遍全田获取高清影像。把两者融合到同一张俯视图上，能非常直观地看出作物长势差异、灌溉不均区域、病虫害集中区域。

这套系统在农业上的特殊之处是离线拼接比在线拼接更重要。无人机飞一次全田会产生几百张影像，我用离线拼接管线把它们拼成一张完整的高精度正射影像，再叠加NDVI（归一化植被指数）计算图层，就能生成一份农田长势差异图。这个方向的性价比非常高，因为不需要实时性，精度优先，开发复杂度比实时监控低，商业价值却很直接。

7.3 和数字孪生结合的底图思路

最后一个让我很兴奋的方向是把gods-eye-view拼接生成的大图作为数字孪生场景的"活底图"。传统数字孪生项目用的是3D建模出的静态场景，做不到"实时反映真实世界"。如果用gods-eye-view输出的大图作为动态纹理层，叠加在3D模型上，再把相机画面实时融合进去，就是一个"活着的数字孪生"——模型不再是摆设，而是实时同步着真实世界状态的镜像。

这个方向我们已经在做一个石油化工园区的概念验证：园区的3D模型 + 实时拼接的视频大图 + 摄像头采集的仪表读数，全部叠加在同一场景中。老板看到"值班室屏幕上有一个活的园区"时，整个需求就完全变了，后面谈预算都容易得多。

我在做这套系统的过程中最大的体会是：gods-eye-view 的本质不是"拼图"这个动作，而是把多源、碎片化的视觉信息统一到同一个空间坐标系里，让人一眼看全局。技术细节很多，但每一步都围绕"空间统一"这一个核心目标。如果你也想做类似的事情，建议先从两个摄像头的实时拼接跑通，再逐步扩展到多路、无人机、GIS叠加，每加一层复杂度都会带来新的挑战和乐趣。

另外一个很实际的建议：动手之前先把整个系统的数据流图画一遍，确定好每一路视频从摄像头到最终显示屏之间经过哪些环节、每个环节的延迟预算和性能预算。我第一次就是没做这个预算，堆了6路摄像头后发现CPU爆了，不得不回头重写架构。架构先行，调试少走一半弯路。