直播开放平台 · 关于我们

先交代一句最直白的：直播开放平台不是某个具体的 App，而是一类产品的统称。 它把「把画面推出去、让成千上万人同时看到」这件事拆成很多个环节——采集、编码、推流、 转码、分发、鉴权、录制、连麦、统计——然后把这些环节包装成接口和 SDK， 交给开发者去调用。你自己做一个电商直播小程序，或者给公司年会搭一个内网直播页， 背后跑的可能就是某家开放平台的能力。

我们这批人从 2021 年开始做这件事。起点其实很朴素：当时团队里有人要接第一条直播链路， 翻了三家平台的文档，发现同一个概念在不同文档里叫法不一样，同一个「低延迟」在不同页面上 指的是完全不同的量级，价格表的计费维度更是各写各的。踩完这轮坑之后我们决定， 与其每次重新摸一遍，不如把公开信息整理成一张能对照着看的表。

所以这个站点的定位很明确：信息整理与导航，不是任何平台的官方渠道， 也不代理任何一条线路。你在页面上看到的能力项、计费口径、限制说明， 全部来自各平台对外公开的文档、帮助中心与公告页；凡是公开渠道查不到的数据， 我们宁可留空写「待确认」，也不去凑一个看起来漂亮的数字。

我们解决的核心问题就三个：这条链路该怎么接、这个价格口径到底怎么算、 出问题了先查哪里。围绕这三件事，我们做了能力横评、上手清单、踩坑记录和 政策观察四类内容。它们不追求「全网最全」，但每一条都尽量写清楚出处和适用条件， 因为选型这件事，看错一个限制条件的代价，往往比多看十篇文章的时间成本高得多。

第一步：先定业务指标，再去看文档

打开任何一家平台的文档之前，先写下三个数字：延迟上限（能接受几秒）、 并发峰值（最多同时多少人看）、清晰度档位（720P 够不够）。 这三项直接决定了你后面能选哪一档能力。举个例子：如果你的场景是「主播喊一句、观众三秒内反应」， 那普通 HLS 分发就不合适，得看低延迟直播或快直播；如果只是录播回看，那用标准分发就够了， 没必要为低延迟能力多付钱。

第二步：分清「推流端」和「播放端」两套东西

新手最容易混的一点：推流 SDK 和播放 SDK 通常是两套独立的集成，各自有版本号、 各自的鉴权参数，甚至可能来自不同的技术栈。很多人只集成了推流端，测试时自己用浏览器 打开播放地址看得到画面，就以为完事了——结果上线后发现播放页在弱网下频繁卡顿， 因为播放端根本没做码率自适应。建议从一开始就把两端分开列进任务清单。

第三步：把鉴权方案写进架构设计

推流地址和播放地址一般是带签名和有效期的，签名在服务端生成，客户端只拿结果。 这个顺序不能反：如果你打算在客户端直接生成签名，密钥就有暴露风险。 我们见过不止一个项目在上线前才发现这个结构问题，只能推倒重来。 另外签名有效期要设得合理——太短会导致长时间直播中途断流，太长则失去防盗链意义。

第四步：小流量跑通再谈并发

先找一个内部同事当主播，跑通「推流 → 转码 → 播放 → 录制」全链路， 确认每一环都有可查的日志。这一步花的半天时间，能抵掉后面上线当天的通宵。 并发测试不要一上来就压到业务峰值，先按峰值的三成跑一轮， 看错误率和首帧时间，再逐步往上加。

直播开放平台几个高频踩坑点

坑一：把「支持 RTMP」理解成「全平台支持」。RTMP 在浏览器端早已不被主流支持， 网页播放基本要靠 HLS、FLV 或 WebRTC，文档里写支持的协议要确认清楚指的是推流还是播放。

坑二：忽略配额与限流说明。很多平台对单账号的并发推流路数、 接口调用频率都有默认上限，超了会直接返回错误。这些限制一般写在文档的角落， 选型阶段就该翻出来写进自己的容量规划。

坑三：录制文件的生命周期。录制默认保存多久、什么时候清理、 能不能转存到自己的对象存储，这些条款直接关系到你的存档策略， 别等文件被清掉才去看文档。

最后提醒一句：上面这些经验来自公开文档与实操整理的归纳， 各平台的具体参数会随版本变化，落地前请以对应平台的官方文档为准。 凡是我们在公开渠道核不到的细节，这里都会明确写「待确认」，不会替你猜。

做「直播开放平台」这块内容整理已经有些年头了。说实话，最常被问到的问题不是 「哪家技术最强」，而是「我到底该从哪一页文档开始看」。这个困惑背后其实是一个更实际的问题： 大部分人选型时，手里并没有一份清晰的业务指标清单，于是只能在各家文档之间来回跳， 越看越乱。

所以我们后来调整了内容顺序——不再先摆平台对比，而是先讲「你该怎么描述自己的需求」。 这篇关于页里那份上手顺序清单，就是从这个思路长出来的。 读者反馈里最有价值的一类，是那种带着具体场景来的：「我们做的是在线课堂， 老师和学生要实时对话，延迟能接受一秒左右」——这种描述我们能直接给出方向； 而「哪个平台最好」这种问法，说实话没有答案。

另一个反复出现的点是价格。直播开放平台的计费维度普遍不止一项， 转码、分发、录制、连麦往往分开计价，各自的单位和阶梯也不一样。 很多人第一眼看到单价觉得便宜，算完整套链路才发现预算差出一截。 我们的建议一直是：把你的业务换算成「每月推流时长 + 转码档位 + 分发流量 + 录制存储」 这四个可估算的量，再去对照价格表，比看任何排行榜都靠谱。

至于编辑部自己，有几条规矩一直没变：不写没有出处的数字，不为了更新而更新。 看板里有时候会连着几天显示「本批次暂无变更」，这不是偷懒， 而是公开文档确实没有动。我们更愿意让你看到一段诚实的空白， 而不是一堆看起来很热闹、但经不起点开原文核对的条目。