直播的那些事。。。

| Tags rtmp 

有那些直播协议?

当前主流的直播的协议可以分为3类:1) RTMP协议;2)HLS协议; 3) 私有协议(一般基于UDP协议);

RTMP协议

RTMP 协议是一个基于 TCP 的、持久连接并提供低延迟通信的协议 (延迟可以控制在1-3s)。RTMP 对流进行分段,客户端和服务器可以对分段长度进行协商(音频数据默认为 64 bytes, 视频数据和其他数据默认为 128 bytes)。

RTMP 定义了一些彼此独立运作的虚拟通道,通过它们可以发送和接收 RTMP 包。例如,可能会有一个用于视频流数据的通道,一个用于音频流数据的通道,一个用于带外控制信息(分段长度协商,等等)的通道,等等。在一个典型的 RTMP 会话中,在任意给定时间内,可能会有几个通道是同时活跃的。当 RTMP 数据被编码时,会产生一个包头。包头定义了其他一些事项,要发送到通道的 id,这一包产生时的 timestamp (如果需要的话),以及这一包的有效负载。包头后紧跟这一包实际负载的内容,包的内容是在发送给连接前根据当前协商好的分段长度分割好的。包头自己不会分段,并且包头的长度也不会被计入这一包第一个分段的长度中去。更高一层讲,RTMP 压缩 MP3 或者 AAC 音频和 FLV1 视频多媒体流,并使用 AMF (Action Message Format) 协议进行远程方法调用 (RPCs)。所需的 RPC 服务都是异步的,它们使用单一的 client/server request/response 模型,因此不需要实时通信。

Adobe 公开声明的规范(2009 年 6 月 15 日发布的 RTMP specification),没有公开协议实现的关键细节。很难单单根据发布的规范将 RTMP 协议自己实现这个协议,我们只能够通过学习实现了这个协议的应用,以及根据测试 TCP/IP 数据包捕获,来断定其很少的细节。

Adobe 发布的规范中缺少的细节包括:

  • 关于 RTMP 握手没有只言片语的描述。如果(关于握手)做的不正确,服务器的实现将无法传递 H.264/AAC 内容。如果握手错误,Flash player 会接收 H.264 内容失败。但是所有的客户端实现能够正常工作,因为 RTMP 服务器在这方面比较宽容(包括 FMS)。

  • 发送的块只以最大块大小发送;超出那个大小的块仍会被发送,这个块带有整个块大小的头,但是当超出最大块大小后,一个类型为 4 的块头会被发送,紧跟其后的是这一块被分割出来的下一部分。

  • 关于流的管理信息的解释缺失(31 和 32)。FMS 会时不时发送这些包。

数据包格式

数据包包含一个头和一个体,至于连接和控制命令使用 AMF (Action Message Format) 编码。头分为__基本报头__和__块消息报头__。基本报头是数据包唯一不变的部分,常常由一个复合字节组成,两个有效位代表块类型(规范中的格式),其余的组成了流 id。块消息报头包含 meta-data 信息,比如消息大小(以字节byte为单位),Timestamp 以及消息类型。

RTMP优势

RTMP劣势

协议内容

程序实现

HLS协议

私有协议


Previous     Next