从采集编码到 CDN 分发：直播系统的技术底层、协议选型、码率并发与建设路径全解析
学术会议、手术示教、远程会诊，等保三级合规。
多机位腹腔镜转播、<800ms 超低延迟教学。
私域带货、商品挂载、小程序闭环。
微信生态原生集成，私域流量变现。
健康科普、养生讲堂、医患互动。
医疗/教育/企业/电商 14 大场景方案总览。
15 家主流直播平台横向 PK，含专属对比页。
活动/发布会/培训通用视频直播，多码率自适应。
无需 App，H5 网页即开即看，低门槛触达。
线上课程/讲座/发布会一站式直播方案。
手术/演出/会议多机位切换，专业导播台。
云展会/虚拟展厅，展商与观众实时互联。
校园招聘/雇主品牌直播，简历即时收集。
价格/带宽/成本计算器与方案匹配器。
很多人以为"直播平台"就是一个能开播的网页，事实上它是一整套把音视频从现场搬到观众屏幕的工程系统。行业里通常把这条链路拆成八段：采集 → 前处理与编码 → 推流上行 → 接入与 CDN 分发 → 转码转封装 → 播放端 → 录制存储 → 数据与管控后台。判断一套直播系统成熟与否，不看它的官网做得多漂亮，而看这八段里每一段有没有可观测、可配置、可兜底的手段。
| 环节 | 干什么 | 关键指标 | 常见坑 |
|---|---|---|---|
| 1. 采集 | 摄像机、摄像头、桌面屏幕、多路信号经采集卡或导播台进入系统 | 分辨率、帧率、色彩采样、音频采样率（44.1/48 kHz） | USB 供电不足导致掉设备、多路信号声画不同步 |
| 2. 前处理与编码 | 美颜、降噪、混音、叠加水印，再压成 H.264/H.265/AV1 码流 | 码率、GOP 长度、B 帧、Profile/Level、编码耗时 | 开启 B 帧与长 GOP 换取压缩率，代价是延迟显著上升 |
| 3. 推流上行 | 用 RTMP/SRT/WebRTC 把码流送到接入点，地址带鉴权参数 | 上行带宽、丢包率、RTT、抖动 | 上行带宽没留冗余、用公共 Wi-Fi 推流、跨运营商链路抖动 |
| 4. 接入与 CDN 分发 | 边缘节点就近服务观众，未命中时回源拉取 | 命中率、回源率、首帧时间、节点覆盖率 | 回源率过高把压力顶回源站；调度不准导致跨网访问 |
| 5. 转码与转封装 | 一路推流输出多档清晰度供自适应切换，或换成 HLS/FLV 容器 | 转码耗时、画质损失、转码成本 | 实时转码是延迟和成本的大头，非必要不开 |
| 6. 播放端 | H5、App、小程序、电视端拉流解码渲染 | 首帧时间、卡顿率、解码方式（硬解/软解）、错误码 | iOS 不支持 FLV、低端机软解发热掉帧、缓冲策略过于保守 |
| 7. 录制与存储 | 实时录制、自动转点播、剪辑切片、冷归档 | 录制完整率、回放生成时长、存储周期 | 只做本地录制不做云端双录，推流端断电即丢片 |
| 8. 数据与管控后台 | 并发曲线、地域运营商分布、观看行为、互动记录、审计日志、告警 | 数据粒度、可导出性、留存时长 | 只有一个"总观看人数"，拿不出名单和完课率，业务无法复盘 |
一句话概括：前四段决定"能不能播出去"，后四段决定"播得稳不稳、能不能交付给业务"。企业采购时常犯的错误是把预算全砸在摄像机和导播台上，最后卡在上行带宽、CDN 调度和播放端兼容上。如果你更关心场景与选型流程，可以看企业直播专题页；本篇聚焦技术底层。需要按自身并发规模倒推链路容量，可用带宽计算器先算一笔账。
协议是直播系统里最容易被忽略、却最影响体验的一层。选型前先分清两个位置：上行指采集端到服务器，业内叫"推流"；下行指服务器到观众，叫"拉流"或"分发"。RTMP 与 SRT 主要活在上行，HLS 与 HTTP-FLV 活在下行，WebRTC 两头都能干。用错了位置，再怎么调参也没用。
RTMP 基于 TCP、默认 1935 端口，端到端 1-3 秒。它的优势是生态最成熟，OBS、硬件编码器、导播台、手机推流 App 几乎全都支持，服务端实现也最稳定。缺点是浏览器已不能直接播 RTMP，必须由服务端转成 HLS 或 HTTP-FLV 再分发；另外它跑在 TCP 上，弱网丢包时会触发队头阻塞，表现为画面停住转圈。结论：作为上行推流协议，RTMP 依然是首选，Adobe 早已停止更新，但它在推流侧的地位短期内不会被取代。
HTTP-FLV 走 HTTP 长连接下发 FLV 流，延迟 1-3 秒。它复用现有 HTTP 基础设施，穿透性好，PC 浏览器可通过 MSE 方案直接播放，无需插件。缺点是需要维持长连接、不支持原生多码率自适应（多档清晰度要开多条流），且 iOS Safari 不支持，苹果设备仍需回落 HLS。适合带货上链接、现场问答、竞拍这类要求 1-3 秒延迟、又以 PC 和安卓为主的场景。
HLS 把流切成一个个小片段（ts 或 fMP4），播放器按列表依次拉取，默认缓存 3 个切片，因此延迟通常在 6-20 秒。它的优势是兼容性无出其右：iOS、Safari、智能电视、机顶盒原生支持，天然支持多码率自适应，HTTP 文件也能被任意 CDN 缓存。低延迟版本（LL-HLS / LHLS）通过部分片段传输可把延迟压到 2-5 秒，但服务端与播放器都需支持。适合发布会、培训、年会这类对延迟不敏感、观众网络环境复杂的场景。
WebRTC 基于 UDP（SRTP），端到端可做到 200-800 毫秒，浏览器与移动端原生支持，内建 NACK、FEC、PLC、NetEQ 等一整套抗丢包机制，也是目前低成本实现多人连麦的主流方案。代价是架构复杂：大规模分发要引入 SFU 并做级联，服务端资源消耗远高于 HTTP 分发，录制、审核、CDN 复用都要旁路处理。适合连麦互动、双师课堂、远程协作，以及手术示教这类要求强实时、低并发的场景。
SRT 基于 UDP，通过 ARQ 重传与可配置缓冲在丢包链路上保持稳定，延迟参数通常设为 120 毫秒到 1 秒。它原本服务于广电制作域，现在广泛用于现场到机房的远距离回传、跨国跨省传输、5G 聚合背包。浏览器不支持 SRT，需要网关转成 RTMP 再进入分发环节。判断标准很简单：当你的上行链路丢包率超过 1%、或 RTT 超过 100 毫秒时，就该考虑用 SRT 替代 RTMP 上行。
| 协议 | 主要位置 | 传输层 | 典型延迟 | 兼容性 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|---|---|---|
| RTMP | 上行推流 | TCP | 1-3 秒 | 编码器与推流工具全覆盖，浏览器不能直接播 | 生态最成熟、实现稳定、延迟可控 | 弱网队头阻塞、需转封装才能分发 | OBS、硬件编码器、导播台推流 |
| HTTP-FLV | 下行分发 | HTTP 长连接 | 1-3 秒 | PC/H5 广泛支持，iOS 不支持 | 延迟低、无插件、可复用 HTTP 设施 | 长连接占用、无原生自适应码率 | 带货、竞拍、现场问答 |
| HLS | 下行分发 | HTTP 切片 | 6-20 秒（低延迟版 2-5 秒） | 全平台原生，iOS 与电视端强制 | 兼容性最好、原生自适应、CDN 友好 | 切片机制导致延迟高、小文件数量多 | 移动端大规模分发、发布会与培训 |
| WebRTC | 双向实时 | UDP（SRTP） | 200-800 毫秒 | 浏览器与移动端原生 | 亚秒级、抗丢包机制完备、支持连麦 | 架构复杂、成本高、大规模分发需级联 | 连麦互动、答疑、手术示教、双师课堂 |
| SRT | 上行/制作域 | UDP | 可配置，常见 120 毫秒-1 秒 | 专业编码器与硬件支持，浏览器不支持 | 抗丢包强、可加密、适合远距离回传 | 终端支持有限，需网关转换 | 现场回传、跨国传输、5G 聚合链路 |
优化延迟的第一步，是搞清楚延迟花在哪里。端到端延迟大致由七部分组成，其中播放器缓冲与转码通常是最大的两块。
| 环节 | 典型耗时 | 说明 |
|---|---|---|
| 采集与预处理 | 30-100 毫秒 | 传感器曝光、降噪、美颜、音画同步 |
| 编码 | 50-500 毫秒 | 取决于编码预设、GOP 长度与是否开 B 帧；低延迟预设可压到 50-150 毫秒 |
| 上行网络 | 20-150 毫秒 | 由 RTT 与抖动决定，跨运营商或跨国会更高 |
| 转封装 | 50-300 毫秒 | 只换容器不重编码，算力消耗极低 |
| 转码 | 300 毫秒-3 秒 | 多码率实时转码是延迟与成本的主要来源 |
| CDN 分发 | 50-300 毫秒 | 边缘节点未命中时回源，多一轮往返 |
| 播放器缓冲 | 1-10 秒 | HLS 默认缓存 3 个切片，FLV 缓存 1-2 个 GOP，这是观众感知延迟的大头 |
| 等级 | 端到端延迟 | 推荐组合 | 适用场景 | 代价与注意 |
|---|---|---|---|---|
| 标准延迟 | 3-10 秒 | RTMP 推 + HLS 拉 | 培训、年会、发布会、公开课、赛事转播 | 成本最低、抗弱网最好、兼容性最好，观众几乎无感 |
| 低延迟 | 1-3 秒 | RTMP 推 + HTTP-FLV 拉，iOS 回落 HLS | 带货上链接、抽奖、竞拍、现场问答 | 需维持长连接，弱网用户容易二次缓冲 |
| 超低延迟 | 400 毫秒-1 秒 | WebRTC 或低延迟 HLS / 低延迟 FLV | 连麦互动、远程协作、双师课堂、手术示教 | 架构复杂、成本高、抗弱网能力弱 |
码率是每秒传输的比特数，它同时决定了画质、带宽占用和流量成本。换算公式：单观众流量（GB）= 码率（Mbps）× 时长（秒）÷ 8 ÷ 1024。举例：4 Mbps 看 1 小时约消耗 1.8 GB。
| 清晰度 | 分辨率 | 帧率 | H.264 推荐码率 | H.265 参考码率 | 建议上行带宽 | 1 小时单人流量 |
|---|---|---|---|---|---|---|
| 流畅 | 854×480 | 25 fps | 800-1200 kbps | 500-800 kbps | ≥ 2 Mbps | 约 0.5 GB |
| 标清 | 1280×720 | 25/30 fps | 1500-2500 kbps | 1000-1600 kbps | ≥ 4 Mbps | 约 0.9 GB |
| 高清 | 1920×1080 | 25/30 fps | 3500-5000 kbps | 2000-3000 kbps | ≥ 8 Mbps | 约 1.8 GB |
| 2K | 2560×1440 | 30 fps | 6000-9000 kbps | 4000-6000 kbps | ≥ 15 Mbps | 约 3.4 GB |
| 4K | 3840×2160 | 30 fps | 12000-20000 kbps | 8000-12000 kbps | ≥ 30 Mbps | 约 7.2 GB |
参数需要按内容动态调整：体育赛事、演唱会、游戏、手术视野内大量器械移动这类高运动画面，码率上浮 30%-50%；PPT 讲授、静态机位访谈这类低运动画面，可下调 20%-30%。H.265 与 AV1 在同等主观画质下比 H.264 省 30%-50% 码率，但要求终端支持硬解，老旧设备可能只能软解，反而更耗电。
带宽规划有两条经验值：一是上行带宽按推流码率的 1.5-2 倍预留，留给丢包重传和网络抖动；二是下行总带宽 = 码率 × 并发人数，1 万人看 1080P 约需 40 Gbps，这部分由 CDN 承担，企业侧不必自己扛，只需保证上行稳定。具体数字可以用成本计算器按你的并发规模实测。
并发（CCU，Concurrent Users）指同一统计周期内正在拉流的连接数，常用的统计粒度是 1 分钟或 5 分钟。它和"累计观看人次""观看 UV"不是一个概念：一场 1 小时的直播可能有 5 万人次观看，但峰值并发只有 8000。采购时一定要问清楚报价口径是峰值并发还是累计人次，这是最容易产生纠纷的地方。
CDN 扛住万人的原理是把一份流量复制成上万份，且让每一份都就近送达。典型架构是源站、区域中心、边缘节点三级：观众请求被调度到最近的边缘节点，节点已缓存则直接返回，未缓存才回源拉取一次。因此核心指标是命中率与回源率——命中率越高，源站压力越小，成本也越低。调度方式常见有 DNS 调度、HTTPDNS 调度与 302 调度，精细的系统还会按运营商、省份、甚至单机质量评分动态切换。
关于弹性扩容：多数云服务与 SaaS 平台都提供突发带宽池，但"弹性"不等于"无限"。瞬时涌入超过报备峰值时，系统通常会触发排队或降清晰度，而不是无上限扩容。所以压测报备不是走过场，它决定了平台为你预留多少资源。
做一套直播系统，绕不开"自己做、买现成、还是拿云厂商的积木拼"这道选择题。三条路径没有绝对优劣，取决于团队规模、直播在业务中的位置、以及对数据和定制的要求。
| 维度 | 自研自建 | 采购 SaaS | 云 PaaS 组装 |
|---|---|---|---|
| 首年投入 | 50 万-200 万元起（研发人力 + 服务器与带宽） | 1 万-20 万元/年（按并发与模块） | 按量与云产品计费，中等 |
| 上线周期 | 3-9 个月 | 1-7 天开通，1-2 周完成配置与联调 | 2-8 周 |
| 人力配置 | 5-10 人（音视频、后端、前端、SRE、测试） | 业务侧 0.5-1 人即可运营 | 1-3 人研发做集成与运维 |
| 定制与集成 | 完全自由 | 受平台开放能力限制（页面配置、API、SDK） | 灵活度高，可深度嵌入自有 App 与系统 |
| 运维责任 | 全部自担，需 7×24 值守 | 平台承担，SLA 写入合同 | 自运维集成层，底层由云厂商保障 |
| 可控性与数据归属 | 最强，数据完全自持 | 较弱，取决于平台是否支持私有化与数据导出 | 中等，数据在企业自有云账号内 |
| 成本曲线 | 固定成本高、边际成本低，规模足够大才划算 | 随并发与场次线性增长 | 随流量线性增长，需持续做成本优化 |
| 主要风险 | 技术门槛高、人才依赖强、进度易失控 | 供应商绑定，深度需求可能无法满足 | 多厂商协调复杂，账单容易失控 |
| 适用团队 | 直播是主营业务、有专职音视频研发团队 | 绝大多数企业，业务驱动、要求快速上线 | 有研发、希望把直播能力嵌进自有产品 |
此外还有一条折中路线：混合部署或私有化部署——把鉴权、录制、观看数据留在企业内网或专有云，分发仍走公有云 CDN，兼顾合规与弹性。金融、医疗、政务这类受监管行业常采用这种形态。
不确定该走哪条建设路径？
把峰值并发、清晰度要求、年场次与集成需求告诉我们，直达播技术团队可协助做一次链路选型与容量测算。
电话 微信 videotv888 · 微信 videotv888
采购或验收时，建议按下面这张表逐项打勾。很多平台在演示环节只展示播放器有多流畅，真正决定长期能否用下去的，是审核、鉴权、数据这三块。
| 模块 | 作用 | 采购时要问什么 |
|---|---|---|
| 推流工具 | 桌面软件、硬件编码器、手机 App、网页端推流 | 支持哪些推流方式？有没有免安装的网页推流？弱网能否切换到 SRT？ |
| 多码率转码 | 一路推流输出多档清晰度，供播放器自适应切换 | 转码是否单独计费？会增加多少延迟？是否支持 H.265？ |
| 录制与回放 | 云端实时录制、自动转点播、剪辑与切片 | 回放生成需要多久？录制失败有无补偿？是否支持边播边剪？详见录制回放 |
| 内容审核 | 抽帧截图、语音转写、画面文字识别，机审加人审 | 抽帧间隔多少秒？有没有人工复核通道？命中违规能否一键断流？ |
| 鉴权与防盗链 | 观看鉴权、URL 时效签名、动态水印 | 是否支持一次性票据？水印能否带上观看者身份信息？ |
| 弹幕与互动 | 聊天、点赞、问卷、投票、抽奖、连麦 | 消息并发上限是多少？有没有敏感词过滤与人工审核？ |
| 数据统计 | 并发曲线、地域运营商分布、观看时长、完课率、导出 | 数据粒度到什么级别？留存多久？能否导出或对接 BI 与 HR 系统？ |
| API 与 SDK | 与 OA、HR、CRM、自有 App 打通 | 推流、拉流、用户、数据接口是否齐全？有没有 Webhooks 与回调？详见直播 API |
| 运营后台 | 活动管理、子账号、多租户、权限分级、操作审计 | 能否按部门或子公司分权？关键操作是否有审计日志？ |
| 全球化（可选） | 海外节点、多语言、跨时区分发 | 海外节点覆盖哪些地区？跨境回传走什么链路？参见海外直播 |
直播是一次性的，没有"刷新重试"的机会，所以稳定性靠的是预案而不是运气。成熟的平台通常会在以下五个层面做冗余。
主路和备路同时推流，两条链路走不同运营商、不同物理路由，主路异常时服务端自动切换，切换时长控制在 1-10 秒，观众端尽量无感。推流端需支持指数退避自动重连，避免网络闪断后疯狂重试把链路打满；观众端在 3-15 秒内自动重连续播，而不是弹出错误提示后就不管了。
至少准备两家 CDN 互为备份，按地域、运营商、实时质量评分动态切换，切换应做到秒级生效。降级顺序建议提前写死：先降清晰度保流畅（自适应码率自动降档），再关非核心功能（弹幕、礼物、动效），最后才是排队等待页。任何情况下都用静态提示页兜底，绝不允许出现白屏。
监控要覆盖四层：推流端（码率、帧率、丢包率、CPU 占用）、服务端（转码健康、节点状态）、CDN（命中率、回源率、5xx 占比、慢速比）、播放端（首帧时间、卡顿率、错误码）。告警要分级到人，重大告警同时触达短信与值守群。流程上分三段：播前 checklist（网络、设备、备用链路、权限、完整彩排）、播中值守（指标看板 + 一键切备 + 一键断流）、播后复盘（并发曲线、卡顿分布、事故时间轴）。
基础手段有三类：Referer 黑白名单、IP 黑白名单、UA 限制，能挡住大部分直接引用；URL 鉴权（时间戳加密钥签名，到期自动失效，有效期通常设几分钟到几小时）才能真正防止地址被复制传播。企业级场景还要叠加登录态校验、手机号验证码、工号或组织架构校验，以及一次性票据，做到链接转发出去即刻失效。动态水印把观看者身份实时叠在画面上，既形成心理约束，也便于事后追溯。
合规做法是机审加人审：系统按固定间隔（常见 2-10 秒）抽帧截图，同时做语音转写与画面文字识别，模型初筛后由人工复核，命中违规立即告警或断流。互动区要有敏感词过滤与人工审核。内容涉及医疗、金融、教育等受监管行业的，建议采用先审后发或延迟播出策略。
按《互联网直播服务管理规定》，直播内容留存不少于 60 日，具体以主管部门最新要求为准。观看行为、鉴权日志、操作审计建议留存 6 个月以上，便于事后核查。等保合规层面的通用要求包括：身份鉴别、访问控制、安全审计、通信与数据传输加密（HTTPS/TLS、SRTP）、数据完整性与保密性、备份恢复、剩余信息保护；三级系统需按周期开展测评。
涉及个人信息收集（如手机号、人脸核验）时，应遵循最小必要与告知同意原则。若业务形态涉及互联网视听节目、网络表演、经营性互联网信息服务等，需按主管部门要求取得相应许可，具体以最新法规与属地监管口径为准，建议由法务或合规部门确认。这部分方案设计可与直达播技术团队沟通，微信 videotv888。
两者是包含关系，但关注点不同。直播平台泛指提供采集、编码、分发、播放能力的技术系统；企业直播平台在此基础上叠加了身份鉴权、观看数据回传、内容沉淀与合规留痕。简单判断：如果一个平台只能给你一个观看链接和一个总人数，它是通用直播平台；如果它能做白名单鉴权、导出每个人的观看时长、生成带水印的回放档案，才够得上企业级。选型时可先看场景再看技术。
Adobe 确实已停止维护 RTMP，但它在上行推流侧仍是事实标准，原因是生态太成熟：OBS、硬件编码器、导播台、手机推流 App 全部支持，服务端实现稳定，延迟 1-3 秒可控。它退出的只是播放侧——浏览器不再支持直接播 RTMP，服务端会转成 HLS 或 HTTP-FLV 再分发。所以现在的格局是 RTMP 管推、HLS 与 FLV 管拉、WebRTC 管互动。
HLS 把流切成小片段，播放器必须等一个片段完整生成并下载后才能播，默认缓存 3 个切片，切片时长 6 秒时延迟就有 18 秒。压到 2 秒有两条路：一是把切片缩短到 1-2 秒并减少缓存数量，代价是请求量成倍上升、弱网易卡顿；二是采用低延迟 HLS（部分片段传输），需要服务端与播放器同时支持。一般建议只在必要场景做低延迟。
按 4 Mbps 码率计算：单个观众 1 小时约消耗 1.8 GB，1 万人合计约 18 TB 流量。下行带宽方面，4 Mbps × 1 万 = 约 40 Gbps，这部分由 CDN 分布式承担，企业侧不需要自己准备。企业真正要保证的是上行：推流码率 4 Mbps 时，建议准备不低于 8 Mbps 的稳定上行链路，并留一条独立备用网络。可用带宽计算器按自身参数复核。
WebRTC 的设计目标是实时通信而非大规模分发。单台 SFU 服务器承载量取决于码率与机型，通常从几百到数千路不等，万人以上必须做 SFU 级联或转成 HLS/FLV 分发。因此常见做法是混合：需要连麦的少数人（一般 1-9 人）走 WebRTC，其余观众走低延迟 FLV 或 HLS。这样既保住互动体验，又不让成本失控。
按链路从后往前查。先看观众侧：是全网卡顿还是个别用户、个别地区、个别运营商卡顿，个别问题多为本地网络。再看播放端缓冲策略与解码方式，低端机软解常导致掉帧。然后看 CDN 指标：回源率是否过高、该地区节点是否健康。最后查上行：推流端码率是否稳定、丢包率与 CPU 占用是否异常。现场最常见的原因其实是上行带宽不足和 Wi-Fi 抖动。
最小可行团队约 5-8 人：音视频工程师负责编码参数与协议，后端负责流媒体服务、调度与鉴权，前端负责播放器与多端适配，SRE 负责节点与监控，测试负责压测。技术栈涉及流媒体服务器、编码与转码、CDN 或自建分发、播放器内核、监控体系。周期通常 3-9 个月。若没有专职音视频工程师，不建议走自建路线。
按《互联网直播服务管理规定》，直播内容留存不少于 60 日，具体以主管部门最新要求为准。此外建议留存观看行为与鉴权日志 6 个月以上，便于审计追溯。等保方面关注身份鉴别、访问控制、安全审计、传输加密、备份恢复等通用项。若业务涉及视听节目、网络表演或经营性信息服务，应按主管部门要求取得相应许可，由法务确认属地口径。
三层防护。第一层 URL 鉴权：播放地址带时间戳与密钥签名，到期失效，复制出去也播不了。第二层域名与 Referer 白名单：只允许自有域名嵌入播放器。第三层观看鉴权：登录态、验证码、一次性票据，配合带观看者身份的动态水印形成追溯能力。回放还要设置有效期与下载限制。涉密内容建议直接私有化部署。
并发指同一时刻正在拉流的连接数，与累计观看人次不同。估算方法：预估总观看人数 × 同时在线率（通知类活动 30%-60%，公开引流活动 10%-30%）× 峰值系数 1.2。例如预计 2 万人参加的内部大会，按 50% 同时在线再乘 1.2，峰值约 1.2 万并发。还要区分平均并发与峰值并发，采购与压测报备都应按峰值来，并预留一定余量。
两者是包含关系，但关注点不同。直播平台泛指提供采集、编码、分发、播放能力的技术系统；企业直播平台在此基础上叠加了身份鉴权、观看数据回传、内容沉淀与合规留痕。简单判断：如果一个平台只能给你一个观看链接和一个总人数，它是通用直播平台；如果它能做白名单鉴权、导出每个人的观看时长、生成带水印的回放档案，才够得上企业级。选型时可先看场景再看技术。
Adobe 确实已停止维护 RTMP，但它在上行推流侧仍是事实标准，原因是生态太成熟：OBS、硬件编码器、导播台、手机推流 App 全部支持，服务端实现稳定，延迟 1-3 秒可控。它退出的只是播放侧——浏览器不再支持直接播 RTMP，服务端会转成 HLS 或 HTTP-FLV 再分发。所以现在的格局是 RTMP 管推、HLS 与 FLV 管拉、WebRTC 管互动。
HLS 把流切成小片段，播放器必须等一个片段完整生成并下载后才能播，默认缓存 3 个切片，切片时长 6 秒时延迟就有 18 秒。压到 2 秒有两条路：一是把切片缩短到 1-2 秒并减少缓存数量，代价是请求量成倍上升、弱网易卡顿；二是采用低延迟 HLS（部分片段传输），需要服务端与播放器同时支持。一般建议只在必要场景做低延迟。
按 4 Mbps 码率计算：单个观众 1 小时约消耗 1.8 GB，1 万人合计约 18 TB 流量。下行带宽方面，4 Mbps × 1 万 = 约 40 Gbps，这部分由 CDN 分布式承担，企业侧不需要自己准备。企业真正要保证的是上行：推流码率 4 Mbps 时，建议准备不低于 8 Mbps 的稳定上行链路，并留一条独立备用网络。可用带宽计算器按自身参数复核。
WebRTC 的设计目标是实时通信而非大规模分发。单台 SFU 服务器承载量取决于码率与机型，通常从几百到数千路不等，万人以上必须做 SFU 级联或转成 HLS/FLV 分发。因此常见做法是混合：需要连麦的少数人（一般 1-9 人）走 WebRTC，其余观众走低延迟 FLV 或 HLS。这样既保住互动体验，又不让成本失控。
按链路从后往前查。先看观众侧：是全网卡顿还是个别用户、个别地区、个别运营商卡顿，个别问题多为本地网络。再看播放端缓冲策略与解码方式，低端机软解常导致掉帧。然后看 CDN 指标：回源率是否过高、该地区节点是否健康。最后查上行：推流端码率是否稳定、丢包率与 CPU 占用是否异常。现场最常见的原因其实是上行带宽不足和 Wi-Fi 抖动。
最小可行团队约 5-8 人：音视频工程师负责编码参数与协议，后端负责流媒体服务、调度与鉴权，前端负责播放器与多端适配，SRE 负责节点与监控，测试负责压测。技术栈涉及流媒体服务器、编码与转码、CDN 或自建分发、播放器内核、监控体系。周期通常 3-9 个月。若没有专职音视频工程师，不建议走自建路线。
按《互联网直播服务管理规定》，直播内容留存不少于 60 日，具体以主管部门最新要求为准。此外建议留存观看行为与鉴权日志 6 个月以上，便于审计追溯。等保方面关注身份鉴别、访问控制、安全审计、传输加密、备份恢复等通用项。若业务涉及视听节目、网络表演或经营性信息服务，应按主管部门要求取得相应许可，由法务确认属地口径。
三层防护。第一层 URL 鉴权：播放地址带时间戳与密钥签名，到期失效，复制出去也播不了。第二层域名与 Referer 白名单：只允许自有域名嵌入播放器。第三层观看鉴权：登录态、验证码、一次性票据，配合带观看者身份的动态水印形成追溯能力。回放还要设置有效期与下载限制。涉密内容建议直接私有化部署。
并发指同一时刻正在拉流的连接数，与累计观看人次不同。估算方法：预估总观看人数 × 同时在线率（通知类活动 30%-60%，公开引流活动 10%-30%）× 峰值系数 1.2。例如预计 2 万人参加的内部大会，按 50% 同时在线再乘 1.2，峰值约 1.2 万并发。还要区分平均并发与峰值并发，采购与压测报备都应按峰值来，并预留一定余量。