前阵子做了个移动巡检项目，甲方不拉网线，要求把四路MIPI摄像头的画面通过WiFi无线链路传到几十米外的接收终端，还反复强调画面延迟要控制在100毫秒以内。第一次把RK3588多路摄像头采集和WiFi低延迟传输放在同一个系统里跑，踩的坑比预想多得多，最后方案也算完整落地了。这篇把整条链路拆开讲清楚，从硬件选型、MIPI CSI驱动适配、多路采集编码，到WiFi传输协议取舍、延迟实测和调优记录，适合正要上RK3588做多目相机的工程师，也适合纯粹想把无线图传延迟压下来的同学。

整条链路的核心其实一句话就能概括：采集端用RK3588的MIPI CSI接口接多路Sensor，通过硬件ISP和RGA做图像预处理，再用MPP硬编码成H.264/H.265，最后把编码后的视频流通过WiFi用UDP的方式扔出去。每一步都有成熟方案，难点在于把这些环节串起来，并且保证延迟、码率、稳定性三者平衡。

1. 项目需求拆解与硬件选型的几个关键决策

先别急着下单买板子，把需求拆清楚比什么都重要。这个项目表面上是“四路摄像头+无线路传”，实际约束条件很具体：移动平台供电有限、不能拖网线、需要在弱信号环境下稳定工作、延迟目标100ms以内，后期还要在板端跑目标检测算法。这些约束直接决定了后面的硬件选择。

1.1 为什么是RK3588，而不是Jetson或x86

RK3588能成为当前多路视觉项目的热门选择，核心不是算力有多强，而是接口资源和媒体处理链路太完整了。它提供了4路MIPI CSI（每路最高4-lane）、内置ISP、RGA、8K VPU硬件编解码器，还有6T算力NPU，整个“采集-预处理-编码-分析”链条在一颗SoC上就闭环了。相比之下，Jetson的MIPI CSI接口数量少，扩展多路摄像头往往要加昂贵的采集卡；x86平台则体积和功耗都不适合移动巡检场景。

用RK3588搭这套采集传输系统，板端不需要额外的FPGA或专用视频处理芯片。热词里有人提到“fpga实现mipi”，如果摄像头数量超过4路，比如要接8路甚至更多，FPGA做MIPI聚合确实是合理方向，但会引入额外的硬件成本和调试复杂度，对于本文讨论的4路以内场景完全没必要。选RK3588的意义就在于原生的多路CSI输入。

1.2 MIPI摄像头选型：分辨率、全局快门与驱动成熟度

摄像头选型大家最容易只看分辨率，我这次踩过之后总结了一套标准：传感器型号、接口lane数、驱动成熟度、是否支持外部触发，这四样比单纯看像素重要得多。

常用的MIPI Sensor可以分成几类：

这次项目用的是IMX415做广角巡检，另外一路用SC132GS做近景测距，一广一近搭配。如果做视觉SLAM或者多相机三维重建，强烈建议上全局快门Sensor，卷帘快门在车运动状态下拍出来画面是歪的，后期算法根本没法治。

MIPI接口的lane数直接决定最大数据吞吐。单路4-lane在RAW10格式下大概能跑1.2Gbps左右，跑1080p@30绰绰有余，跑4K@30也在范围内。RK3588的4路CSI可以分别接4个不同的Sensor，也可以把其中两路合并成8-lane接更高分辨率的Sensor，具体得看官方SDK的board配置模板，别自己拍脑袋。

1.3 WiFi模组的取舍：PCIe方案和USB方案的差距

WiFi这部分试过两种方案，一种是USB3.0接口的WiFi 6网卡，一种是PCIe接口的AX210系列模块。结论明确：对延迟敏感的多路视频传输场景，优先选PCIe接口模组，别用USB网卡凑合。

USB WiFi在正常信号下表现还行，但一旦信号变弱，USB总线调度会产生额外延迟抖动。实测中有一段需要穿一堵承重墙的路径，USB方案端到端延迟能明显高50到80ms，而PCIe方案大体保持稳定。背后的原因不神秘：USB是独占总线的轮询机制，WiFi网卡的中断和数据传输要排队；PCIe是点对点并发链路，数据通路短得多。

模块选型上我建议直接选支持802.11ac或802.11ax、工作在5GHz频段的模组，配合外置天线。5GHz能避开大量2.4GHz设备的干扰，而且可用信道带宽更大。项目中用的方案是把RK3588作为AP模式，接收终端连接这个热点；当然也可以让RK3588作为STA接入已有路由器，两种模式在后文会给出配置差异。

顺便说一句供电，这句话放在选型阶段是因为它影响一切：RK3588满载功耗本身就不低，四路Sensor加上WiFi发射瞬间峰值电流很大，电源至少选择12V/5A以上的稳压电源，否则多路摄像头同时启动时WiFi掉卡、Sensor花屏这类问题会接踵而来。

2. MIPI CSI驱动适配：设备树、DPHY与出图调试

说句实在话，多路MIPI采集最耗时、最折磨人的环节就是驱动适配。RK3588的CPU算力、编码性能都不会骗人，但Sensor不出图是真的能卡一周。这一章把我整理的适配流程和排查思路完整写出来。

2.1 先理解RK3588的CSI控制器链路

从硬件角度看，一条完整链路是：MIPI Sensor输出 -> D-PHY接收 -> CSI2 Host控制器 -> VICAP采集 -> DDR内存。RK3588内部有多个CSI2 Host和VICAP（Video Capture）单元，设备树里的任务就是把Sensor的output端点依次连到CSI2 Host的input端点，再连到VICAP。

不同内核版本的节点命名有差异，有的叫mipi2_csi2，有的叫rkcif_mipi2，还有的内核把VICAP统一叫rkcif。别照抄网上的老配置，按你用的SDK里现有模板改。打开板卡厂商提供的dts，先找到&mipi2_csi2这类节点，理解现有的端点连接方式，再照着新增Sensor。

我调试时用的双路IMX415设备树骨架大概这样（路径和命名以实际SDK为准）：

&i2c7 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&i2c7m2_xfer>; imx415_0: imx415@1a { compatible = "sony,imx415"; reg = <0x1a>; clocks = <&cru CLK_MIPICAM_OUT2>; clock-names = "xvclk"; pinctrl-names = "default"; pinctrl-0 = <&mipimux2_mclk>; reset-gpios = <&gpio1 RK_PB0 GPIO_ACTIVE_LOW>; pwdn-gpios = <&gpio1 RK_PB1 GPIO_ACTIVE_HIGH>; rockchip,camera-module-index = <2>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "default"; rockchip,camera-module-lens-name = "default"; port { imx415_0_out: endpoint { remote-endpoint = <&mipi2_csi2_input>; >i2cdetect -y 7

如果能看到0x1a（IMX415的I2C地址）出现，说明Sensor供电和I2C通路基本正常。接着用media-ctl查看整个media graph上的端点连接情况：

media-ctl -p

这条命令会把rkcif、csi2、mipi_dphy、sensor这些节点的连接关系全部打印出来。正常状态是sensor的endpoint连到csi2的input，csi2的output连到vicap。如果发现某个endpoint没有连接到对端，说明设备树里remote-endpoint名称写错了，回头去检查DTS。

链路确认无误后，用media-ctl给sensor subdev设置format：

media-ctl -d /dev/media0 -V '"imx415 7-001a":0[fmt:SRGGB10_1X10/3840x2160]' media-ctl -d /dev/media0 -V '"mipi2_csi2":0[fmt:SRGGB10_1X10/3840x2160]'

这里要记住，Sensor输出的是RAW格式（比如SRGGB10），不是RGB也不是YUV。RAW格式带不带你熟悉的颜色信息不重要，后面交给ISP处理。如果直接取流看到的是绿色或品红色马赛克，不要慌，那是sensor bit depth和VICAP格式没配对，重新设一下format即可。

2.4 花屏、偏色、延迟异常怎么定位

花屏和偏色这类问题，九成出在比特率/位数配置错误，或者FPC排线信号质量差。

• 整体偏绿或品红：RAW Bayer的行列顺序配置错，改一下sensor的bayer pattern顺序。
• 画面有横条纹：检查MIPI lane数据是否均衡，可能是某根DPHY差分线断了。用i2cdetect看不出来，只能通过dmesg里的CRC错误计数判断。
• 随机丢帧/画面闪烁：优先怀疑FPC排线过长或弯曲太厉害。MIPI D-PHY对信号完整性要求高，长度超过15cm或者折叠过度的排线都会让误码率飙升。我最后把60cm的延长线全换成了15cm短线。
• 延迟和帧率接口对不上：查看实际帧率用v4l2-ctl --get-fmt-video和v4l2-ctl --stream-mmap --stream-count=30，确认frame interval是30fps而不是掉到15fps。Sensor的输出帧率会让整个链路延迟线性增大，这一步确认越早越好。

多路采集时，可以同时打开多个/dev/video*设备节点。RK3588的VICAP通常对应多个video节点，每路MIPI CSI对应一个。这里有个容易混淆的点：/dev/video0不一定对应第一个CSI口，具体映射关系看v4l2-ctl --list-devices的输出，按名字找。

3. 多路并发采集与低延迟编码管线

采集链路通之后，下一关是把四路视频同时跑起来，并且用硬件编码器实时出H.264流。这部分是RK3588被讨论最多、也最容易做坏的地方。

3.1 从V4L2到DMA-BUF：避免每次拷贝的愚蠢方案

四路1080p@30的RAW流，每秒钟约248MB数据（3840x2160x10bit/8 * 4路 * 30）。如果从V4L2读出来做内存memcpy，CPU直接被打满。正确做法是从V4L2直接获得DMA-BUF fd，基于零拷贝把buffer传给后续RGA或MPP。

V4L2的MMAP模式本身不会拷贝，它通过mmap把驱动内核态的buffer映射到用户态，用户拿到的是物理内存的映射。更进一步，可以用VIDIOC_EXPBUF得到dmabuf fd，把它传给libdrm或者RK的媒体库。简单说：取流时尽量用V4L2_MEMORY_MMAP而不要用V4L2_MEMORY_USERPTR手动分配buffer，RK平台的媒体驱动对MMAP路径优化得最好。

取流的线程模型上，我给每路摄像头分配一个独立线程，每个线程不断循环：VIDIOC_DQBUF -> 处理帧 -> VIDIOC_QBUF。编码再单独用两个线程，一个负责把原始帧送给RGA做格式/尺寸转换，一个负责把NV12数据送入MPP编码器。这样设计的好处是，某一路采集偶尔抖动不会拖垮其他路的编码节奏。

3.2 RK3588媒体链路的正确分工

RK3588内部有几条专门处理图像的硬件模块，合理分工能让CPU占用率低到可以忽略：

• ISP（图像信号处理器）：负责RAW转RGB、去马赛克、降噪、自动白平衡、自动曝光。如果使用raw sensor，链路里必须要过ISP。
• RGA（Raster Graphic Acceleration）：负责格式转换、缩放、旋转、裁剪。编码前把RAW/YUV数据转成NV12就靠它。
• MPP（Media Process Platform）：负责H.264/H.265编码解码。把NV12帧编成视频流的就是它。

一个直觉的流程是：Sensor出RAW -> ISP得到NV12 -> RGA缩放到编码分辨率 -> MPP编码H.264。RK官方SDK里通常有基于librockchip_mpp的demo，我记得mpi_enc_multi_test这个例子就默认支持多路并发编码，能省不少事。但如果你自己用gstreamer，可以直接用v4l2src ! mpph264enc ! h264parse ! rtph264pay一类插件串。

3.3 低延迟编码参数：关闭B帧和固定码率

低延迟编码和高质量编码的参数取向完全相反。默认编码器为了画质和压缩率会开B帧、用较大的GOP、按场景动态调整码率，这些对网络传输和延迟都是灾难。B帧意味着解码端必须等后续帧到达才能回放，直接引入额外延迟；动态码率会让视频码流大小剧烈波动，无线网络一拥塞，延迟就失守。

MPP编码时，重点设置这几个参数：

• profile设为baseline（H.264）或等价的低延迟档，强制关闭B帧。
• GOP/IP间隔：我设为30，即1秒一个I帧。I帧越小延迟越低，但码率浪费严重，1秒足够兼顾。
• 码控模式用CBR（固定码率）：让每帧数据量尽量平滑，避免瞬时码率尖峰。
• 码率依分辨率设定：1080p@30设为4Mbps，720p@30设为2Mbps，这个码率下画质够用，WiFi也不会吃满。

下面给一个用gstreamer跑单路低延迟编码的示例，多路用不同v4l2src device循环加nvmixer或videoconvert组合：

gst-launch-1.0 \ v4l2src device=/dev/video0 ! video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! \ mpph264enc bitrate=4000000 max-bframes=0 header-mode=1 ! \ rtph264pay config-interval=1 pt=96 ! udpsink host=192.168.1.2 port=5000

这里max-bframes=0就是关B帧，config-interval=1让每个I帧都带SPS/PPS，接收端能快速起播。MPP编码器的API若自己调，参数名字对应关系也很直接。我自己更推荐直接基于MPP native C API，网络工程化时可控性更好；gstreamer适合快速验证。

3.4 解码端同步与NPU推理的共存问题

板端既要做视频编码传输，可能还要做NPU推理（热词里大量出现rk3588部署yolov8）。这里有个共享资源的问题：NPU和MPP编码器其实是两个独立硬件，可以并行，但如果每帧RAW数据都要既送编码器又送NPU，内存带宽会被大量消耗。我的做法是，编码用降采样后的NV12帧，推理则从同一帧里抽帧送RKNN，两路互不阻塞。用RKNN-Toolkit2把yolov8导出成rknn模型时，输入尺寸定640x640，NPU单次推理大概20ms，而编码一帧需要8ms，两者并行时整体帧率能稳在25fps以上。

4. WiFi低延迟传输：链路配置与协议取舍

传输这步是整个项目里最容易翻车的地方。很多人在采集编码做得很漂亮，结果止步在WiFi数据出不去或者延迟爆炸。问题往往不是硬件不行，而是协议和参数选择不对。

4.1 让RK3588作为AP热点

如果接收端是笔记本或专用终端，推荐让RK3588当AP，接收端去连它。这样WiFi链路完全可控，不受外部路由器策略影响，也方便在移动场景中快速展开。

RK3588跑的是Ubuntu或Armbian时，AP模式用hostapd配置。一个参考配置如下：

interface=wlan0 driver=nl80211 ssid=robot-link hw_mode=a channel=149 ieee80211n=1 ieee80211ac=1 wmm_enabled=1 auth_algs=1 wpa=2 wpa_passphrase=yourpassword

关键点：hw_mode=a表示5GHz频段，channel=149是5.8GHz的常用信道，避开雷达信道和拥挤的2.4GHz。wmm_enabled=1一定要开，WMM（Wi-Fi Multimedia）会为视频类业务提供优先级队列，对降低无线延迟抖动非常有帮助。如果模组支持802.11ax，把ieee80211ax=1一并开启。

启动后还需要给wlan0配置静态IP，并把DHCP服务起来：

ip addr add 192.168.1.1/24 dev wlan0 ip link set wlan0 up dnsmasq -i wlan0 --dhcp-range=192.168.1.10,192.168.1.100,255.255.255.0

4.2 为什么别用TCP，优先UDP和SRT

做视频传输时，大多数人第一反应是走RTSP over TCP。TCP确实可靠，但它的可靠是基于重传机制的，而视频是强实时、弱容错的数据。一帧视频数据丢了，TCP会等重传，重传期间后面的数据全堵在队列里，延迟直接飙到几百毫秒甚至几秒。显然不符合低延迟需求。

正确的打开方式是UDP。UDP不保证可靠，但延迟可控、开销极小。为了缓解丢包带来的画面花屏，可以加一层轻量FEC（前向纠错），发送端每N个数据包附加1-2个冗余包，接收端只要丢包率不是太高，就能在不解码延时的情况下恢复丢失的数据。SRT协议就是一个把UDP、FEC、加密、流模式包装得很好的开源方案，它在WiFi链路上比我预想中表现好，尤其适合跨网穿透场景。

如果自己实现私有传输，思路也不复杂：MPP编码出来的每一帧H.264数据按NAL Unit切片，每个切片打上序号和时间戳，直接用UDP sendto发出去。接收端按序号重组，丢包就丢包，错误遮掩由解码器处理。这样的私有协议架子简单，调试起来反而快。

4.3 码率与无线带宽的匹配计算

多路同时传输，先算一笔帐再定Bei特流参数。以四路720p@30为例，每路2Mbps，总码率8Mbps。在80MHz频宽、良好的WiFi 5信号下，实际TCP吞吐量可能到300Mbps左右，UDP更轻松。但WiFi是共享介质，天线距离、障碍物、干扰都会让有效吞吐量大幅下降。

我实测的经验是，传输总码率不要超过WiFi链路实际饱和吞吐量的30%。比如点对点测速能稳定到100Mbps，那四路视频总码率就控制在30Mbps以内。这样给链路留下足够的余量，即使信道出现瞬时干扰，也不会立刻把延迟击穿。多路码率分配上，优先保证关键路（比如检测目标的那一路）以固定码率传输，其余路可以动态降码率，这个策略对“看起来稳定”特别有效。

4.4 接收端的低延迟播放参数

接收端如果直接用ffplay打开UDP流，默认会有几百毫秒缓冲，这是为网络抖动准备的平滑措施，却和低延迟目标冲突。调低缓冲的ffplay命令：

ffplay -fflags nobuffer -probesize 32 -analyzeduration 0 -framedrop \ -f mpegts udp://:5000

nobuffer告诉ffplay尽可能不缓冲，probesize 32和analyzeduration 0让它不要花时间做深度解析，framedrop在解码跟不上的情况下丢帧而不是累积延迟。性能更强的接收端工具是FFmpeg自带的low latency过滤器，或者直接用VLC把network-caching调到50ms以内。实际接收端延迟能从默认的300到500ms降到30到50ms级别。

5. 全链路延迟测量与逐段优化记录

做完以上步骤，系统已经能跑了，但延迟到底多少，得用数据说话。这一步我靠着“先测量、再优化”的原则，把整个链路拖到了100ms以内。

5.1 测量方法：秒表法与打点法结合

测延迟最粗暴也最有效的方式是“秒表法”：在摄像头前放一个高刷新率的电子秒表（或者手机打开在线毫秒计时器），接收端屏幕同时显示摄像头拍到的画面和当前系统时间。用另一台手机连拍两三张，对比接收端画面里秒表读数和真实秒表读数，差值就是端到端延迟。这个方法不需要任何埋点，适合整链路验收。

要定位瓶颈在哪个环节，就得软件打点。在RK3588的编码线程里用clock_gettime(CLOCK_MONOTONIC)记录：DQBUF时间点、送入MPP编码的时间点、编码完成的时间点；接收端记录：UDP收包时间点、解码开始时间点、渲染完成的时间点。把两端的日志时间戳放在一起，就能算出各段耗时。注意两端系统时钟不同步，需要先做时间同步，或者在同一个局域网内用NTP做粗同步，误差在几毫秒内不影响分析。

5.2 延迟分布图和瓶颈定位

实测数据（单路1080p@30，编码4Mbps，WiFi 5GHz AP模式，接收端为x86笔记本）大概是这样的：

端到端约60-85ms。可见最大头在Sensor曝光和ISP，其次是接收端解码渲染。想要把总延迟压进50ms，靠优化网络已经不够，得从Camera端下手：缩短曝光时间、减少ISP内部buffer级数、或者用sensor的HDR模式（会额外引入多帧合成延迟，反而要慎用）。

四路同时传输时，总延迟会加上一定抖动，因为WiFi空中接口要轮流发送各路数据。实测四路720p@30时端到端在80-100ms之间，符合项目验收预期。真正拉开差距的是信号变弱的情况，这个问题我在下面的优化记录里讲。

5.3 一轮又一轮的优化记录

把整个项目期间改过的关键参数变化记录成一张表，比任何经验总结都直观：

其中“TCP换UDP”是最关键的一步。最初图省事直接RTSP over TCP，近距离测试一切正常，但把接收端拿到隔墙房间后，整个画面变成幻灯片，延迟达到几百毫秒。换成UDP后，即使丢包率接近2%，画面也只是偶尔几帧花屏，时间戳和播放节奏没有大崩坏。

5.4 实际环境中的WiFi干扰与弱信号表现

移动巡检的现场环境到处都是干扰源：蓝牙耳机、2.4GHz无线键鼠、其他AP。我们做了两组对比测试：一组是RK3588和接收端之间无遮挡，距离5米；一组隔一堵混凝土墙，距离10米。

无遮挡时，四路视频总码率8Mbps，端到端延迟约80ms，抖动±8ms。隔墙的情况下，丢包率上升到0.5%到1%，由于开了FEC冗余（每8个包补1个冗余包），视频画面基本不花，延迟上升约20ms。如果把FEC去掉，延迟倒是能更低，但画面会出现短促花屏，主观体验反而变差。所以FEC冗余比例是值得在项目初期就固化成常量的一个参数，我的默认值是10%到15%，丢包严重的环境再酌情往上加。

6. 容易被忽略的五个坑：电源、散热、平台版本与扩展方向

最后这部分完全来自项目收尾阶段痛苦叠加的教训，每一个坑都曾让我怀疑人生。写出来希望大家绕开。

6.1 电源噪声是WiFi不稳定的元凶

项目初期遇到一个诡异现象：RK3588只要一跑多路编码，WiFi就会周期性掉线，dmesg里全是iwlwifi的接口重置日志。一开始以为是驱动问题，查了三天，最后用示波器抓12V电源输入，发现峰值跌落接近2V，是电源适配器扛不住瞬时功耗。换了高功率稳压电源后，WiFi和摄像头再也没同时出过问题。

这个坑在开发板场景尤其坑人，因为开发板通常不是为恶劣电源环境设计的。如果你的系统出现“跑视频时网络特别不稳定”的问题，第一反应应该是测电源，而不是重刷驱动。

6.2 散热降频会给编码带来隐藏延迟

RK3588满载编码四路视频时，核心温度能迅速冲到85度以上。超过温控阈值后，CPU/GPU/VPU频率调度会触发降频，编码器的运行频率也会跟着受影响，帧率会出现周期性掉到24fps或更低，直观表现就是延迟逐渐拉长再突然恢复。

项目机箱里我加了一个PWM温控风扇，根据CPU温度调节转速。调风扇用的是普通PWM调速，在Ubuntu下通过/sys/class/hwmon里的pwm节点控制。风扇转速从30%到80%曲线测试下来，可以稳定把温度压在70度以内，延迟也就没了那种“过山车”式的波动。需要提醒的是，PWM风扇的电源一定独立，别和Sensor的电源共路，风扇电流变化会让MIPI信号波形抖动。

6.3 平台选择：先Linux后Android

热词里大量出现rk3588 android12、armbian刷机之类，这里给个顺序建议：项目原型阶段优先用官方Linux SDK或Armbian，别一上来就用Android。Android的Camera HAL是另一套OK锁、buffer、3A回调体系，虽然官方也提供了Camera2 API，但系统集成度和可调试性远不如Linux V4L2链路透明。Linux下出现问题，dmesg、media-ctl、各种ioctl一查到底；Android下出现问题，日志被层层包装，排查成本高得多。等Linux侧把Sensor选型、编码参数、WiFi传输都验证完毕，再根据产品形态决定是否移植Android。

6.4 多路采集的系统稳定性联调

多路MIPI采集有个隐藏的并发问题：当多个Sensor同时启动、同时开始流时，多个线程同时申请buffer和编码器资源，容易触发竞态。我在启动阶段给每路Sensor加了500ms的错峰启动延时，避免四路同时发起。运行阶段则要监控/proc/buddyinfo是否持续出现内存碎片，以及每个video节点的overrun计数。如果某一路出现连续丢帧，不要优化全局，先查那一路的FPC和Sensor供电，通常又是硬件引线问题。

6.5 这套方案的扩展方向

说两个我接下来准备继续折腾的方向。一是给系统加上目标检测，用RK3588的NPU跑yolov8模型，让板端提前过滤只有目标的帧才回传，能把可用带宽利用效率提升数倍。二是做视频录制和回传的双通道设计：一路低码率流做实时监控，一路本地录存高码率原始素材，等回到基站再批量同步，这样即使用户现场只看到流畅回传，后续分析还有高质量数据保底。

最后说点实在的，这套RK3588多路MIPI采集加WiFi低延迟传输方案，真正的门槛并不在某一颗芯片或者协议身上，而是“采集-编码-无线-解码”这几段必须作为整体一起调。任何一个环节沿用默认配置，最终延迟都可能直接翻倍。项目做完我最大的体会是：先把瓶颈算清楚，再决定动哪一段。如果你正准备上类似方案，建议从一台接收机开始，先跑通一路视频并测量全链路延迟，再去铺开多路并行——这样每一步都有对照，出了偏差也容易定位。