萤石开放平台音视频接入实战：RTMP、HLS、WebRTC协议选型指南

最近在做视频监控项目时，团队因为音视频协议选型差点吵起来。设备已经选了支持萤石开放平台协议的摄像头，云端也接好了，但到了播放链路，RTMP、HLS、WebRTC、HTTP-FLV……一堆协议摆在面前，每个人都能说出各自的理由，最后只能一个个实测、对比、调优。如果你也正在做萤石开放平台的音视频接入，或者刚接触摄像头上云、直播取流、低延迟对讲这类需求，这篇文章就是给你准备的。

我会把萤石开放平台音视频相关的协议从原理到选型完整拆一遍，重点讲解每个协议到底适合什么场景、延迟能压到多少、为什么有的场景必须用WebRTC，有的场景用HLS反而更稳。内容偏实操，前端、后端、嵌入式开发的工程师都能直接用，系统集成商和安防从业者也可以拿它作为方案设计参考。

1. 项目概述：萤石开放平台音视频协议为什么让人头疼

1.1 这套能力到底解决什么问题

萤石开放平台的音视频能力，本质上是把摄像头、云端和播放端三者串起来。它解决的问题很具体：设备在野外、仓库、商铺等位置拍了视频，怎么稳定地传到云端；用户想随时随地用手机看实时画面、回看录像，怎么保证拉流顺畅；门禁对讲、云台控制这类需要实时反馈的场景，如何把延迟压到人眼几乎无感的程度。

从技术架构上看，整个链路分三段。设备端要处理编码、推流、报警事件；云端负责设备接入、流媒体转发、存储和鉴权；播放端则要解封装、解码、渲染。协议选型在这三段里都有体现，而且往往不是选一个协议就完事，而是做组合。我见过不少项目卡在中间层：设备推流用的是私有协议，播放端却想直接用HLS拉流，中间没做转换，结果怎么调都不通。

这也是为什么做协议介绍和选择时，需要先看清自己到底处在链路的哪一端。你如果是做App播放器，关注的是HLS、HTTP-FLV、WebRTC这些拉流侧协议；如果你是做设备接入，关注的是GB/T 28181、ONVIF、RTSP这类设备侧协议。萤石开放平台的灵活之处在于，它把这两端的能力都开放出来了，所以协议矩阵会更复杂，但也更值得做组合优化。

1.2 协议矩阵的整体逻辑

我的经验是，看协议不能只看名称，要理解它解决什么问题。现在常见的音视频协议，按用途可以分为三大类：

第一类是设备接入协议，典型是GB/T 28181和ONVIF。它们解决的是“怎么把第三方摄像头接入平台、怎么发现设备、怎么取流”。第二类是流媒体分发协议，典型是RTMP、HTTP-FLV、HLS、WebRTC。它们解决的是“云端把一路视频流分发给多个播放器时，用什么封装和传输方式”。第三类是信令与辅助协议，比如SIP、ICE、STUN/TURN，它们更多是配合音视频传输完成会话协商和网络穿透。

萤石开放平台在设备侧支持多种接入方式，在分发侧也提供了多种取流协议接口。核心思路是：设备侧尽量标准化，播放侧尽量兼容。也就是说不强制你只能用某一种协议，而是根据你的终端类型、网络环境、延迟要求，选择最合适的一条链路。下面我先把每个协议的底层原理和特点讲清楚，然后再讲具体怎么选。

2. 协议逐个拆解：RTMP、HLS、HTTP-FLV、WebRTC、GB28181与ONVIF

2.1 直播三剑客：RTMP、HTTP-FLV、HLS的区别

先说RTMP。这是个老协议，基于TCP，早期Flash时代统治了直播行业。它的特点是稳定、成熟、生态完善，很多摄像头和编码器的推流端都内置RTMP推流能力。RTMP由Adobe设计，传输的是FLV封装的数据，握手流程比较冗长，握手成功后通过长连接持续推送音视频数据。

但RTMP在播放端基本已经淘汰了。原因很简单，浏览器不再支持Flash，移动端原生App也没法直接播放RTMP流。所以现在RTMP在萤石开放平台生态里的定位，更多是作为上行推流协议，也就是设备或编码器把视频推到云端流媒体服务器，云端再转成其他协议给播放端。如果你是想在端上直接播放RTMP流，我建议放弃这个念头。

HTTP-FLV可以看作是RTMP的“HTTP化”。它把FLV封装的数据块直接放到HTTP响应体里，播放器通过HTTP请求拿到流后边下边播。这种方式的优势是兼容性好，任何能发HTTP请求的环境理论上都能实现播放；延迟也低，1到3秒是比较容易达到的区间。缺点是移动端和浏览器没有原生播放支持，需要引入专门播放器SDK或者基于WebSocket的Web播放方案。萤石的Web端播放器方案里，HTTP-FLV是常见选项。

HLS则是完全不同的思路。它不传输持续的数据流，而是把视频切成一个个小的TS或者CMAF切片文件，通过一个m3u8索引文件按顺序播放。切片的时长通常是2到10秒，播放器每播完一个切片就继续请求下一个。HLS的最大优点是可以完美利用HTTP缓存和CDN，大规模分发时源站压力很小；苹果系统的Safari浏览器原生支持m3u8播放，iOS端的兼容性非常好。缺点则是延迟高，最少也要比切片时长多出两到三个切片的滞后，延迟通常在5到30秒之间。所以HLS特别适合回放、点播和弱网环境下的直播，但绝不适合实时性要求高的场景。

2.2 低延迟与实时通信的首选：WebRTC

WebRTC是近些年低延迟音视频场景的主角。它走的是UDP传输，配合SRTP加密，延迟能压到500毫秒以内，最低甚至能到一两百毫秒。这套协议不是简单的一个播放协议，而是一整套实时通信框架，包含音视频采集、编解码、网络传输、NAT穿透、抖动缓冲等完整方案。

WebRTC的优势很明显，对于门禁对讲、远程喊话、云台操控这类需要实时反馈的业务，它是目前效果最好的选择。但代价是架构复杂度高。标准的WebRTC方案需要信令服务器完成会话协商，需要STUN服务器探测公网地址，部分网络环境还需要TURN服务器做中继转发。这些组件单独搭建和维护都不轻松，好在萤石开放平台提供了封装好的低延迟方案和配套的WebRTC播放能力，否则我估计很多中小团队根本玩不转。

在萤石开放平台的协议矩阵里，WebRTC和RTSP、HLS、HTTP-FLV并存，适用于不同场景。直播做监控墙、多人围观、大屏展示，用HLS或HTTP-FLV；门禁双向语音、指挥调度、云台实时控制，用WebRTC。选WebRTC之前，一定要确认自己的网络基础设施能支持STUN/TURN，否则延迟会从“极低”变成“极不稳定”。

2.3 设备接入侧：GB/T 28181与ONVIF

播放协议选的再好，设备接不进来也是白搭。萤石开放平台的设备接入侧，有两个协议绕不开：GB/T 28181和ONVIF。

GB/T 28181是面向安防行业的国标协议，核心是基于SIP的信令交互，设备通过SIP REGISTER向平台注册，平台通过INVITE请求设备推送视频流。这套协议的价值在于统一设备接入规范，让不同厂商的摄像头、NVR、平台之间可以互联互通。如果你要接入的不是萤石自己的摄像头，而是第三方的IPC/NVR，GB/T 28181通常是必选项。它的坑点是信令交互细节多，不少设备厂家的实现并不完全标准，对接时经常需要反复调试。

ONVIF则是国际通用的安防设备标准，主要解决设备发现、媒体配置、PTZ控制等问题。它和GB/T 28181的侧重点不同，ONVIF更偏向设备能力抽象，GET/PUT方式获取设备信息，设置视频参数、移动云台等。很多海外设备和部分国产设备都支持ONVIF。实践中，我一般会同时开启设备的ONVIF配置用于设备发现和参数管理，再用GB/T 28181做正式的流媒体接入，两条腿走路，兼容性和稳定性兼顾。

2.4 协议特性速查表

3. 协议选择方法论：5个维度定方案

3.1 维度一：延迟忍受度决定协议下限

选择协议，首先要问业务能接受多高的延迟。我把常见场景分成了三档。

第一档是实时操控类，比如门口机呼叫、远程开锁、双向对讲、云台方向控制。这类场景如果延迟超过1秒，用户体验会非常差：你看着画面里的云台转到了目标位置，实际画面可能还是两三秒前的，操作感“发飘”。这一档只能选WebRTC，用量化标准来说，500毫秒以内的延迟是基本要求。

第二档是直播监控类，比如店铺看护、施工现场远程监管、家长看娃。用户只需要“实时了解”正在发生什么，偶尔放大看细节，不需要和现场做交互。HTTP-FLV的1到3秒延迟完全够用，价格和复杂度也比WebRTC亲民得多。

第三档是录像回放与取证类，比如查历史事件、回看某段时间的监控。这类场景延迟已经不是核心指标了，首帧秒开、拖动进度条跟手、画面清晰稳定才是重点。HLS的切片机制天然适合这类需求，用户体验稳定，还可以借助CDN做缓存加速。

我的建议是，别把“延迟”作为单一参数去比拼，而是把它和业务行为绑定在一起定义。延迟目标最好是可量化的SLA，比如合同上写“实时视频延迟不超过3秒”，那你就老老实实选HTTP-FLV或者WebRTC，而不是HLS。

3.2 维度二：终端覆盖范围决定协议上限

第二个维度是观看终端的类型。不同协议在终端上的支持情况差异很大，我列一个比较通用的匹配原则。

如果你的观看端主要是PC浏览器，Web端原生直播尽量用HTTP-FLV或者WebRTC，配合播放器SDK可以做得比较顺滑。要注意的是，HTTP-FLV在移动端Safari上没有原生支持，纯H5页面很难直接播放，通常需要嵌入一个基于WebSocket转发FLV数据的播放器，或者直接改用HLS。

如果你主要做iOS/Android的App，HLS在iOS端最稳，Safari可以直接解m3u8；Android端对HLS的兼容性也不错，但需要自己处理一些延迟抖动。想要更低延迟，就集成WebRTC的SDK。通常的做法是：App里同时支持HLS和WebRTC两种模式，Wi-Fi下默认HLS，低延迟场景切换WebRTC。

如果你要做小程序，小程序的video组件对HLS支持最好，可以直接播放m3u8地址；低延迟方面，多家厂商提供了小程序专用的WebRTC方案，但需要申请相应的类目权限。萤石开放平台的播放器方案在这些终端上都有对应封装，接入的时候先确认一下SDK的版本和平台支持清单，能省很多事。

3.3 维度三：并发规模与带宽成本博弈

并发规模直接决定你的分发架构和带宽费用。HLS在并发场景下的优势特别明显，因为切片文件可以被CDN缓存，用户越多，边缘节点的命中率越高，源站压力反而更小。HTTP-FLV虽然也能走CDN，但它是长连接，每个用户都会持续占用一条连接到源站的链路，并发上去了，源站和带宽压力会成倍增加。

我自己做过一个对比，同样是一千路并发观看，HLS配合CDN，源站带宽消耗可能只有HTTP-FLV的三分之一到四分之一，原因是边缘缓存承担了大部分流量。WebRTC的并发模型不同，它优先走P2P，也就是用户互相之间直接传流，服务器只做信令协调，理论上并发越大，P2P比例越高，带宽成本越分散。但这是在NAT穿透成功率高的情况下。一旦大量用户处于复杂的对称型NAT后面，需要TURN服务器中转，成本就会反过来飙升。

所以，如果你做的是面向公众的大规模直播，HLS是性价比最稳的。如果你做的是几百路以内的中小规模监控直播，HTTP-FLV或WebRTC更合适，延迟可控，部署也简单。

3.4 维度四：接入复杂度和维护成本权衡

接入复杂度往往是最被低估的维度。有经验的开发者都明白，上线后真正费精力的不是写代码，而是排障和调优。WebRTC虽然效果好，但它需要信令服务和STUN/TURN服务，任何一个环节出问题，都会表现为“网络差、连不上”，排查链非常长。HTTPS里混合内容、浏览器策略调整、防火墙UDP封锁，这些都可能让WebRTC连接失败，而且失败原因很难一眼看穿。

相比之下，HLS和HTTP-FLV基于HTTP，排查链路简单很多。打开浏览器开发者工具就能看到请求状态码、耗时和缓存命中情况，问题定位快得多。RTMP推流链路也相对成熟，调试工具多，但播放端兼容性问题会比较烦。我的实际建议是：除非业务确实有强实时需求，否则尽量选维护路径短的协议。需求是“差不多能看就行”，那就没必要上WebRTC给自己增加运维负担。

3.5 维度五：结合萤石开放平台的推荐组合

把上面四个维度结合起来，在萤石开放平台下我常用的协议组合有这么几套：

第一套，标准远程监控组合：设备接入走设备侧的RTSP或私有协议上云，播放端取HTTP-FLV的直播地址，同时开启HLS地址用于回放。这套适合大多数安防场景，延迟可控制在3秒左右，播放兼容性很好，带宽成本可控。

第二套，低延迟对讲组合：设备侧接入不变，播放端和语音对讲都走WebRTC。萤石平台的低延迟方案里，WebRTC链路延迟一般能做到1秒以内。适合门禁、医院呼叫、指挥调度等场景。

第三套，大规模直播组合：设备推流上云后，云端转封装为HLS切片，再叠加CDN分发。适合景区慢直播、工地多工地直播、活动直播这类观看人数多、实时互动少的业务。代价是延迟高，如果直播里没人需要控制设备，这个方案最省钱。

体育场馆这类混合场景，我还会把HTTP-FLV和WebRTC同时接入：默认大屏观看用HTTP-FLV，观众扫码远程操控摄像机时切到WebRTC。协议之间其实不需要做零和选择，完全可以按业务路由分流。

4. 实操记录：从开通到播放的完整链路

4.1 准备工作：账号、应用与能力开通

在萤石开放平台开始之前，先要把账号和应用准备好。注册并登录开放平台后，在控制台创建一个应用，系统会给你一对AppKey和AppSecret，这是后续所有API调用的凭证。需要注意，AppSecret要严格保密，不能出现在前端代码或者公开仓库里，建议统一存放在后端服务环境变量中。

创建完应用，还要确认音视频相关的能力已经开通。萤石的能力是按模块划分的，比如实时预览、录像回放、云存储、设备消息推送等。如果你在调用接口时遇到“能力未开通”或“API无权限”之类的报错，第一时间去应用详情页查看能力列表，而不是去查业务逻辑。另外，设备本身也要绑定到你的账号下面，可以通过设备序列号和验证码在控制台添加。验证码是设备的六位大写字母+数字组合，通常在设备机身标签上能找到。

4.2 获取AccessToken的API交互细节

音视频接口调用前，需要先获取AccessToken。这一步很标准，向/api/lapp/token/get接口发起POST请求，携带AppKey和AppSecret，接口会返回一个token字符串和过期时间，有效期通常为7天。token有效期内可以重复使用，不用每次都重新获取。

这里我趟过两个坑。第一个是get请求里的AppSecret不能用错了，用错直接返回签名错误。第二个是token过期时间，生产环境里7天是个不长不短的时间，建议写个定时任务在过期前主动刷新，而不是等到报错再去刷。

获取token的HTTPS请求示例：

POST /api/lapp/token/get HTTP/1.1 Host: open.ys7.com Content-Type: application/x-www-form-urlencoded appKey=你的AppKey&appSecret=你的AppSecret

返回的JSON结构大致如下：

{ "code": "200", "msg": "操作成功", "data": { "accessToken": "at.xxxxxxxxxxxxxxxxxxxxxxxxxxxx", "expireTime": 1728345600000 } }

调用其他业务接口时，把accessToken作为公共参数带上，很多签名算法也和它有关。如果你使用的是萤石官方SDK，SDK内部会帮你管理token的生命周期；如果是自己写HTTP客户端，就要把过期逻辑处理好。我的建议是封装一个统一的API客户端，默认对token做内存缓存和定时刷新，避免每个请求都去获取新token，也能减少被平台限流的概率。

4.3 获取直播播放地址的典型流程

拿到token后，获取直播地址就水到渠成了。核心接口是/api/lapp/live/address/get，请求时需要传设备序列号和通道号。设备序列号是萤石设备的唯一标识，通道号一般默认为1，表示第一路视频通道。如果你要指定协议类型，可以在请求参数里明确指定，比如仅返回HLS地址，或同时返回HLS和RTMP地址。

带参数的请求示例：

POST /api/lapp/live/address/get HTTP/1.1 Host: open.ys7.com Content-Type: application/x-www-form-urlencoded accessToken=at.xxxx&deviceSerial=设备序列号&channelNo=1&protocol=2

返回结果中一般包含hls地址、rtmp地址、设备状态码和播放地址过期时间。以我的实测经验，返回的hls地址格式为https://xxx/xxx.m3u8，可以直接拿到VLC、ffplay或者播放器SDK里播放；rtmp地址则是rtmp://xxx/xxx。

播放地址本身也带有效时间，过期后需要重新获取。在正式项目中，我不建议把播放地址硬编码到前端，而是让后端做一层代理：客户端先请求自己的服务端，服务端再从萤石接口获取播放地址并返回。这样既能做鉴权校验，也能统一控制地址的刷新策略，避免播放地址泄露后被人恶意拉流。

4.4 播放器接入与参数调优

播放器侧，我用得最多的是面向Web的播放器SDK，H5播放器初始化代码一般不长。以HTTP-FLV为例，核心逻辑是创建播放器实例，传入容器、播放地址、清晰度配置等。关键参数里，autoplay要结合实际浏览器策略设置，很多浏览器会拦截有声自动播放，需要用户手动点击后才能播放。

一个典型的初始化片段如下：

const player = new JSPlayer({ url: 'https://xxx/xxx.flv', container: document.getElementById('video-container'), autoplay: true, isLive: true, muted: false, bufferTime: 1, lowLatencyMode: true }); player.play();

这里bufferTime很关键。延迟和卡顿是一对矛盾体：缓冲时间设得短，延迟低，但网络抖动时容易卡顿；缓冲时间设得长，画面稳定，但延迟会明显增加。低延迟场景我一般把bufferTime压到1秒以内，普通监控场景可以放宽到2到3秒。lowLatencyMode也是同样的逻辑，开启后播放器会尝试更激进的缓冲策略，但如果网络质量差，反而可能频繁重缓冲。

如果你是移动端，萤石提供了对应的播放器SDK，接口风格类似。集成SDK时要注意包体积和权限声明，尤其是Android端，摄像头、麦克风、存储权限都要在Manifest里配置，否则可能出现“能播放但无法录像”的奇怪现象。

5. 踩坑清单与问题排查实录

5.1 延迟忽高忽低怎么查

有段时间我负责的项目里，播放端总是隔几分钟延迟就跳到十秒以上，然后又自己恢复正常。排查下来，核心原因是播放器缓冲策略太保守。播放器检测到网络抖动后会主动增加缓冲长度，只要网络一抖，缓冲越积越多，延迟自然飙升。问题出在把自动缓冲策略和低延迟模式没有区分开。

解决思路是分场景处理：对实时性要求高的设备，强制关闭自动缓冲调整；对普通监控，允许缓冲，避免频繁卡顿。另一个常见原因是视频流的GOP（关键帧间隔）设置不合理。GOP越短，播放器起播越快，但码率波动大；GOP越长，延迟恢复越慢，因为播放器需要等到下一个关键帧才能刷新画面。一般把GOP控制在1到2秒比较合适。

5.2 首帧白屏或者黑屏的原因

首帧时间长是我们遇到最多的用户反馈。原因是多方面的，首先是网络DNS解析慢，播放域名没有做好预解析；其次是HLS切片请求模式本身较慢，首帧需要先拿到m3u8索引，再请求第一个切片，切片请求完成才开始起播。如果网页里同时加载了其他资源，播放器启动还会被阻塞。

我常用的优化手段有三个：一是提前建立播放器对象并调用preload接口，把流预先加载到缓冲区，用户点开时几乎秒开；二是把播放域名的DNS TTL调短，同时使用HTTP/2多路复用；三是针对HLS，开启lowLatency模式，使用较短的切片和部分字节加载。实测下来，首帧时间能从3秒多压到1秒以内。

5.3 音画不同步与花屏处理

音画不同步，多半是时间戳问题。HLS切片在封装时，音频和视频时间戳的基准没有对齐；或者播放器在跳转进度时，音频缓冲和视频缓冲更新不同步。处理办法是更新播放器 SDK 到新版本，同时检查原视频流的编码参数，视频编码建议H.264 baseline或main profile，音频编码建议AAC，尽量避免使用过高profile导致终端解码能力跟不上。

花屏则更多出现在弱网环境。UDP传输的WebRTC流在丢包严重时会花屏，HLS和HTTP-FLV这类TCP传输流在弱网下表现为卡顿而不是花屏。如果WebRTC流出现花屏，我的排查顺序是：先看丢包率，再检查编码码率设置，最后看STUN/TURN链路是否稳定。很多时候，花屏不是解码器的问题，而是码率设置过高，超出了网络实际承载能力。

5.4 鉴权过期与防盗链注意事项

播放地址有效期到了之后，播放器会报错、黑屏。这个坑特别隐蔽，因为很多项目在测试阶段没有留意地址过期时间，上线后用户看了一段时间才发现突然黑屏。我的做法是前端在收到播放器报错事件后，立即回调后端刷新播放地址，再重新设置播放器的url。刷新接口要加幂等处理，避免并发刷新导致Token覆盖。

防盗链方面，平台侧提供了URL签名和Referer白名单两种常见方式。如果接口返回的播放地址暴露了签名参数，不要擅自更换；签名参数与播放地址是强绑定的，修改后会导致拉流失败。正式项目一定要开启播放地址鉴权，否则播放地址一旦泄露，任何人都能通过公开链接看到监控画面，这种事故在安防行业属于重大安全事故。

5.5 低延迟场景的WebRTC NAT穿透问题

WebRTC在公网环境里最典型的坑是NAT穿透失败。STUN服务器能拿到公网映射地址，但对称型NAT环境下，不同端口映射的地址不同，P2P连接很难建立，这时候就必须走TURN中继。我见过一个项目，办公网里测试WebRTC延迟只有200毫秒，但到了用户家里，画面卡得没法看，最后发现是用户路由器启用了严格的防火墙策略，UDP包全部被丢弃，TURN服务器也没配置好。

排查WebRTC连接问题，我用的是webrtc-internals面板，能看到ICE候选路径和连接状态。如果发现候选路径为relay，基本就是P2P失败了。优化思路有两个：一是增加STUN服务器数量，提高NAT穿透的成功率；二是部署可靠的中继节点，并保证中继节点带宽充足。TURN中转流量成本很高，生产环境一定要提前做成本评估。

6. 写在最后的几句实在话

做了这么久音视频接入项目，我最深的体会是：协议选型永远没有标准答案，但有可复用的判断框架。别被“低延迟”“高并发”“兼容性好”这些词带偏，先回到业务本身，问自己三个问题：用户最不能接受的是什么？终端主要是什么？维护团队有多少精力投入？

我建议你先搭一套最小验证环境，用目标设备和真实网络环境做一次完整的链路测试。局域网测试和公网测试结果差异可能非常大，尤其是WebRTC这类高度依赖网络环境的协议。我之前就在某项目里因为迷信测试环境的数据，导致上线后又紧急回滚了一次，来回折腾了三天。先把协议做个冒烟测试，再谈大规模落地，这个顺序不能反。

最后一个实际小技巧：无论选哪套方案，客户端和服务端都要把日志体系建好。音视频链路很长，任何一个环节出问题都需要快速定位。我自己习惯给每个播放请求分配一个traceId，贯穿设备、云端、播放器，这样排查问题的时候能省下至少一半的时间。希望这篇文章能帮你少踩几个坑，在萤石开放平台做音视频接入时多一分从容。