流视频协议
原创
video streaming protocol - 流视频协议是由于流式传输需要将音视频分割成小块，按顺序发送并在接收时播放
Real-Time Stream Protocol (RTSP)
可以在任一时间为用户提供最佳质量视频，不支持adaptive bitrate 码率自适应
以客户服务器方式工作，如：暂停/继续、后退、前进等。
多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制,又称为“因特网录像机遥控协议”。
基于TCP/IP协议体系的一个应用层协议，RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。
本协议是最早的视频传输协议，可用于视频点播的会话控制，例如发起点播请求的SETUP请求，进行具体播放操作的PLAY、PAUSE请求，视频的跳转也是通过PLAY请求的参数支持的。
优点，可以控制到视频帧，因此可以承载实时性很高的应用。这个优点是相对于HTTP方式的最大优点。复杂度主要集中在服务器端，可以进行倍速播放功能，其他视频协议都无法支持。
网络延时低，一般在0.5S以内，缺点，就是服务器端的复杂度也比较高，实现起来也比较复杂。ios端不支持该协议，对移动端支持较弱。
rtsp_url = (“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name
rtsp://211.94.164.227/3.3gp RTSP/1.0RTP 协议（媒体数据传输协议）
Rtp数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。
Rtp用到的地方就是 PLAY ，服务器往客户端传输数据用UDP协议，RTP是在传输数据的前面加了个12字节的头(描述信息)。
RTP载荷封装设计本文的网络传输是基于IP协议，所以最大传输单元(MTU)最大为1500字节，在使用IP／UDP／RTP的协议层次结构的时候，这 其中包括至少20字节的IP头，8字节的UDP头，以及12字节的RTP头。这
样，头信息至少要占用40个字节，那么RTP载荷的最大尺寸为1460字 节。以H264 为例，如果一帧数据大于1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放。
HTTP 协议
http的视频协议，主要是在互联网普及之后。在互联网上看视频的需求下形成的。 最初的HTTP视频协议，没有任何特别之处，就是通用的HTTP文件渐进式下载。 本质就是下载视频文件，而利用视频文件本身的特点，
就是存在头部信息，和部分视频帧数据，就完全可以解码播放了。显然这种方式需要将视频文件的头部信息放在文件的前面。有些例如faststart工具，就是专门做这个功能的。但是最为原始的状态下，视频无法进行快进或
者跳转播放到文件尚未被下载到的部分。这个时候对HTTP协议提出了range-request的要求。这个目前几乎所有HTTP的服务器都支持了。 range-request，是请求文件的部分数据，指定偏移字节数。在视频客户端解析出视
频文件的头部后，就可以判断后续视频相应的帧的位置了。或者根据码率等信息，计算相应的为位置。目前常用的基于HTTP协议的视频协议是来源有APP公司的HSL（HTTP Live Streaming）协议，其优缺点：
优点，自适应码率流播（adaptive streaming）。效果就是客户端会根据网络状况自动选择不同码率的视频流，条件允许的情况下使用高码率，网络繁忙的时候使用低码率，并且自动在二者间随意切换。这对移动设备网
络状况不稳定的情况下保障流畅播放非常有帮助。实现方法是服务器端提供多码率视频流，并且在列表文件中注明，播放器根据播放进度和下载速度自动调整。使用起来也非常简单。
缺点，实时性相对较差，直播的时候延迟比较高，通常要在10S以上；
HTTP Live Streaming (HLS)
HTTP Live Streaming 由 Apple 开发，旨在能够从 iPhone 中删除 flash，如今已成为使用最广泛的协议。
桌面浏览器、智能电视、Android、iOS 均支持 HLS。HTML5 视频播放器也原生的支持HLS，但不支持 HDS 和 RTMP。这样就可以触达更多的用户。
HLS 支持码率自适应，并且支持最新的 H.265 解编码器，同样大小的文件，H.265 编码的视频质量是 H.264 的二倍。
此前缺点一直是高延迟，WWDC 2019 发布了新的解决方案，可以将延迟从8秒降低到1至2秒。具体可以查看Introducing Low-Latency HLS。
HLS 是目前使用最广泛的协议，且功能强大。数据显示，如果视频播放过程中遇到故障，只有8%的用户会继续在当前网站观看视频。
使用广泛兼容的自适应协议（例如HLS），可以提供最佳的受众体验。
Dynamic Adaptive Streaming over HTTP (MPEG-DASH)
MPEG-DASH 是最新的协议之一。尽管未被广泛使用，但该协议有一些很大的优势。
支持码率自适应，为观众提供他们当前互联网连接速度可以支持的最佳视频质量。网络速度波动时 DASH 可以保持不间断播放。
几乎支持所有编解码器，还支持加密媒体扩展（Encrpted Media Extensions，简写EME）和媒体扩展源（Media Source Extension，简写MSE），这些扩展用于浏览器的数字版权管理标准API。
如今只有一些广播公司在使用，将来或许会成为标准技术。但由于兼容性问题，这样的时刻还没有到来。
Real-Time Messaging Protocol (RTMP)
RTMP 是一个古老的协议。RMTP 最初由 Macromedia 开发，后被 Adobe 收购，至今仍被使用。
依赖 Flash 插件，正在被迅速淘汰，主要用于提取 stream。
当设置解编码器将视频发送到托管平台时，视频将使用 RTMP 协议发送到 CDN，随后使用另一种协议（通常是HLS）传递给播放器。
RTMP 协议延迟非常低，但由于需要 Flash 插件，不建议使用该协议，但流提取是例外。在流提取方便，RTMP 非常强大，且几乎得到了普遍支持。
HTTP Dynamic Streaming (HDS)
HDS 是 RTMP 的后继产品，也是依赖 Flash 的协议，但增加了码率自适应，并以高质量著称。
HDS 是延迟最低的流协议之一。但由于分段和加密操作，HDS 延迟并不如 RTMP 那样低。在流媒体体育比赛和其他重要事件中广受欢迎。
通常，不建议使用 HDS。对于任何公司而言，采用基于 flash 的技术无法吸引用户，围绕 flash 搭建播放器不是一个好主意。
Microsoft Smooth Streaming （MSS）
2008年推出，以 Microsoft 为重点的开发人员和在 Xbox 生态系统的开发人员仍在使用，除此之外已逐渐失去用户。
支持码率自适应，并且拥有强大的数字版权管理工具。
除非目标用户是 Xbox 用户，或计划只开发 Windows 平台的 app，否则，不推荐使用该协议。
原始文档
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。