视频传输协议的总结区分

视频传输协议的总结区分

1. SRT协议（开源视频传输协议）

定义： 安全可靠传输协议（Secure Reliable Transport, SRT）是基于UDT的开源互联网传输协议，保留了UDT的核心思想和机制，抗丢包能力强，适用于复杂的网络环境。

协议特点： 安全（支持AES加密，保障端到端的视频传输安全），可靠（通过前向纠正技术FEC来保证传输的稳定性），低延迟（建立在UDT协议之上，解决了UDT协议传输延迟高的问题）。SRT协议对上层提供了丰富的拥塞控制统计信息，包括RTT、丢包率、inflight、send/receive bitrate等信息，利用这些信息，可以实现带宽预测，并根据带宽的变化在编码层去做自适应动态编码与拥塞控制。

SRT基本思想： 下图可以涵盖SRT的基本思想：对比编码后的视音频码流（左侧绿色折线“Source”）与经过公网传输后的码流（红色折线“NetworkTransmission”），可以看到编码后的源视音频码流具有固定的帧间隔与一定特性的可变比特率，但经过公网传输后的码流，其帧间隔变得不固定且码率特性也被完全改变，解码这样的信号是一项十分艰巨的挑战，甚至根本无法解码。

而如果使用加入纠错的SRT协议进行公共互联网传输，尽管编码后的视音频码流经过公网传输帧间隔变得不固定，但由于SRT协议封装中包含精准的时间戳，解码接收端可以通过该时间戳重现固定的帧间隔。更重要的是，通过规定延时量，同时划定了send buffer（发送端缓冲区）与receive buffer（接收端缓冲区），来自接收端的反馈信号（可以理解为后向纠错）通过一系列的设置、纠错、流量控制，使编码后的视音频码流拥有与原码流几乎一样的码率特性。

Encoder编码器处理完成的数据会被输入send buffer，send buffer会对数据进行时间校验，也就是按照一定的时间顺序编码并通过internet发送至receive buffer，receive buffer按照报文上的时间戳一点点处理，确保生成的数据与源码流基本一致。

2. DASH协议（MPEG-DASH）

定义： DASH（MPEG-DASH）是 Dynamic Adaptive Streaming over HTTP的缩写，它是基于HTTP的动态自适应的比特率流技术，使用的传输协议是TCP。MPEG-DASH会将内容分解成一系列小型的基于HTTP的文件片段，每个片段包含很短长度的可播放内容，而内容总长度可能长达数小时（例如电影或体育赛事直播）。内容将被制成多种比特率的备选片段，以提供多种比特率的版本供选用。当内容被MPEG-DASH客户端回放时，客户端将根据当前网络条件自动选择下载和播放哪一个备选方案。客户端将选择可及时下载的最高比特率片段进行播放，从而避免播放卡顿或重新缓冲事件。也因如此，MPEG-DASH客户端可以无缝适应不断变化的网络条件并提供高质量的播放体验，拥有更少的卡顿与重新缓冲发生率。

DASH的整个流程：（1）主播直播流上传；（2）服务器端的编解码封装；（3）流媒体分发器（mpd文件，切割后的媒体文件）；（4）客户端（客户端加载mpd文件并进行解析，组成文件下载链接，当前的网速和支持的编码加载相应的视频片段进行播放）。

DASH不关心编解码器，因此它可以接受任何编码格式编码的内容，如H.265、H.264、VP9等。

3. RTMP协议

RTMP，Real-Time Messaging Protocol 是由 Adobe 推出的音视频流传递协议；它通过一种自定义的协议，来完成对指定直播流的播放和相关的操作。在 Web 上可以通过 MSE（MediaSource Extensions）来接入 RTMP，基本思路是根据 WebSocket 直接建立长连接进行数据的交流和监听。RTMP 协议根据不同的套层，也可以分为：

• 纯 RTMP: 直接通过 TCP 连接，端口为 1935
• RTMPS: RTMP + TLS/SSL，用于安全性的交流。
• RTMPE: RTMP + encryption。在 RTMP 原始协议上使用，Adobe 自身的加密方法
• RTMPT: RTMP + HTTP。使用 HTTP 的方式来包裹 RTMP 流，这样能直接通过防火墙。不过，延迟性比较大。
• RTMFP: RMPT + UDP。该协议常常用于 P2P 的场景中，针对延时有变态的要求。

RTMP 内部是借由 TCP 长连接协议传输相关数据，所以，它的延时性非常低。并且，该协议灵活性非常好（所以，也很复杂），它可以根据 message stream ID 传输数据，也可以根据 chunk stream ID 传递数据。两者都可以起到流的划分作用。流的内容也主要分为：视频，音频，相关协议包等。

4. HTTP协议

HTTP的视频协议，主要是在互联网普及之后。在互联网上看视频的需求下形成的。
最初的HTTP视频协议，没有任何特别之处，就是通用的HTTP文件渐进式下载。本质就是下载视频文件，而利用视频文件本身的特点，就是存在头部信息，和部分视频帧数据，就完全可以解码播放了。显然这种方式需要将视频文件的头部信息放在文件的前面。有些例如faststart工具，就是专门做这个功能的。
但是最为原始的状态下，视频无法进行快进或者跳转播放到文件尚未被下载到的部分。这个时候对HTTP协议提出了range-request的要求。这个目前几乎所有HTTP的服务器都支持了。range-request，是请求文件的部分数据，指定偏移字节数。在视频客户端解析出视频文件的头部后，就可以判断后续视频相应的帧的位置了。或者根据码率等信息，计算相应的为位置。

优点：
HTTP Live Streaming 还有一个巨大优势：自适应码率流播（adaptive streaming）。效果就是客户端会根据网络状况自动选择不同码率的视频流，条件允许的情况下使用高码率，网络繁忙的时候使用低码率，并且自动在二者间随意切换。这对移动设备网络状况不稳定的情况下保障流畅播放非常有帮助。实现方法是服务器端提供多码率视频流，并且在列表文件中注明，播放器根据播放进度和下载速度自动调整。使用起来也非常简单。
缺点：
实时性相对较差，直播的时候延迟比较高。

5. RTSP协议

用于Internet上针对多媒体数据流的一种传输协议，是TCP/IP协议体系中的一个应用层协议，RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。
本协议是最早的视频传输协议。其中RTSP协议用于视频点播的会话控制，例如发起点播请求的SETUP请求，进行具体播放操作的PLAY、PAUSE请求，视频的跳转也是通过PLAY请求的参数支持的。

优点：
RTSP协议族的优势，在于可以控制到视频帧，因此可以承载实时性很高的应用。这个优点是相对于HTTP方式的最大优点。H.323视频会议协议，底层一般采用RTSP协议。RTSP协议族的复杂度主要集中在服务器端，因为服务器端需要parse视频文件，seek到具体的视频帧，而且可能还需要进行倍速播放（就是老旧的DVD带的那种2倍速，4倍速播放的功能），倍速播放功能是RTSP协议独有的，其他视频协议都无法支持。
缺点：
就是服务器端的复杂度也比较高，实现起来也比较复杂。Ios端不支持该协议。

参考文献

[1] SRT协议解释： https://zhuanlan.zhihu.com/p/114436399

[2] DASH协议：https://zhuanlan.zhihu.com/p/69184805

[3] https://zhuanlan.zhihu.com/p/47773064

[4] https://blog.****.net/matrix_laboratory/article/details/60574079?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase