首页流式媒体与点播是两种核心媒体分发模式。流式媒体强调实时生成、连续传输与即时播放，对延迟、缓存控制和同步要求极高，适用于直播、实时通信。点播则面向预存储内容按需播放，注重播放稳定性与画质，依赖缓存与完整数据传输。两者在实时性、缓存策略、同步机制及传输容错方面存在系统差异。
一、流式媒体 vs 点播
流式媒体（Streaming Media） 是指媒体内容在生成或分段产生的同时，通过网络连续传输并即时播放的媒体分发方式，用户无需等待完整文件下载完成即可开始消费内容。典型形态包括直播、实时音视频通话、互动直播、云游戏画面流等，其核心特征是“边传边播”，内容具有强时序性和时效性。
点播（Video on Demand, VOD） 则是指媒体内容在传输前已经完整生成并存储在服务器或 CDN 上，用户在任意时间发起请求后按需获取并播放内容。点播强调内容的可重复消费和高稳定性，典型场景包括长视频平台、短视频回放、课程录播等。
二、对实时性与延迟的要求差异
流式媒体对实时性要求极高，尤其是实时通信和直播互动场景，系统设计通常遵循“低延迟优先”的原则。音视频数据需要尽可能接近真实发生时间被播放，端到端延迟往往要求控制在几十毫秒到几百毫秒以内，一旦延迟过高，就会直接影响互动、对话和沉浸体验。因此，流式媒体通常采用 UDP 传输、放弃强可靠性、减少重传，并依赖丢包容错、预测和补偿机制来保证连续播放。
点播场景对实时性的要求相对较低，延迟主要体现在“起播时间”而非“播放时延”。用户更关注点击播放后多久能开始观看，而不要求内容与现实时间同步。系统可以通过预加载、分段下载和缓存来换取更高的稳定性和画质，允许在网络不佳时适当等待数据到齐再播放。
三、缓存与缓冲策略的不同
在流式媒体中，缓存通常被严格限制在较小范围内，以避免引入额外播放延迟。播放器通常只维持一个较短的缓冲区，用于吸收网络抖动和瞬时带宽波动，一旦缓存过大，就会直接转化为端到端延迟。因此，流式媒体系统更强调动态缓冲、抖动缓冲（Jitter Buffer）和快速丢包补偿，而不是长时间缓存。
点播系统则高度依赖缓存机制。播放器通常会提前下载多个分片，形成较大的播放缓冲区，以保证播放过程的连续性。点播平台还会广泛使用 CDN 缓存、边缘缓存和本地缓存技术，将内容尽量提前放置在离用户更近的位置，从而减少卡顿、提升画质稳定性，并降低源站压力。
四、同步要求的差异
流式媒体对同步要求更加严格，尤其是在实时音视频场景中，需要同时保证音频与视频之间的同步（A/V Sync），以及多方通话或多路流之间的时间一致性。此外，在直播或互动场景中，还可能涉及主播端、观众端和互动用户之间的时钟对齐与播放进度同步，一旦同步偏差过大，就会导致“对不上话”“画音不同步”等问题。
点播场景中的同步要求相对宽松。虽然同样需要保证音视频在播放端的同步，但由于内容是预先制作好的，系统可以通过时间戳、索引文件等方式进行精确控制，不涉及多端实时对齐的问题。即便不同用户之间播放进度不一致，也不会影响各自的观看体验。
五、传输与容错机制侧重点
流式媒体更倾向于使用低延迟传输协议和实时容错机制，例如 UDP、RTP、QUIC 等，并结合自适应码率、丢包容错（PLC）、前向纠错（FEC）等技术来应对不稳定网络。在这里，“播放不中断”通常比“数据完全正确”更重要。
点播系统则更强调数据完整性和播放质量，通常采用基于 TCP 的传输方式，允许重传和校验错误。即使出现丢包，也可以通过重传恢复完整数据，从而保证画质和音质的稳定性。
参考
《Understanding VOD vs live streaming》https://www.fastpix.io/blog/understanding-vod-vs-live-streaming
《视频点播 | 应用程序安全性和性能》https://aws.amazon.com/cn/developer/application-security-performance/articles/video-on-demand
