首页直播强调内容的实时生成、分发与播放，对端到端延迟要求极高，使用UDP等协议与小缓冲区以保证低时延，并借助PLC、FEC等技术应对丢包。回放（VOD）则基于预存内容按需播放，侧重播放稳定性与数据完整性，依赖TCP传输与缓存机制。两者在实时性、缓存策略、同步要求及传输容错等方面存在显著差异。
一、直播（Live Streaming） vs 回放（Replay / VOD）
直播是一种内容在产生的同时被分发和消费的媒体形态，内容与现实时间强绑定，具有显著的时效性和不可逆性。其媒体分发模式以“边生成、边传输、边播放”为特征，系统设计的首要目标是尽可能缩短内容产生到用户播放之间的端到端延迟。
回放则是一种基于已录制并存储完成内容的按需消费模式，内容在播放前已经准备就绪，用户可以在任意时间点开始观看，并自由控制播放进度。
直播与现实时间强绑定，核心目标是让用户尽可能“接近正在发生的内容”。因此直播系统对实时性要求极高，哪怕只有几秒甚至更小量级的延迟，也可能影响临场感和互动体验。在系统设计中，实时性通常被置于画质、完整性之上。相比之下，回放并不要求内容与现实时间同步，用户消费的是已经生成的历史内容，只要播放过程本身连续稳定，即使存在较长的时间差也不会影响体验，因此对实时性的要求明显较低。
二、延迟关注点的差异
在直播场景中，延迟主要指端到端延迟，即从内容产生、编码、传输到最终播放的整体时延，这是衡量直播体验的关键指标之一。延迟过高会直接削弱互动性，甚至导致用户之间的体验不同步。回放场景中的延迟则更多体现在起播延迟，也就是用户点击播放后等待视频开始的时间。一旦播放开始，后续播放延迟通常不会被用户明显感知，系统可以通过预加载和缓冲来进一步降低卡顿风险。
三、缓存与缓冲策略的差异
为了控制延迟，直播系统通常采用较小的缓冲区，仅用于吸收网络抖动和瞬时带宽波动，避免缓存累积转化为播放延迟。直播中的缓存更多是一种“临时缓冲”，而非长期存储手段。回放系统则高度依赖缓存机制，播放器和 CDN 通常会提前缓存多个媒体分片，形成较大的播放缓冲区，即使网络质量短时间下降，也能依靠缓存维持平滑播放，从而提升整体稳定性和画质一致性。
四、同步要求的差异
直播对同步性的要求更为严格，不仅需要保证单一终端内音频与视频的同步，还需要在一定程度上保持不同观众之间播放进度的相对一致，以支持互动、弹幕和连麦等功能。这使得直播系统需要进行更精细的时间戳管理和时序控制。回放则主要关注本地播放的音视频同步，不涉及多用户之间的时间对齐问题，每个用户可以独立控制播放进度，同步管理的复杂度相对较低。
五、传输与容错机制侧重点
| 维度 | 直播（Live） | 回放（Playback / On-Demand） |
|---|---|---|
| 核心目标 | 低时延、不中断 | 内容完整、体验稳定 |
| 实时性要求 | 极高，延迟直接影响内容价值 | 较低，可容忍加载等待 |
| 主要传输协议 | UDP / QUIC / WebRTC | HTTP over TCP（HLS、DASH） |
| 缓存策略 | 极小缓存（毫秒～百毫秒级） | 秒级甚至更大的播放缓存 |
| 丢包处理方式 | 不等待重传，采用 PLC、跳帧、降码率 | 通过 TCP 重传或重新请求分片 |
| FEC 使用 | 常用，用冗余换低时延 | 较少使用，可靠性依赖重传 |
| 容错重点 | 感知层连续性与低延迟 | 数据层完整性与一致性 |
| 对抖动的容忍 | 低，需快速自适应 | 高，可通过缓存吸收 |
| 同步要求 | 强实时同步（音画、互动、连麦） | 时间戳精确同步，事后可校正 |
| 容错取向总结 | “宁可失真，也不断流” | “宁可等待，也不丢内容” |
参考：
《Live Streaming vs VOD: Technical Differences & Optimizations》https://www.cincopa.com/learn/live-streaming-vs-vod-technical-differences-and-optimizations
《RTMP/RTSP/WebRTC/SRT/HLS/DASH/GB28181/WebTransport/QUIC协议规范深度分析》https://blog.csdn.net/renhui1112/article/details/154175019?
《直播过程中影响延迟的因素以及优化方法》https://alienchang.github.io/post/直播过程中影响延迟的因素以及优化方法/
