一、流媒体协议

1.1 RTP (Real-time Transport Protocol)

1.1.1 RTP 特征

实时传输协议（Real-time Transport Protocol）是一个网络传输层协议，它是由 IETF 的多媒体传输工作小组 1996 年在 RFC 1889 中公布的，它作为因特网标准在 RFC 3550（该文档的旧版本是 RFC 1889）有详细说明，RTP 标准定义了两个子协议：RTP 和 RTCP。

RTP 协议是建立在 UDP 协议上的。 RTP 协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP 协议常用于流媒体系统（配合 RTCP 协议）、视频会议和视频电话系统（配合 H.263 或 SIP）。

RTP 标准由两个紧密链接部分组成：

• RTP —- 传送具有实时属性的数据；
• RTP 控制协议（RTCP）—-监控服务质量并传送正在进行的会话参与者的相关信息。

RTP 本身并没有提供按时发送机制或其他服务质量（QoS）保证，它依赖于底层服务去实现这一过程。RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。RTP 实行有序传送，RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。

1.1.2 RTP 报头

RTP 报头格式如下：

• V：RTP 协议的版本号，占 2 位，当前协议版本号为 2。
• P：填充标志，占 1 位，如果 P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
• X：扩展标志，占 1 位，如果 X=1，则在 RTP 报头后跟有一个扩展报头。
• CC：CSRC 计数器，占 4 位，指示 CSRC 标识符的个数。
• M: 标记，占 1 位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。
• PT: 有效载荷类型，占 7 位，用于说明 RTP 报文中有效载荷的类型，如 GSM 音频、JPEM 图像等。
• 序列号：占 16 位，用于标识发送者所发送的 RTP 报文的序列号，每发送一个报文，序列号增 1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。
• 时戳(Timestamp)：占 32 位，时戳反映了该 RTP 报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
• 同步信源(SSRC)标识符：占 32 位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的 SSRC。
• 特约信源(CSRC)标识符：每个 CSRC 标识符占 32 位，可以有 0 ～ 15 个。每个 CSRC 标识了包含在该 RTP 报文有效载荷中的所有特约信源。

这里的同步信源是指产生媒体流的信源，它通过 RTP 报头中的一个 32 位数字 SSRC 标识符来标识，而不依赖于网络地址，接收者将根据 SSRC 标识符来区分不同的信源，进行 RTP 报文的分组。特约信源是指当混合器接收到一个或多个同步信源的 RTP 报文后，经过混合处理产生一个新的组合 RTP 报文，并把混合器作为组合 RTP 报文的 SSRC，而将原来所有的 SSRC 都作为 CSRC 传送给接收者，使接收者知道组成组合报文的各个 SSRC。

1.2 RTCP (Real-time Transport Control Protocol)

实时传输控制协议（Real-time Transport Control Protocol,RTCP）是实时传输协议（RTP）的一个姐妹协议。

RTCP 为 RTP 媒体流提供信道外控制。RTCP 定期在多媒体流会话参加者之间传输控制数据。RTCP 的主要功能是为 RTP 所提供的服务质量提供反馈。

RTCP 收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，时延抖动，单向和双向网络延迟等等。网络应用程序可以利用 RTCP 所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP 本身不提供数据加密或身份认证，其伴生协议SRTCP（安全实时传输控制协议）则可用于此类用途。

WebRTC 内部采用的是 RTC+RTCP

1.3 SRTP & SRTCP

SRTP = Secure Real-time Transport Protocol
SRTCP = Secure Real-time Transport Control Protocol
SRTP 是在实时传输协议 RTP 基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由 David Oran（思科）和 Rolf Blom（爱立信）开发的，并最早由 IETF 于 2004 年 3 月作为 RFC 3711 发布。

1.4 RTSP (Real-time Transport Streaming Protocol)

RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议。RTSP 在体系结构上位于 RTP 和 RTCP 之上，它使用 TCP 或 UDP 完成数据传输。

RTSP 是一种基于文本的应用层协议，在语法及一些消息参数等方面与 HTTP 协议类似。

RTSP 被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把 RTSP 控制信息和媒体数据流交织在一起传送，但一般情况 RTSP 本身并不用于传送媒体流数据，媒体数据的传送可通过 RTP/RTCP 等协议来完成。

1.5 SDP (Session Description Protocol)

会话描述协议（Session Description Protocol 或简写 SDP）描述的是流媒体的初始化参数。此协议由 IETF 发表为 RFC 2327。

SDP 完全是一种会话描述格式，它不属于传输协议。

SDP 用于描述多媒体通信会话，包括会话建立、会话请求和参数协商。SDP 不用于传输媒体数据，只能用于两个通信终端的参数协商，包括媒体类型、格式以及所有其他和会话相关的属性。SDP 以字符串的形式描述上述初始化参数。

可以参考 SDP格式解析

1.6 SIP (Session Initiation Protocol)

SIP(Session Initiation Protocol)是一个应用层的信令控制协议。

SIP 用于初始化一个 Session，并负责传输 SDP 包；而 SDP 包中描述了一个 Session 中包含哪些媒体数据，邀请的人等等；当需要被邀请的人都通过各自的终端设备被通知到后，就可以使用 RTSP 来控制特定 Media 的通信，比如 RTSP 控制信息要求开始 Video 的播放，那么就开始使用 RTP（或者 TCP）实时传输数据，在传输过程中，RTCP 要负责 QoS 等。

1.7 RTMP (Real Time Messaging Protocol)

RTMP(Real-Time Messaging Protocol 实时消息传送协议)的缩写，它是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的一个基于TCP的应用层传输协议。这是一个标准的、未加密的实时消息传递协议，默认端口是 1935。

RTMP 是一种有状态协议。

RTMP 协议有效的保证了媒体传输质量，使用户可以观看到高质量的多媒体。RTMP 采用 TCP 协议作为其在传输层的协议，避免了多媒体数据在广域网传输过程中的丢包对质量造成的损失。此外 RTMP 协议传输的 FLV 封装格式支持的 H．264 视频编码方式可以在很低的码率下显示质量还不错的画面，非常适合网络带宽不足的情况下收看流媒体。

当然 RTMP 协议也有一些局限，RTMP 基于 TCP 协议，而 TCP 协议实时性不如 UDP，也非常占用带宽。目前基于 UDP 的 RTMFP 协议能很好的解决这些问题。

RTMPT 封装在 HTTP 请求之中，可穿越防火墙;
RTMPS 类似 RTMPT，但使用的是 HTTPS 连接;

1.8 RTMFP (Real Time Media Flow Protocol)

RTMFP 是 Adobe 公司开发的一套新的通信协议。

RTMFP 是基于 UDP 的，RTMP 是基于 TCP 的。UDP 在传送直播数据方面比 TCP 还是有较多优势的，比如减少延时，对丢包的容忍，虽然在可靠性上有所损失。与 RTMP 不同, RTMFP 支持 Flash Player 直接发送数据给另一个，而不经过 Server。

1.9 RSVP (Resource ReSerVation Protocol)

使用 RSVP 预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供 QoS。通常 RSVP 请求将会引起每个节点数据路径上的资源预留。

RSVP 只在单方向上进行资源请求，因此，尽管相同的应用程序，同时可能既担当发送者也担当接受者，但 RSVP 对发送者与接受者在逻辑上是有区别的。 RSVP 属于网络层协议。 RSVP 不传输应用数据，但支持因特网控制协议，如 ICMP、IGMP 或者路由选择协议。

1.10 MMS (Microsoft Media Server Protocol)

MMS(Microsoft Media Server Protocol)，微软媒体服务器协议，用来访问接收 Windows Media 服务器中 .asf 文件的一种协议。MMS 协议用于访问 Windows Media 发布点上的单播内容。

MMS 的默认端口是 1755.

1.11 HLS (HTTP Live Streaming)

HTTP Live Streaming（缩写是 HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。它的工作原理是把整个流分成一个个小的基于 HTTP 的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的 extended M3U (m3u8)playlist 文件，用于寻找可用的媒体流。

HLS 只请求基本的 HTTP 报文，与实时传输协议（RTP)不同，HLS 可以穿过任何允许 HTTP 数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。

HLS 协议规定：

• 视频的封装格式是 TS。
• 视频的编码格式为 H264,音频编码格式为 MP3、AAC 或者 AC-3。
• 除了 TS 视频文件本身，还定义了用来控制播放的 m3u8 文件（文本文件）。

二、封装格式

三、视频编码格式

四、音频编码格式

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。

分享文章