01 — LIVE GLOSSARY
直播术语说明
不要背定义。点开一个名词，看它在画面里“动起来”，再用生活中的东西把它记住。
遇到陌生格式，先问三句话：它是在压缩数据、组织数据，还是传输数据？这能解决大多数“它们有什么区别”的困惑。
STAGE 01先懂术语，再看信号怎么跑
一帧画面，
究竟经历了什么？
这一阶段只解决四件事：直播术语怎么分、直播链路怎么走、码率为什么影响清晰度，以及 GOP 为什么决定卡顿恢复速度。
TIME / 建议 35 分钟
LIVE00:01:28
1080P30 FPS4.2 MbpsH.264
NALU 7F A2
PTS 90090
02 — SIGNAL CHAIN
直播链路的建立
主播的声音和画面不会“直接传给观众”。它们要先变成可传输的数据，再由服务器分发。
现实信号光线 + 声波
→
数字媒体视频帧 + 音频采样
→
网络数据压缩包 + 时间戳
知识讲解 · 跟我走一遍01 / 07
动手实验 1
0 / 7
重建一条直播链路
依次点击下方模块，把它们放进正确的信号链。想一想：是先编码，还是先推流？
主播端采集 → 编码 → 封装
把原始画面变小，并装进便于连续传输的数据结构。
服务端接入 → 处理 → 分发
接住流，按需转码、录制，再送往离观众更近的节点。
观众端拉流 → 解封装 → 解码
把网络数据还原成屏幕上的像素和扬声器里的声音。
03 — THREE LAYERS
编码、封装、协议，别再混了
记住一句话：编码负责压小，封装负责装好，协议负责送到。
把羽绒被压缩
H.264 / H.265 / AAC / Opus
把物品装进箱子
FLV / MPEG-TS / MP4
选择运输路线
RTMP / HLS / WebRTC / SRT
动手实验 3
0 / 9
把技术名词送回它的家
先点一个名词，再点它所属的分类。
04 — BITRATE LAB
清晰度，不只看分辨率
码率是“每秒能用多少数据描述画面”。同样 1080P，演唱会比静态访谈需要更高码率，因为每一帧变化更多。
知识讲解
三个旋钮，分别控制什么？
分辨率：一张图有多少格
1080P 是 1920×1080 个像素。格子越多，能表现的细节上限越高，每帧要处理的数据也越多。
帧率：每秒翻多少张图
30 FPS 就是每秒 30 帧。帧率主要影响运动流畅度，不会直接让一张静止画面变得更精细。
码率：每秒给多少信息预算
码率是编码后的数据预算。画面越复杂、分辨率和帧率越高，通常越需要更大的预算。
为什么必须编码？
一秒未压缩的 1080P、30 FPS、RGB 视频大约是：
1920 × 1080 × 24 bit × 30 ≈ 1.49 Gbps普通网络几乎扛不住。H.264 会利用“画面内部相似”和“相邻帧相似”把它压到几 Mbps。
建议起始码率
4.2 Mbps
建议主播上行至少6.3 Mbps按码率 × 1.5 留出抖动余量
1080P 访谈画面变化不大，4 Mbps 左右通常是合理起点。
高分辨率 + 低码率 ≠ 高清。像素格子更多，但每个格子分到的信息更少，运动时反而更容易出现马赛克。
05 — GOP VISUALIZER
为什么丢一个包，会糊半天？
I 帧是一张完整图片；P/B 帧只记录“和前后帧的差异”。播放器丢失关键参考后，往往要等下一个 I 帧才能完全恢复。
先记住这张图
I 帧像完整底图，P/B 帧像一叠“修改说明”；下面的动画继续演示丢失参考帧后会发生什么。
I
关键帧 · 完整底图
自己就能解码，不依赖前面的画面。播放器通常从它开始起播和恢复。
P
预测帧 · 修改说明
参考之前的 I/P 帧，只保存“哪里变了”，体积明显更小。
B
双向预测帧 · 更省空间
可同时参考前后画面，压缩效率高，但会让解码顺序与展示顺序不同。
老师小结
如果 30 FPS 下每 60 帧放一个 I 帧，关键帧间隔就是 60 ÷ 30 = 2 秒。丢失重要参考后，最坏可能要接近 2 秒才遇到下一张完整底图。
关键帧间隔约 2 秒
随机丢包后的最坏恢复≤ 2 秒
GOP 越短，恢复越快、起播更容易，但 I 帧多会增加码率。
STAGE 01 · CHECKPOINT
第一阶段，验收信号
15 题全对即可点亮阶段徽章。
STAGE 02主播视角 · 一场媒体旅行
跟着一帧画面，
去服务器旅行。
你是主播。按下开播后，一个由画面和声音组成的“小流”从桌前出发：领路线票、进 FFmpeg 工厂、装进 FLV 货柜、穿过 RTMP 隧道，最后抵达 SRS 中央站。
TIME / 建议 45 分钟
01 — DEPARTURE
先站到主播桌前，再按下开播
上传文件是“货物准备完再发车”；直播则是镜头还在拍，前面的画面已经离开桌面。我们不从协议定义开始，而是跟着这一帧画面一路往下走。
今天的三位向导
FFmpeg 是加工厂，RTMP 是连续运输规则，SRS 是中央车站。记住角色关系，后面的命令和术语自然会找到位置。
8 秒旅行预告
先看小流会经过哪里
这段短片只负责建立整条链路的空间感。看完后，再逐站进入真实参数、协议步骤和故障证据。
知识讲解 · 一站一站旅行
01 / 07跟着媒体旅行者，把术语放回真实链路
沿途会反复遇见的三个角色
工具、协议和服务器各司其职，别把它们混成一个“推流软件”。
FFMPEG媒体加工工具
读输入、调参数、编码、封装，并把连续数据送往输出地址。
RTMP实时传输协议
规定客户端如何连接、发布，以及音视频消息如何在长连接里传输。
SRS流媒体服务器
监听端口、接入直播流、鉴权、录制，并向下游做一对多分发。
02 — ROUTE PASS
第二站：给小流领取一张路线票
主播通常先从直播后台拿到推流地址和密钥，再填进工具。它同时回答五个问题：走什么规则、去哪里、进哪个应用、发布哪一路、带什么通行证。
地址闸机一层层缩小目的地
先确认交通规则和服务器入口，再进入业务楼层，最后凭流名与 token 到达具体房间。
rtmp://live.example.com:1935/live/room-001?token=••••
过站任务 1
不会发起真实请求亲手填好小流的 RTMP 路线票
服务器最终收到的地址
同一个 APP / STREAM，可映射为播放地址
推流和播放协议可以不同，但 live / demo 这对业务坐标保持一致。
HTTP-FLV 示例
HLS 示例
这里只演示地址映射；相应播放地址是否可用，取决于 SRS 是否启用了对应输出能力。
03 — MEDIA FACTORY
第三站：走进 FFmpeg 媒体工厂
站在主播侧看，FFmpeg 就是接受摄像头、麦克风、屏幕或文件的加工厂。命令是工厂订单：从左向右规定原料、加工规格、装箱方式和出口。
视频与音频走不同工位，再在出口会合
视频被调整尺寸、帧率和码率，音频被采样与压缩；工厂必须始终跟上直播的实时节奏。
01 · 输入节奏
-re -i demo.mp4-re 让文件按原始速度读取；没有它，文件可能被尽快推完，不再像直播。
02 · 视频加工
-c:v libx264 -b:v 2500k选择 H.264 编码器并设置视频码率目标。画质和上行压力都从这里开始变化。
03 · 音频加工
-c:a aac -b:a 128k把音频编码成兼容性较好的 AAC，并给它每秒 128 kb 的信息预算。
04 · 封装与出口
-f flv rtmp://…将音视频组织成 FLV，再通过 RTMP 地址持续送往服务器。
编码是把货物压小，封装是把货物按时间装好
橙色视频块和蓝色音频块不会随便混在一起。封装器依据 PTS/DTS 把它们交错放进 FLV Tag；它不再次提高画质，也不负责网络运输。
过站任务 2
命令模拟器给 FFmpeg 工厂填写一张加工单
等待启动模拟推流…
编码压力估算 45%
受分辨率、帧率和 preset 影响
上行预算占用 60%
按 10 Mbps 稳定上行预算估算
命令能运行，不代表参数合理。稳定推流要同时满足：编码速度 ≥ 实时速度、输出码率低于稳定上行、服务器接受地址与鉴权。
04 — RTMP TUNNEL
第四站：穿过五道 RTMP 关卡
小流离开工厂后，并不能直接冲进服务器。“连接成功”和“推流成功”不是同一刻：TCP、握手、connect、createStream、publish 必须按顺序放行。
走到哪一关，就是最有用的故障坐标
第一关都进不去就查网络；最后 publish 才被拦下，则应查流名、鉴权或重复发布。
01 / 05
05 — CENTRAL STATION
第五站：抵达 SRS 中央站
小流完成 publish 后，终于成为服务器中的直播源。SRS 校验发布者、维护这一路输入，再按配置送去播放、录制或 CDN；主播不用给每位观众各上传一份。
一进多出，是中央站最重要的能力
左边只有主播的一路上行；右边的播放、转协议、录制和分发出口都由服务端承担。
知识讲解 · 本地教学配置
先读懂五行，再启动服务
点击配置行查看作用。这里讲的是配置语义，不会连接或修改任何生产环境。
过站任务 3
一对多分发替小流打开不同的分发站台
主播上行RTMP / live / demo
接入服务器SRS
网页播放交给下游播放协议
录制存档保存为文件或切片
CDN 转发扩大观众覆盖
接入前监听与路由
确认 1935 监听、vhost、app 与 stream 路径匹配。
发布时鉴权与占用
校验 token、过期时间，并阻止同一流名被意外重复发布。
运行中带宽与日志
观察输入帧率、客户端数、队列、带宽和录制错误。
06 — REPAIR WORKSHOP
终点之后：进入链路维修间
旅行途中真的出故障，不要把每个参数都拧一遍。错误日志是小流留下的路标：先判断它停在采集、加工、装箱、运输还是中央站，再做最小范围验证。
先沿旅行地图找到断点，再拿工具
连接拒绝、publish 被拒、发送队列溢出、时间戳倒退，分别来自不同站点，不能用同一个办法修。
采集→编码→封装/时间戳→TCP/RTMP→SRS
维修任务 4
0 / 4四起旅行事故，选择第一检查动作
通用排障顺序：先验证“输入有没有”，再看“编码跟不跟得上”，然后检查“地址能不能连、publish 是否通过”，最后观察长时间发送是否稳定。
STAGE 02 · CHECKPOINT
第二阶段，旅行通关验收
15 题全对，证明你能从主播桌前一路解释到 SRS 中央站。
地址协议 + 主机端口 + APP + STREAM
能说清每一段，才知道连接和发布分别查哪里。
命令输入 → 编码 → 封装 → 输出
能解释参数作用，比背下一整行命令更重要。
排障先定故障层，再改参数
TCP、publish、发送队列和时间戳对应不同方向。
STAGE 03观众视角 · 一场播放旅行
点下播放，
去屏幕里旅行。
你是观众。按下播放后，小流通常不会从遥远源站直接赶来：它先经过 CDN 边缘节点，也可能由附近观众通过 P2P 协助分发，再进入缓冲、解封装、解码和同步放映厅。
TIME / 建议 65 分钟
01 — PLAYBACK JOURNEY
先坐到观众屏幕前，再按下播放
播放器不是一块被动显示器。它同时是路线查找员、网络接收员、缓冲管理员、拆箱师傅、解码机器和音画指挥家。
协议决定“怎么送”，播放器负责“怎么吃”
路线可以不同，但最终都要经过缓冲、拆轨、解码和渲染。
先记住低延迟的代价
离直播边缘越近，可用来抵抗网络抖动的数据越少。真正的低延迟，不是简单把缓冲改成 0。
8 秒播放旅行预告
先看小流怎样抵达屏幕
这段短片先建立空间感：拿到入口、选择路线、穿过缓冲与解码，最后由播放器把音画同步呈现。
知识讲解 · 一站一站旅行
01 / 06跟着媒体旅行者，把播放术语放回真实链路
三种协议，一眼分清
延迟数字不是固定承诺，会受配置、网络和播放器策略影响；先抓住它们的传输模型。
02 — HLS
HLS：清单带你一片片取
服务器把连续直播切成短媒体片段，并维护一份滚动清单。播放器反复刷新清单、下载新片、放进缓冲，再按顺序播放。
清单像取餐表，切片才是真正的媒体
播放器先拿 m3u8，再按里面的地址请求 TS 或 fMP4 切片。
知识讲解 · 读懂 M3U8
这不是视频文件，而是一张不断更新的路线表
动手实验 1
教学估算器切片越短，延迟就一定越低吗？
估算播放延迟
单观众切片请求频率
03 — HTTP-FLV
HTTP-FLV：打开一根不断流的管道
播放器只发起一次 HTTP 请求，服务器保持响应不断开，并持续送来一个个带类型和时间戳的 FLV Tag。网页端通常由 flv.js 拆 Tag、转成 fMP4，再通过 MSE 交给浏览器播放。
不是不断下载新文件，而是一个响应一直有新数据
HTTP 负责运输，FLV Tag 负责给数据分组贴标签；flv.js 转换包装后，MSE 才把媒体接进浏览器播放管线。
知识讲解 · 两个关键名词
先看懂包裹，再看懂浏览器的装货口
把整个 HTTP 响应想成一条不停前进的货运带：FLV Tag 是带标签的包裹，MSE 是 JavaScript 把媒体持续交给浏览器的标准装货口。
01
FLV TAG
FLV 数据流里的一个“带标签包裹”
一个 FLV 流先出现一次 FLV Header，后面紧跟许多个 Tag。每个 Tag 都用头部说明“我是什么、数据有多大、应该在什么时间播放”，再携带真正的数据。
TAG HEADER · 11 字节类型 8/9/18 · 长度 · Timestamp8 是音频，9 是视频，18 是脚本元数据
+
TAG DATA视频 / 音频 / 元数据例如 H.264 编码帧或 AAC 音频
别混淆：Tag 是 FLV 封装里的记录单元，不等于 TCP 数据包，也不一定等于一张完整视频画面。
02
MEDIA SOURCE EXTENSIONS
MSE 是浏览器提供的“可追加媒体入口”
MSE 是一组浏览器 API。JavaScript 可以创建 MediaSource 和 SourceBuffer，再用 appendBuffer() 连续追加浏览器能够消费的媒体片段。
FLV.JSfMP4 片段appendBuffer()MSESourceBuffer→HTML<video>
别混淆：MSE 不是解码器，也通常不直接认识 FLV；它管理追加的数据和播放缓冲，后面的浏览器媒体管线才负责解码、同步与渲染。
HTTP 长响应→FLV Header + Tag + Tag…→flv.js 拆 Tag、按时间戳分出音视频→重新封装为 fMP4→MSE SourceBuffer→video 解码播放
SERVER持续写 FLV Tag
→
FLV.JS拆 Tag + 转 fMP4
→
MSEappendBuffer()
→
VIDEO解码与渲染
动手实验 2
稳定与实时的跷跷板缓冲到底该留多少？
SRS
PLAYER
估算播放延迟
卡顿风险
HTTP-FLV 不是所有浏览器都原生支持。桌面网页常借助 MSE；Safari/iOS 等环境的支持边界要用真实设备验证。
04 — WEBRTC
WebRTC：先找一条能实时说话的路
WebRTC 不是拿一个 URL 就开始下载。双方要先交换能力，收集候选地址，进行连通性检查和安全握手，才能传输实时媒体。
能直连就走近路，走不通就让 TURN 中继
ICE 的目标是找到可用路径；TURN 是可靠兜底，也是需要计算带宽成本的中继。
动手实验 3
ICE PATH直连失败时，媒体去哪儿？
媒体服务
TURN
观众
当前路径
延迟直觉
带宽代价
05 — CDN & P2P DELIVERY
十万人看直播，不能让十万人都挤到源站门口
CDN 把内容提前送到离观众更近的边缘节点；P2P 再让部分观众贡献上传带宽，互相传递已经拿到的数据。它们解决的是“怎样把同一份直播大规模送出去”。
直播的原始出口。它负责向分发网络供给内容，不应该直接承受所有观众连接。
部署在不同地域和运营商附近，接住观众请求，减少跨地域距离并分散源站压力。
边缘已有数据叫命中；没有时才向上游取。回源过多会把压力重新推回源站。
调度器让观众之间交换已获得的数据。它通常补充 CDN，不是完全替代 CDN。
动手实验 4 · 分发调度台
以 4 Mbps HLS、98% CDN 命中率估算同样的观众规模，流量由谁承担？
ORIGIN源站低负载
EDGE A
EDGE B
EDGE C
观众 1观众 2观众 3观众 4观众 5观众 6
观众总下行
源站承担
CDN 边缘承担
观众互助承担
CDN、P2P 是分发方式；HLS、HTTP-FLV、WebRTC 是播放器取得媒体的方式，两者不是同一层概念。
HLS / LL-HLS切片可缓存，最适合传统 CDN；P2P 也常交换这些短切片。
HTTP-FLVCDN 可以代理长连接，但不像 HLS 切片那样依靠文件缓存复用。
WebRTC大规模观看通常依赖 SFU 或实时边缘网络；多人全互连 P2P 只适合很小规模。
P2P 不是免费 CDN。它受 NAT、终端上传能力、运营商网络、隐私与内容保护影响，必须有 CDN 兜底、调度控制和真实播放质量监控。
06 — PROTOCOL CHOICE
没有最强协议，只有最硬约束
先问是否双向互动，再看目标延迟、终端兼容、观看规模、CDN 和回看需求。不要因为“延迟低”就让所有场景都上 WebRTC。
第一问需要双向实时互动吗？
→需要：优先评估 WebRTC。
第二问需要大规模与广兼容吗？
→需要：优先评估 HLS。
第三问固定桌面且希望较低延迟？
可以评估 HTTP-FLV。
动手实验 5
0 / 6六个场景，替它们选播放协议
07 — PLAYBACK INCIDENTS
黑屏、卡顿、高延迟，先看第一条证据
把浏览器网络请求、控制台、缓冲长度和 WebRTC 状态放在一起，先判断“数据有没有到”，再追封装、解码和渲染。
地址/信令→网络请求→缓冲→解封装/解码→渲染
动手实验 6
0 / 4四起播放事故，选择第一检查动作
STAGE 03 · CHECKPOINT
第三阶段，播放验收
15 题全对，证明你能把协议、CDN / P2P 分发、缓冲和排障串起来。
HLS清单 + 切片
规模与兼容优先，延迟来自切片和缓冲的累积。
HTTP-FLV长响应 + MSE
桌面网页较低延迟，重点管住连续缓冲。
WebRTCICE + 加密实时媒体
互动优先，难点在选路、中继和网络质量。
分发CDN 边缘 + P2P 协同
CDN 承担稳定与兜底，P2P 在合适环境中分担部分流量。
STAGE 04直播急诊室 · 一场故障会诊
直播卡顿，
先别乱开药。
“卡”不是病名。跟着媒体旅行者进入直播急诊室：先把症状翻译清楚，再确认影响范围、找到第一条异常证据，最后用最小实验完成会诊。
TIME / 建议 60 分钟
01 — TRIAGE JOURNEY
先分诊，再拿工具
优秀的排障不是记住更多命令，而是用最少证据缩小范围。先问“谁、何时、哪种症状”，再决定看哪一层。
一句“卡了”要先拆成可以验证的症状
黑屏、首开慢、卡顿、高延迟和音画不同步，会走向不同的证据链。
急诊室第一条规则
先确认影响范围，再看第一条异常证据；不要看到 CPU 高就立刻宣布它是根因。
8 秒急诊室预告
先看一场故障怎样被接诊
媒体旅行者会经过症状挂号、延迟检查、缓冲监护、指标读片和音画校准，最后锁定真正的断点。
知识讲解 · 六步会诊
01 / 06跟着媒体旅行者，把“卡”变成可验证的结论
02 — LATENCY BUDGET
直播延迟从哪儿来？每个环节都会增加一点
从主播采集画面到观众看到直播，采集、编码、网络传输、播放缓冲和解码渲染都会消耗时间。把这些耗时加起来，就是最终的端到端延迟。
每一道闸门都拿走一点时间
端到端延迟要按链路拆预算，再优先处理最大且可控的部分。
动手实验 1
教学估算器给五个环节分配延迟预算
端到端估算
分诊灯
03 — STUTTER MONITOR
卡顿：缓冲水库为什么突然见底
网络送货忽快忽慢、连续丢包和设备解码过载都能让画面卡，但它们留下的指标形状不一样。
先分清“没送到”还是“来不及吃”
缓冲见底更像供给问题；数据充足但掉帧上涨，更像解码和渲染压力。
动手实验 2
BUFFER ECG切换病因，观察同一个播放器怎样反应
安全水位
DECODER
流畅
故障发生在链路正常
包裹均匀送到，缓冲仓库保持水位，解码工位也能及时处理。
到达节奏
卡顿风险
掉帧观察
04 — METRIC READING
指标不是答案，是一张张检查片
把输入 FPS、队列、丢包、缓冲、掉帧和音画差放到同一时间轴，才能看出故障从哪里开始传播。
先看形状和先后，再解释数值
阈值会因业务而变；持续上涨、同步突变和范围差异通常比孤立数字更有意义。
知识讲解 · 指标挂号单
点开六张检查片，学习它们能证明什么
相关不等于因果。CPU 和卡顿同时升高，只说明值得进一步验证；还需要找到处理速度、队列或掉帧等中间证据。
05 — A/V SYNC
音画不同步：让嘴型和声音回到同一拍
播放器按时间戳安排音视频登场。固定偏差可以补偿验证，持续漂移则要回到 PTS 和时钟源。
不是让两条轨道同时收到，而是让它们按 PTS 同时呈现
网络到达时间、解码完成时间和最终播放时间是三件不同的事。
动手实验 3
SYNC CALIBRATION模拟播放器的音画同步模块，根据 PTS 调整播放时间
你扮演播放器的音画同步模块
→
你要做比较音视频 PTS，判断谁先谁后
→
完成目标调整音频播放偏移，让嘴型和声音对齐
VIDEOAUDIO
校正后音画差
会诊判断
06 — INCIDENT WAR ROOM
五份病历，找到第一条异常证据
每份病历都有很多数字，但只有少数能解释症状。先用影响范围缩小链路，再选择第一检查动作。
先隔离第一处异常，再追上下游
修复动作必须能解释症状、范围和证据，而不是碰巧让红灯熄灭。
采集→编码→发布/分发→网络→播放器→渲染/同步
动手实验 4
0 / 5五起直播急诊，选择第一检查动作
STAGE 04 · CHECKPOINT
第四阶段，急诊出科考试
15 题全对，证明你能把症状、指标和第一检查动作连成一条证据链。
分诊症状 + 范围 + 时间
先把“卡”翻译成可验证的诊断输入。
证据指标 + 日志 + 协议事实
对齐时间线，寻找第一处异常和传播顺序。
闭环实验 + 验证 + 预防
恢复不等于根因，复盘要留下长期修复。
STAGE 05直播架构总装厂 · 最终阶段
把前四阶段，
装成一套系统。
这一次你不再只盯一帧画面，而是担任直播架构师：决定怎样接入、转码、封装、分发、容灾和观测，并亲手把主播登录、OBS 推流一路接到观众屏幕。
TIME / 建议 85 分钟
01主播
→
02媒体核心
→
03多档转码
→
04CDN / P2P
→
05观众
OBSERVABILITY ONLINE
01 — ARCHITECTURE BLUEPRINT
先画数据怎么走，再决定机器放哪里
生产架构不是把热门组件堆在一起。每一层都要回答：输入是什么、输出是什么、容量边界在哪里、失败后由谁接替。
数据面真正搬运音视频
+
采集、编码、封装、源站、CDN、P2P 和播放器。
控制面决定数据往哪里走
+
鉴权、调度、配置、流量切换和发布管理。
观测面证明每一层是否健康
指标、日志、追踪、QoE、告警和成本。
知识讲解 · 架构六站
01 / 06跟着一场直播，从入口走到观众屏幕
02 — ABR LADDER
一条高清源流，为什么要变成多档画质
观众的屏幕和网络不同。转码梯子把同一内容生产成多种分辨率和码率，播放器才能根据实时带宽切换，而不是让所有人硬扛最高档。
输入1080p 源流
→
保留一份高质量主源。
转码1080 / 720 / 480 / 360
→
每档都要消耗计算资源。
ABR 播放播放器按网络切换
目标是少卡顿，不是永远最高画质。
动手实验 1
点击档位启用或停用搭一架能覆盖不同网络的转码梯子
启用档位
聚合输出码率
网络覆盖
多一档不是免费。它会增加转码计算、存储/封装对象、CDN 流量组合和监控维度；档位要由真实终端与网络分布决定。
03 — DELIVERY ORCHESTRATION
CDN 是主干，P2P 是协助，多路分发要能随时切换
单一出口简单，但故障面大。生产系统会在 CDN A、CDN B 和 P2P 之间调度流量，并为节点故障、区域异常和 P2P 不可用准备回退路径。
动手实验 2 · 分发控制台
所有百分比均指观众下行分配正常流量，再拔掉一条路
ORIGIN SHIELD回源保护层
→
CDN ACDN BP2P
→
观众
CDN A
CDN B
P2P
04 — CAPACITY & COST
先算峰值流量，再谈机器和预算
并发人数只是起点。平均码率、峰值系数、观看时长、CDN 命中率和 P2P 分担共同决定出口带宽、每小时数据量和回源压力。
动手实验 3 · 容量估算器
教学估算，忽略协议开销把一场直播的规模换算成真实流量
峰值观众下行
每小时数据量
估算回源
05 — RESILIENCE & OBSERVABILITY
高可用不是“不会坏”，而是坏了仍知道该走哪条路
冗余必须和故障检测、自动切换、验证与回滚成套出现。没有观测的双机，可能只是两台同时出问题却没人知道的机器。
发布在线流数 / 建连成功率
证明主播是否真正进入系统。
处理编码 FPS / 队列 / 错误率
证明媒体核心是否跟得上。
分发命中率 / 回源 / 边缘错误
证明内容是否稳定送到各地。
体验首开 / 卡顿 / 延迟 / 掉帧
证明观众是否真的看得好。
动手实验 4 · 故障演练
0 / 5先配置保护，再注入一次故障
06 — BUILD A REAL LIVE CHAIN
亲手把一场直播，从登录接到观众屏幕
前面学的是零件，这里要把零件按真实先后接起来。每一站都要说清输入、动作、输出和验证证据；选对后才能接通下一段。
先说清 OBS 与 FFmpeg 的真实关系
OBS 自己就能完成采集、合成、编码、封装和推流，并会使用 FFmpeg 相关组件；复杂业务也可能额外接独立 FFmpeg 进程做滤镜、转码或中继。教学链路会经过“媒体加工”这一站，但不把外部 FFmpeg 说成所有直播的强制步骤。
01 · 平台控制面登录 → 创建场次 → 发放推流凭据
→
先确认谁在开播，以及这条流属于哪一场直播。
02 · 主播媒体面OBS → 加工 → 编码 → 封装 → RTMP
→
把摄像头和声音变成带时间戳的可传输码流。
03 · 服务与分发Ingest → ABR → HLS → Origin → CDN / P2P
→
把一路上行生产成可供十万观众获取的播放产品。
04 · 观众播放器请求 → 缓冲 → Demux → Decode → PTS 同步
把媒体还原成按正确时间出现的画面和声音，并回传 QoE。
动手实验 5 · 端到端接线台
00 / 17 已接通逐站选择正确动作，把信号送到观众屏幕
07 — ARCHITECTURE CAPSTONE
五张需求单，选择最合适的直播架构
没有一套架构同时做到最低延迟、最低成本、最大规模和最简单运维。先抓业务硬约束，再为失败路径付必要的复杂度。
最终架构挑战
0 / 5不要选最豪华的，选择能解释需求的
STAGE 05 · FINAL CHECKPOINT
最终阶段，架构交付考试
15 题全对，证明你能从一条源流推导出转码、分发、容量、容灾和观测方案。
媒体接入 + 转码 + 封装
让源流变成不同终端可以消费的产品。
分发CDN + P2P + 回源保护
让规模增长时源站仍保持可控。
可靠性冗余 + 切换 + 观测
让故障可发现、可绕行、可验证。
决策体验 + 容量 + 成本
用业务约束选择复杂度，而不是堆组件。