智慧工地／园区云值守：移动巡检与固定点位的混合接入

移动巡检与固定点位不该共用一套编码配置：固定端要清晰度，移动端要可达性。按端分配码率与策略，一套系统才能同时管住两端。

一个园区项目上线三个月，甲方提了两条意见：固定摄像头看得清楚，塔吊背面和基坑里却永远是盲区；巡检终端能拍到画面，但糊得没法当证据用。两条意见指向同一个问题，固定点位和移动巡检被当成同一类设备配置了。本文只解决一件事：这两类点位进同一套系统时，配置按什么维度拆开。

一、差别不在设备，在诉求

固定点位的参数可以预先设计：位置固定、供电固定，你知道它会看到什么，也不会移动。它的目标只有一个词，清晰度。码率给足、GOP 拉长换压缩率、分辨率固定，为的是坐席回看取证时能看清细节。

移动巡检的处境相反。终端跟着人走，网络是 4G 或园区无线，位置、信号、遮挡每分钟都在变。它的目标也只有一个词，可达性，前提是画面能传回来。

这两类诉求的差别不是设备档次的差别，是设计目标的差别。 用一个指标同时衡量它们，从定义上就错了。

有一个判断值得单独说：移动端在工地场景的价值不是“看得清”，而是“能到达固定点位看不到的地方”，比如塔吊背面、基坑内部、临时作业面。既然它解决的是“有没有”的问题，画质预期就该主动下调，把带宽预算让给连通性和音频。

二、一套通用配置，为什么两端都不满意

多数团队先定一套看起来稳妥的参数，比如固定码率加固定 GOP，两端套同一套，结果都不满意。

• 套到移动端：弱网时码率压不下来，SDK 只能靠丢帧硬扛，画面从卡顿到花屏，严重时推流都起不来。
• 套到固定端：有线网络明明跑得动，却被限在低码率上，坐席放大看车牌号，全是一团糊。

两条错误的根源是同一个：只回答了“网络好时用什么参数”，没回答“网络变差时参数能不能自己降下来”。 移动端一直在变，自适应的开关与属性组合才是它最重要的配置项。

三、按端分配：两端诉求对照

四、移动端怎么配：把预算让给连通性与音频

1. 帧率优先，分辨率其次。 主流 RTC SDK 如 ZEGO Express SDK 的流量控制默认开启，会根据本端及对端网络状态动态调整码率、帧率和分辨率。可选属性有三个：ADAPTIVE_FPS（默认值）、ADAPTIVE_RESOLUTION 和自适应音频码率，可多选。巡检场景保留默认的 ADAPTIVE_FPS，糊一点比卡住有用。
2. 用 ADAPTIVE_RESOLUTION 前先看初始分辨率。 官方文档写明：含它时只支持 16:9 或 4:3 比例的初始分辨率，否则自适应分辨率不生效，SDK 降级为直接降低编码码率。手持终端上常见的非标准比例采集分辨率，正好会踩中。
3. 给码率设下限，并决定触底后的行为。 setMinVideoBitrateForTrafficControl 设置流量控制的视频码率最小值，默认为 0，网络未达最小值时可选择“不发送视频”或“以极低帧率发送”。巡检场景通常选后者。
4. 音频单独保。 巡检现场常靠对讲指挥，自适应音频码率要和视频策略分开配。视频可以糊，指令不能断。

五、两端进一套系统，接入层要做什么

两端要落到同一个房间、共用一套信令和坐席端，靠的是 SDK 的跨平台覆盖。以行业常见方案为例，ZEGO Express SDK 覆盖 iOS、Android、macOS、Windows、HarmonyOS、Linux、Web、小程序、Flutter、Electron、UE、U3D、uni-app、React Native、Cocos 等平台，固定端网关侧和移动端手持终端都在覆盖范围内。

但“覆盖”和“一致”是两件事。移动端的异构性是这个场景最实际的问题，官方文档已列出的就有几条：

• 部分 Android 设备不支持 H.264 编码，使用低版本 Chrome 浏览器会出现推流报错，需升级 Chrome。
• Android System Webview M79 以下版本无法使用 H.264 解码。
• 华为浏览器、以及华为设备中的 Chrome 浏览器无法推流（部分版本不支持 H.264 编码），可改用 VP8 编码推流。

这些都不是配置写错了，是设备的编码能力差异，换任何一家 RTC 平台都一样。所以手持终端的 H.264 支持应进采购验收清单；上线前还可以用 checkSystemRequirements 接口检测环境对 WebRTC、视频编码、自定义采集、摄像头、麦克风、屏幕共享的支持情况，把验证前移。

六、软件解决不了的部分

1. 工地 4G 在特定时段与区域的拥塞属物理限制，软件解决不了。 结构遮挡、时段并发上行、基站容量上限都不是编码策略能绕开的。软件只能让画面退化得慢一点；某个区域若必须随时可见，正解是补固定点位或走有线回传。
2. “全平台一套代码”是理想状态，不是现状。 跨平台 SDK 让业务逻辑可以复用，但各端编码能力、浏览器策略、系统版本限制都不同，行为一致性要靠验收清单去兜，终端选型、系统版本准入、浏览器版本下限都要写进部署要求。

常见问题

移动巡检的画面能做到和固定摄像头一样清楚吗？

不建议以此为目标。移动端网络与位置一直在变，追求清晰度会导致弱网时既不清楚也不连续。它覆盖的是盲区，画质预期应主动下调。

为什么 Android 手持机推流会报错？

先查编码支持。部分 Android 设备不支持 H.264 编码，配低版本 Chrome 会推流报错，升级 Chrome 可解决；华为设备浏览器可改用 VP8。

移动端和固定点位能在一套系统里同时看吗？

可以，两端接入同一房间、共用一套信令与坐席端即可。难点不在能不能看，而在两端的码率和自适应策略必须分开配置。

开了自适应分辨率后本地录制文件出问题怎么办？

使用自适应分辨率时如需本地媒体录制，“MP4”格式会受影响，需改为“FLV”。这条代价常在联调最后一天才被发现。

小结

混合接入的难点从来不是把移动端接进来，而是承认这两类点位不该共用一套参数：固定点位配清晰度，移动巡检配可达性，前者靠固定码率换细节，后者靠帧率优先、码率下限和自适应属性换连通性。

移动端这一侧的弱网策略，ZEGO 在移动场景的默认配置里已经给了明确取向：流量控制默认开启，ADAPTIVE_FPS 是默认属性，再叠加自适应音频码率。这套默认值背后的判断值得抄，弱网下先保住画面连续性，再谈清晰度。