音视频基础- 流媒体协议

Posted on   |   In

流媒体协议

HLS

HLS 全称是 HTTP Live Streaming，是一个由 Apple 公司提出的基于 HTTP 的媒体流传输协议，用于实时音视频流的传输。目前HLS协议被广泛的应用于视频点播和直播领域。

HLS协议将整条流切割成一个小的能够经过HTTP下载的媒体文件，而后提供一个配套的媒体列表文件M3U8。客户端拿到M3U8后，根据内容顺序地拉取媒体文件播放。

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

HLS协议

HLS 协议由三部分组成：HTTP、M3U8、TS。其中，HTTP是传输协议，M3U8是索引文件，TS是音视频的承载文件

HTTP传输

HTTP是最常见的应用层协议，我们日常基本的浏览器上网就是基于HTTP协议。

在HLS中，客户端通过HTTP请求获取m3u8内容和TS文件。

M3U8

M3U8是一个UTF-8文本文件，不包含音视频数据，是一个索引文件。

M3U8的内容由一些属性列表和URI组成：属性列表描述整个流的一些信息或者单个TS的信息；URI描述TS的路径。

TS

TS文件是一个媒体段，包含一部分音视频数据。单个TS可以单独播放。

一个完整的视频会包含很多个ts文件，直播场景下会不断的产生新的ts文件。

播放HLS时实际上播放的就是TS文件。

HLS优点和缺点

优点：

  • 手机，平板，电脑等设备对HLS的支持比较好
  • HLS可以根据网络带宽和设备性能等因素，自动调整视频的码率和分辨率，以保证最佳的观看体验。
  • HTTP 协议网络兼容性好, HTTP 数据包也可以方便地通过防火墙或者代理服务器, CDN 支持良好.

缺点：

  • 由于HLS是基于分段传输的，因此无法实现实时性较高的直播，不适合对实时性要求较高的场景，通常延迟都在10-30s之间。

RTMP

RTMP 协议是Real Time Message Protocol(实时信息传输协议)的缩写，它是由Adobe公司提出的一种应用层的协议，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题。

RTMP协议是应用层协议，是要靠底层可靠的传输层协议（通常是TCP）来保证信息传输的可靠性的。一般是使用端口1935，并且无论传输何种信息包括音视频数据都只有一个socket通道即只有一个物理通道。

RTMP协议传输时会对数据做自己的格式化，这种格式的消息我们称之为RTMP Message，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message划分为带有Message ID的Chunk，每个Chunk可能是一个单独的Message，也可能是Message的一部分，在接受端会根据chunk中包含的data的长度，message id和message的长度把chunk还原成完整的Message，从而实现信息的收发。

RTMP协议

RTMP在通讯前，需要建立客户端和服务器之间的连接，并且需要经过握手验证连接才能建立连接。

连接后，RTMP通过消息（Message）来传输数据。消息可以包括音频、视频、数据，甚至其它任何信息。

为了优化传输，Message会分为更小的单位：块。

握手

RTMP建立连接前，需要握手。

RTMP的握手分为简单握手和复杂握手：

  • 简单握手不需要进行验证
  • 复杂握手要通过复杂握手协议进行必要的验证
组块

RTMP会把消息（Message）分成小的块（Chunk）来传输，接收端通过消息ID来重组消息。

AMF

RTMP使用AMF协议描述消息内容。

消息

RTMP的消息有几种：

  1. 协议控制消息\
    协议控制消息负责交换参数，设置参数等。
  2. 命令消息\
    命令消息是控制流的，创建，连接，推流，拉流，关闭流等。
  3. 音视频消息\
    音视频消息携带音视频数据，一般是FLV格式封装的数据
  4. 数据消息\
    数据消息主要传输Meta数据，比如分辨率，名称等

RTMP优点和缺点

优点：

  • 延时低，一般3-5秒
  • 技术成熟，大部分CDN厂商都实现了RTMP协议，可以相互拉流推流

缺点：

  • 播放端需要定制，所以一般只是作为推流以及CDN内部传输协议
  • 由于TCP握手和RTMP握手的存在，建立连接花费时间长
  • 协议本身是为了传输完整的数据设计，所以没办法进一步优化延时

HTTP-FLV

HTTP-FLV不算是一种流媒体协议。

HTTP-FLV就是通过HTTP来传输FLV格式封装的音视频数据。

HTTP-FLV原理

客户端通过HTTP请求FLV时，服务端返回一个不带长度的头，客户端就一直接收数据，不会关闭；而服务端会持续的发送音视频数据

HTTP-FLV优点和缺点

优点：

  • HTTP协议更容易在网络上传输
  • FLV格式封装简单
  • FLV格式封装出来的媒体流有效负载高
  • HTTP-FLV的延时一般在3-5秒

缺点：

  • FLV需要Flash Player或者定制的播放器来播放

HTTP-MPEGTS

HTTP-MPEGTS 跟HTTP-FLV类似。

HTTP-MPEGTS 通过HTTP来传输mpegts数据。

HTTP-MPEGTS工作原理

客户端请求mpegts时，服务端返回一个不带长度的头，客户端不关闭，一直接收数据；而服务端持续发送ts数据。

HTTP-MPEGTS优点和缺点

优点：

  • HTTP协议更容易在网络上传输
  • mpegts数据流中，隔一段时间会插入一些必要的信息，以便播放不管从哪一段数据开始播放，都能播放成功
  • HTTP-MPEGTS的延时一般在3-5秒
  • 播放器普遍支持ts播放

缺点：

  • mpegts格式数据头占用的比较多，导致有效负载降低

WEBRTC

WebRTC（Web Real-Time Communication）协议，是由Google主导的，由一组标准、协议和JavaScript API组成，用于实现浏览器之间（端到端之间）的音频、视频及数据共享。

WebRTC工作原理

WebRTC是一个协议框架，定义了握手协议（DTLS），会话描述（SDP），加密传输协议（SRTP/SRTCP），P2P穿透（STUN/TURN），同时也加了一些新的拥塞控制算法GCC/BBR等。

DTLS

DTLS 是UDP版本的TLS协议，用于建立连接的时候交换密钥。

SDP

WebRTC 通过SDP来描述WebRTC建立连接所需的 ICE 服务器信息、音视频编码信息等。

SDP可以通过http,websocket以及其他的方式交互。

SRTP/SRTCP

SRTP/SRTCP 就是加密版本的RTP/RTCP。

ICE/STUN/TURN

ICE/STUN/TURN 主要是解决P2P打洞问题。

WebRTC优点和缺点

优点：

  • 延时低，可以优化到毫秒级别
  • 弱网环境下表现优异

缺点：

  • 设备端适配不好
  • WebRTC只适合解决第一公里和最后一公里的问题
  • WebRTC支持的音视频格式少
  • WebRTC只在弱网环境下有优势
-->