视频点播 vs 视频直播：推流与拉流完全通俗指南
一、先搞懂最基础的两个词：推流 & 拉流
在视频业务里，"流"指的就是一段正在传输中的音视频数据。围绕这段数据，永远有两种角色：
- 推流（Push）：把音视频数据从本地送出去，发到服务器。方向是"本地 → 服务端"，主体是内容生产者（主播、摄像头、视频作者、转码服务）。
- 拉流（Pull）：从服务器上把音视频数据取回来播放。方向是"服务端 → 本地"，主体是内容消费者（观众、播放器、APP）。
一句最直观的类比：推流是"上传/发送"，拉流是"下载/接收"——只不过在视频场景里，它们是边传边放的流式，而不是等整个文件下载完再看。
有了这个基础，"点播"和"直播"只是这两个动作被用在了不同的业务时机上。
二、点播场景中的推流和拉流
点播推流 ≈ 上传一个完整的视频文件
点播（VOD, Video On Demand）指的是内容早就录好了、放在服务器上，用户啥时候想看都行（爱奇艺追剧、B 站看番、抖音刷短视频、在线课程回放都属于点播）。
- 点播推流：创作者/机构把已经录制好、剪辑好的完整视频文件（MP4、MOV 等）上传到点播平台。严格意义上这更像"上传 + 转码"，行业里也常直接叫"上传"，但因为最终平台会把它转成可流式播放的切片，所以也被归入"推流"的广义概念。
- 重点：内容是预先存在的、完整的、有头有尾的。上传之后平台会做转码（转 H.264/H.265）、切片（切成 HLS 的
.ts或 DASH 的.m4s）、生成多码率版本（1080P/720P/480P），永久或长期存储在对象存储 + CDN 上。
点播拉流 ≈ 在线"边下边播"存好的视频
- 点播拉流：用户打开播放器，点"播放"，按需从 CDN 边缘节点流式地拉取视频分片回来解码、渲染。
- 重点：可以任意拖动进度条，因为整个视频已经存在服务器上，你想从哪一秒开始播，服务器都能立刻给你对应片段；可以暂停、续播、倍速、回看；同一个视频可以被成千上万人在不同时间点观看。
点播的端到端链路
[创作者本地]
│ ①录制/剪辑/编辑 (剪映、Pr、达芬奇)
▼
[点播平台上传接口]
│ ②上传/点播推流 (HTTP PUT / 分片上传 / 秒传)
▼
[转码集群]
│ ③转码 + 切片 + 多码率 (FFmpeg 集群)
▼
[对象存储 + CDN]
│ ④长期存储,按需分发 (OSS/S3 + 全球 CDN)
▼
[用户播放器]
│ ⑤点播拉流 (HLS/DASH,边拉边播,可 seek)
▼
[解码渲染上屏]三、直播场景中的推流和拉流
直播推流 ≈ 实时把现场画面往服务器上怼
直播（Live）是边产生、边传输、边观看的——内容在这一刻正在发生（游戏直播、带货直播、体育赛事、演唱会在线转播、视频会议）。
- 直播推流：主播端的摄像头/采集卡/OBS 一边采集、一边编码、一边把音视频流实时发送到直播服务器。传输协议最常见的是 RTMP（国内最主流）、SRT（专业场景）、WebRTC/WHIP（低延迟互动）。
- 重点：流是持续的、没有终点的（直播结束才结束），不允许回退（主播只能往前推当前时刻的画面）。
直播拉流 ≈ 实时接收正在发生的画面
- 直播拉流：观众的播放器从 CDN 边缘节点持续不断地拉取当前正在发生的画面。协议通常是 HTTP-FLV / HLS / LL-HLS / WebRTC。
- 重点：默认只能看"现在"，不能 seek 到"五分钟前"（除非平台做了"直播回看 / 时移 / 回放"功能，那本质上是把直播流录下来转成点播了）；所有观众看到的画面几乎是同一时刻（只差 CDN 传输和缓冲的那几秒延迟）。
直播的端到端链路
[采集设备]
│ ①摄像头/麦克风/屏幕录制 (手机/单反/OBS/采集卡)
▼
[本地编码]
│ ②实时编码 H.264/H.265 + AAC (硬编码/软编码)
▼
[直播推流]
│ ③RTMP/SRT/WHIP 推到源站 (rtmp://push.xx.com/live/streamKey)
▼
[直播源站]
│ ④鉴权、录制、转码多码率、审核
▼
[CDN 边缘节点]
│ ⑤全球分发,就近服务
▼
[观众拉流]
│ ⑥HTTP-FLV/HLS/WebRTC 持续拉取
▼
[解码渲染上屏] —— 相对主播有 1s~30s 延迟四、点播 vs 直播：关键差异对比
| 对比维度 | 点播（VOD） | 直播（Live） |
|---|---|---|
| 是否实时 | 否，内容早已录好 | 是，边产生边消费 |
| 延迟 | 不存在"延迟"概念，想看就看；首屏一般 < 1s | 主播 → 观众有 1–30s 延迟（看协议） |
| 是否可提前编辑/剪辑 | 可以，上传前自由剪辑、调色、加字幕 | 几乎不行，只能实时加水印/滤镜/美颜 |
| 进度条能否拖动 | 能任意 seek、倍速、回看 | 默认不能（需平台支持"时移/回看") |
| 服务器存储 | 长期存储在对象存储 + CDN，几年几十年都在 | 默认不存，或按需录制成 MP4/HLS 归档 |
| 内容长度 | 明确的开头和结尾 | 持续的、没有预设终点 |
| 推流主体 | 创作者、剪辑师、内容生产机构 | 主播、摄像机、赛事转播车、会议室设备 |
| 拉流主体 | 观众（可在不同时间分散观看） | 观众（大量集中在同一时间观看） |
| 常用推流协议 | HTTP PUT / 分片上传 / 断点续传 | RTMP（最通用）、SRT、WHIP/WebRTC |
| 常用拉流协议 | HLS、DASH、MP4 渐进式下载 | HTTP-FLV（低延迟）、HLS/LL-HLS、WebRTC（超低延迟） |
| 码率自适应 | 普遍支持（ABR，自动切 1080P/720P/480P） | 部分支持（HLS/DASH 直播） |
| CDN 缓存策略 | 长 TTL，命中率高，成本低 | 短 TTL 或不缓存，源站压力大，成本高 |
| 典型应用场景 | 电视剧/电影、短视频、课程回放、纪录片、企业培训、在线课件 | 游戏直播、带货直播、体育赛事、演唱会、发布会、视频会议、在线教育直播课、监控摄像头 |
| 转码时机 | 上传完后离线慢慢转（质量优先） | 实时转码（速度优先，常用 -preset ultrafast） |
| 失败代价 | 重试、断点续传即可 | 关键时刻卡顿/黑屏直接翻车，不可挽回 |
五、生活化比喻帮你秒懂
比喻一：网盘 vs 电话
- 点播 = 看网盘里早已上传好的视频 你周五下班打开网盘，看朋友上周发的旅游 vlog。视频早就躺在那儿了，你想几点看就几点看、想拖到哪一秒就哪一秒、想倍速就倍速，看完还在，下周你还能再看一遍。
- 直播 = 打一通视频电话 / 看一场演唱会现场 对方正在对着镜头说话、唱歌，你看到的是"此刻"。你不能让对方"倒回去再说一遍"，只能等他重复；你一挂断（主播下播），这通电话就结束了，默认不留痕迹（除非你主动录屏）。
比喻二：餐厅的两种供餐模式
- 点播 = 冰柜里的预制菜 厨师提前做好、包装好、冻进冰柜（上传 + 转码 + 存储）。顾客想吃哪个，从冰柜里拿出来微波加热（CDN 拉取 + 本地播放）。顾客 A 中午吃、顾客 B 晚上吃、顾客 C 下周吃，都吃得上，味道一模一样。
- 直播 = 铁板烧现场 厨师当场煎牛排（主播实时推流），顾客当场吃到（观众实时拉流）。你迟到 10 分钟，前面那块肉就错过了（除非店家录下来放给你看，那就变"点播"了）。
比喻三：推流 vs 拉流的方向感
- 推流 = 寄快递：你主动把包裹交给快递小哥（服务器），让他帮你送出去。
- 拉流 = 取外卖：外卖小哥（服务器）把餐放在柜子里，你自己去取。
在点播里：作者"寄了一次"（上传），观众反复"取"（拉流看视频）。 在直播里：主播"一直在寄"（持续推流），观众"一直在取"（持续拉流），直到主播下播。
六、一句话总结
推流和拉流只是方向相反的两端：谁往服务器送 = 推流，谁从服务器取 = 拉流。 点播和直播的差别只在"内容是提前录好还是此刻正在发生"：前者强调"随看随有、可回看"，后者强调"实时同步、别人正在看同一画面"。
选型时记住三条经验：
- 能离线剪的内容就做点播，对"当下"没强要求就别做直播——直播贵且容易翻车。
- 直播结束后若需要长期复用，把直播流录制归档转为点播是最经济的组合拳（大多数平台的"直播回放"就是这么做的）。
- 协议选型：点播首选 HLS/DASH（兼容性 + ABR），直播低延迟用 HTTP-FLV/WebRTC，强兼容用 HLS——这条你前面的文档里也已经沉淀过，可以直接对齐。