流媒体中的“协议”和“格式”有什么区别？

协议定义数据在网络中如何传输和控制，例如 RTMP、RTSP、HLS、WebRTC；格式定义音视频数据如何组织和封装，包括容器格式（如 FLV、MP4）和编码格式（如 H.264、AAC）。协议解决“怎么传”，格式解决“怎么装”。

为什么直播推流常用 RTMP，而分发端常用 HLS？

RTMP 基于 TCP，推流稳定、延迟较低，适合主播端推流；HLS 基于 HTTP，兼容性好、易接入 CDN，并支持多码率自适应，适合大规模分发。常见架构是“RTMP 推流 + 转码切片 + HLS/DASH 分发”。

超低延迟直播应该选 HTTP-FLV 还是 WebRTC？

互动连麦、视频会议、在线教育等点对点或强互动场景优先 WebRTC；大规模低延迟直播可考虑 HTTP-FLV，成本较低且易复用 HTTP/CDN 体系。WebRTC 延迟可做到亚秒级，但通常需要 STUN/TURN 等网络穿透与基础设施支持。

HLS 延迟较高，为什么点播和标准直播仍广泛使用？

HLS 的优势在于 HTTP 兼容性、CDN 友好、自适应码率和终端支持广。对于点播、标准直播分发和高并发场景，10–30 秒延迟通常可接受，因此 HLS 仍是平衡兼容性、成本和规模的重要方案。

流媒体协议与格式怎么选？RTSP/RTMP/HLS/HTTP-FLV/WebRTC对比指南

首页 / 技术服务 / 从RTSP到WebRTC：流媒体协议、格式与选型实战指南

在视频监控、直播电商、在线教育、视频会议和点播平台中，流媒体技术始终围绕两个核心问题展开：数据如何传输，以及音视频如何封装与编码。前者对应“协议”，后者对应“格式”。理解二者的区别，并结合延迟、兼容性、防火墙穿透和 CDN 成本进行选型，是构建流媒体系统的第一步。

一、协议与格式：先分清“怎么传”和“怎么装”

协议（Protocol）定义数据在网络中如何传输、控制和管理，例如 RTMP、RTSP、HLS、WebRTC。它决定连接建立、会话控制、数据传输方式和延迟表现。

格式（Format）定义音视频数据如何组织和封装，包括容器格式（如 FLV、MP4、TS）和编码格式（如 H.264、AAC、AV1）。它决定媒体数据如何被组织、存储和解码播放。

一句话理解：协议解决“怎么传”，格式解决“怎么装”。实际系统往往是“协议 + 容器 + 编码”的组合，例如 RTMP 推流、FLV 封装、H.264/AAC 编码，或 HLS 分发、TS 分片、多码率自适应。

二、五大主流协议速览

1. RTSP：实时流控制协议

RTSP 主要用于实时视频通信，如监控摄像头和视频会议系统。它本身不直接传输媒体数据，而是负责建立和控制媒体会话，实际数据通常通过 RTP/RTCP 传输。典型流程包括 DESCRIBE、SETUP、PLAY 等请求，服务器返回 SDP 描述媒体信息。

2. RTMP：直播推流的成熟选择

RTMP 是 Adobe 开发的实时消息协议，基于 TCP，提供稳定、较低延迟的连接，常用于直播推流。它支持 AMF 数据序列化，默认端口 1935，但可能被防火墙阻挡。尽管 Flash 已淘汰，RTMP 在推流端仍被 OBS 等工具广泛支持。

3. HLS：HTTP 自适应流媒体

HLS 由苹果提出，基于 HTTP，将流切分为 TS 分片，并通过 m3u8 播放列表组织。其优势是兼容性极佳、CDN 友好、支持多码率自适应；代价是延迟通常较高，常见为 10–30 秒。HLS 适合点播、标准直播分发和高并发场景。

4. FLV 与 HTTP-FLV：低延迟直播的实用方案

FLV 是一种容器格式，曾与 Flash Player 紧密绑定。浏览器原生支持弱化后，FLV 仍通过 HTTP-FLV 方案用于低延迟直播：服务端以 HTTP 长连接持续下发 FLV 流，客户端通过 JavaScript 解码播放。它延迟较低，但通常不自带自适应码率能力。

5. WebRTC：浏览器原生实时通信

WebRTC 是 W3C 标准，支持浏览器间无需插件的实时音视频通信。其核心包括 MediaStream、RTCPeerConnection 和 RTCDataChannel，通常使用 UDP 传输并结合 SRTP 保障安全。WebRTC 延迟可做到亚秒级，适合视频会议、互动直播和在线教育，但网络穿透通常需要 STUN/TURN 支持。

三、技术参数对比

特性	RTSP	RTMP	HLS	HTTP-FLV	WebRTC
延迟	非常低（<1秒）	低（2–5秒）	高（10–30秒）	低（2–5秒）	极低（<1秒）
协议基础	TCP/UDP + RTP	TCP	HTTP	HTTP	UDP + SRTP
浏览器支持	需插件	需Flash（已淘汰）	原生支持	需JavaScript解码	原生支持
防火墙穿透	差	差	优秀	优秀	一般（需STUN/TURN）
自适应码率	不支持	不支持	支持	不支持	有限支持
主要应用	监控、视频会议	直播推流	点播、直播分发	低延迟直播	实时通信、互动直播

四、应用场景选型指南

点播视频（如B站、YouTube）：推荐 HLS 或 MPEG-DASH，获得更好的自适应能力和兼容性。

标准直播（高并发、高兼容）：推流端使用 RTMP，分发端使用 HLS，平衡延迟、兼容性和 CDN 成本。

超低延迟直播（电商带货、互动直播）：可考虑 HTTP-FLV 或 WebRTC，实现秒级甚至亚秒级延迟。

实时通信（视频会议、在线教育）：首选 WebRTC，专为低延迟点对点通信设计。

安防监控：传统领域仍以 RTSP 为主，与硬件设备兼容性好。

五、现代流媒体架构与趋势

典型直播工作流包括：采集推流、云端处理、内容分发和客户端播放。主播通过 OBS 等工具以 RTMP 推流到源站；服务器进行转码、切片，生成多码率自适应流；处理后的流通过 CDN 分发到边缘节点；客户端根据网络条件选择最佳清晰度。

技术趋势上，流媒体正向低延迟化、标准化、编码效率提升和智能化演进：从 HLS 的 10 秒以上延迟向 WebRTC 的亚秒级延迟发展；MPEG-DASH 作为国际标准得到更广泛支持；AV1、H.266 等新编码标准提供更高压缩率；AI 技术用于内容理解、画质增强和带宽预测。

结语

流媒体选型没有单一“最优协议”，只有与业务目标匹配的组合。点播和标准直播优先考虑 HLS/DASH 的兼容与自适应；低延迟直播可结合 RTMP 推流、HTTP-FLV 或 WebRTC；实时互动场景优先 WebRTC；安防监控继续发挥 RTSP 的硬件生态优势。理解协议与格式的边界，才能在设计架构时做出更稳健的技术决策。