流媒体协议

流媒体

流媒体(Streaming Media)又叫流式媒体。是指把连续的影像和声音信息经过压缩处理后放上网站服务器,由视频服务器向用户计算机顺序或实时地传送各个压缩包，让用户一边下载一边观看、收听，而不要等整个压缩文件下载到自己的计算机上才可以观看的网络传输技术。该技术先在使用者端的计算机上创建一个缓冲区，客户端在播放前并不需要下载整个媒体⽂文件，而是在将缓存区中已经收到的媒体数据进⾏行播放。同时，媒体流的剩余部分仍持续不断地从服务器递送到客户端，即所谓的“边下载，边播放”。采用流媒体技术使得数据包得以像流水一样发送, 如果没有流媒体技术, 那么我们就要像以前用迅雷下电影一样, 下载整个影片才能观看。这样我们需要在漫长的等待之后（因为受限于带宽，下载通常要花上较长的时间），才可以看到或听到媒体传达的信息。令人欣慰的是，在流媒体技术出现之后，人们便无需再等待媒体完全下载完成了。

流媒体系统的组成

通常，组成一个完整的流媒体系统包括以下5个部分:

  • 一种用于创建、捕捉和编辑多媒体数据，形成流媒体格式的编码工具;

  • 流媒体数据;

  • 一个存放和控制流媒体数据的服务器;

  • 要有适合多媒体传输协议甚至是实时传输协议的网络;

  • 供客户端浏览流媒体文件的播放器。

流媒体技术的分类

从传输方式上大致可以分为HTTP渐进式下载、实时流媒体传输、HTTP流式传输三大类。

HTTP顺序流(渐进)式传输(Progressive Streaming)

顺序流式传输是顺序下载，在下载文件的同时用户可以观看，但是，用户的观看与服务器上的传输并不是同步进行的，用户是在一段延时后才能看到服务器上传出来的信息，或者说用户看到的总是服务器在若干时间以前传出来的信息。如YouTube、优酷等大型视频网站的点播分发。它的核心区别是媒体文件不分片，直接以完整文件形态进行分发，通过支持Seek,终端播放器可从没下载完成部分中任意选取一个时间点开始播放，如此来满足不用等整个文件下载完快速播放的需求，一般MP4和FLV格式文件支持较好，打开一个视频拖拽到中部，短暂缓冲即可播放，点击暂停后文件仍将被持续下载就是典型的渐进式下载。在这过程中，客户端需要在硬盘上缓存所有前⾯已经下载的媒体数据，对本地存储空间的需求较⼤大。播放过程中⽤用户只能在前⾯面已经下载媒体数据的时间范围内进行进度条搜索和快进、快退等操作，而无法在整个媒体文件时间范围内执⾏行这些操作。顺序流式传输比较适合高质量的短片段，因为它可以较好地保证节目播放的最终质量。它适合于在网站上发布的供用户点播的音视频节目。

  • 应用场景
    • 点播型应用
  • 协议
    • 基于HTTP协议，HTTP协议并不是流媒体协议

实时流式传输(Realtime Streaming)

在实时流式传输中，音视频信息可被实时观看到。 实时流式传输必须匹配连接宽带，意味着以调制解调器速度连接时图像质量较差，而且由于出错丢失的信息被忽略掉，网络拥挤或者出现问题时候，视频质量很差，如欲保证视频质量，顺序流式传输也许更好，实时流式传输需要特定的服务器，如QuickTime Streaming Server/Real Server/Windows Media Server这些服务器允许你对媒体发送进行更多级别的控制，因为而系统设置管理比HTTP服务器更复杂，实时流传输还需要特殊的网络协议，比如RTSP(Real time sreming protocol)或MMS(Microsoft Media Server)这些协议在有防火墙的时候会出现问题，导致用户不能看到一些地点的实时内容。

  • 应用场景
    • 直播型应用。直播服务模式下，用户只能观看播放的内容，无法进行控制。
    • 会议型应用。会议型应用类似于直播型应用，但是两者有不同的要求，如双向通信等。这对一般双方都要有包括媒体采集的硬件和软件，还有流传输技术。会议型的应用有时候不需要很高的音/视频质量。
  • 协议
    • RTSP
    • RTMP

HTTP流式传输

细分又可以分为: 伪HTTP流和HTTP流。

HTTP流

http-flv这样的使用类似RTMP流式协议的HTTP长连接，需由特定流媒体服务器分发的，是真正的HTTP流媒体传输方式，他在延时、首画等体验上跟RTMP等流式协议拥有完全一致的表现，同时继承了部分HTTP的优势。

  • 协议

    • HTTP FLV

  • 应用场景

    • 点播型应用
    • 直播型应用

HLS类“伪”HTTP流

HLS（Apple）、HDS(Adobe)、MSS(Microsoft) 、DASH（MPEG组织）均属于“伪”HTTP流，之所以说他们“伪”，是因为他们在体验上类似“流”，但本质上依然是HTTP文件下载。以上几个协议的原理都一样，就是将媒体数据（文件或者直播信号）进行切割分块，同时建立一个分块对应的索引表，一并存储在HTTP Web服务器中，客户端连续线性的请求这些分块小文件，以HTTP文件方式下载，顺序的进行解码播放，我们就得到了平滑无缝的“流”的体验。

  • 协议
    • HLS
    • HDS
    • MSS
    • DASH

接下来我们以上面传输方式的分类来简单介绍一下。

相关协议

HTTP

渐进下载流媒体播放采⽤用标准HTTP协议来在Web服务器和客户端之间递送媒体数据。

互联网上最初只能传输一些文本类的数据，自从HTTP协议发明之后，就可以传输超文本的音频视频等等内容，这主要就是靠HTTP协议中的MIME。通过它，浏览器就会根据协议中的Content-Type header去选择相应的应用程序去处理相应的内容。如此，才使得流媒体内容通过HTTP协议传输成为可能。

基于HTTP渐进式下载的流媒体播放仅能⽀持点播而不能支持直播，媒体流数据到达客户端的速率无法精确控制，客户端仍需维持一个与服务器上媒体文件同样大小的缓冲存储空间，在开始播放之前需要等待一段较长的缓冲时间从而导致实时性较差，播放过程中由于⽹网络带宽的波动或分组丢失可能会导致画面停顿或断续等待。为克服这些问题，需要引入专门的流媒体服务器以及相应的实时流媒体传输和控制协议来进行支持。所以就出现了接下来实时流媒体协议。

RTSP/RTP实际上由一组在IETF 中标准化的协议所组成，包括RTSP (实时流媒体会话协议)，SDP(会话描述协议)，RTP (实时传输协议)，以及针对不同编解码标准的RTP净载格式等，共同协作来构成⼀一个流媒体协议栈。基于该协议栈的扩展已被 ISMA (互联⽹网流媒体联盟) 和 3GPP (第三代合作伙伴计划) 等组织采纳成为互联⽹网和 3G 移动互联⽹网的流媒体标准。

RTSP

RTP

实时传输协议(Real-time Transport Protocol):是用于Internet上针对多媒体数据流的一种传输层协议，用于实际承载媒体数据并为具有实时特性的媒体数据交互提供端到端的传输服务，例如净载类型识别、序列号、时间戳和传输监控等。RTP是真正的实时传输协议，客户端仅需要维持一个很⼩小的解码缓冲区⽤于缓存视频解码所需的少数参考帧数据，从⽽⼤大缩短了起始播放时延，通常可控制在1秒之内。应⽤用程序通常选择在UDP之上来运⾏行RTP协议，以便利用UDP的复用和校验和等功能，并提高网络传输的有效吞吐量。当因为网络拥塞而发⽣RTP丢包时，服务器可以根据媒体编码特性智能的进行选择性重传，故意丢弃一些不重要的数据包；客户端也可以不必等待未按时到达的数据⽽继续向前播放，从⽽保证媒体播放的流畅性。RTP在组建IP网络(managed IP networks)中有良好的表现。但是，目前网络应用已经基本转移到CDN上，CDN大多数都不支持RTP流；此外，RTP包很容易被防火墙拦截；另外，RTP流要求服务端与每一个客户端都保持独立的长连接，这对服务端负载造成巨大的压力。

RTCP

Real-time Transport Control Protocol或RTP Control Protocol实时传输控制协议，是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外(out-of-band)控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据，它的主要功能是收集相关媒体链接的统计信息，并为RTP所提供的服务质量提供反馈。

RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。

RTSP

Real Time Streaming Protocol(实时流传输协议):由哥伦比亚大学、网景和Real Networks公司提交，是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。⽤来建立和控制⼀个或多个时间同步的连续⾳视频媒体流的会话协议。通过在客户机和服务器之间传递RTSP会话命令，可以完成诸如请求播放、开始、暂停、查找、快进和快退等VCR控制操作。RTSP 在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。允许同时多个串流需求控制，除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）或者安防。

由于安防行业非常多程序都已经是写的RTSP协议支持，要改就要改平台，要么就换支持RTSP协议的设备，那么你做为摄像机厂商，你究竟是支持还是不支持RTSP呢？千千万万的开发商和集成商程序都写好了，默认都是依照你设备支持RTSP的标准做的平台，你设备不支持，就会导致没人买。然后还是要支持RTSP。

基于 RTSP/RTP 的流媒体系统专门针对大规模流媒体直播和点播等应⽤用⽽设计，需要专门的流媒体服务器支持，与 HTTP 渐进下载相比主要具有如下优势：

  • 流媒体播放的实时性。与HTTP渐进下载客户端需要先缓冲一定数量媒体数据才能开始播放不同，基于RTSP/RTP的流媒体客户端几乎在接收到第一帧媒体数据的同时就可以启动播放。

  • ⽀持进度条搜索、快进、快退等高级VCR控制功能。

  • 平滑、流畅的⾳视频播放体验。

    在基于RTSP的流媒体会话期间，客户端与服务器之间始终保持会话联系，服务器能够对来自客户端的反馈信息动态做出响应。当因⽹络拥塞等原因导致可用带宽不足时，服务器可通过适当降低帧率等⽅式来智能调整发送速率。此外，UDP 传输协议的使用使得客户端在检测到有丢包发生时，可选择让服务器仅选择性地重传部分重要的数据（如关键帧），而忽略其他优先级较低的数据，从而保证在⽹络不好的情况下客户端也仍能连续、流畅地进行播放。

尽管如此，基于RTSP/RTP的流媒体系统在实际的应用部署特别是移动互联⽹应用中仍然遇到了不少问题，主要体现在:

  • 与 Web 服务器相比，流媒体服务器的安装、配置和维护都较为复杂，另外一个方面，目前的CDN都是基于RTMP的，顺势而为吧，特别是对于已经建有CDN内容分发⽹络）等基础设施的运营商来说，重新安装配置支持RTSP/RTP的流媒体服务器⼯作量很大。RTSP+RTP在UDP传输，实际上公网环境下大量的UDP包，容易被防火墙block住。
  • RTSP协议使⽤用的⽹网络端⼜⼝口号(554)可能被部分⽤用户⽹网络中的防⽕火墙和NAT等封堵，导致⽆无法使⽤用。虽然有些流媒体服务器可通过隧道⽅式将RTSP配置在HTTP的80端口上承载，但实际部署起来并不是特别⽅便。

RTSP在安防领域有广泛应用,一般传输的是ts/mp4格式的流。

  • 优点:
    • 延迟低，一般都能够做到500ms
    • 带宽好，时效率高
    • 倍速播放，主要是回放的时候提供的功能
    • 控制精准，任意选择播放点
  • 缺点
    • 服务端实现复杂
    • 代理服务器弱：数量少，优化少
    • 无路由器防火墙穿透
    • 管流分离：需要1-3个通道

SDP

SDP协议⽤用来描述多媒体会话。SDP协议的主要作⽤用在于公告⼀一个多媒体会话中所有媒体流的相关描述信息，以使得接收者能够感知这些描述信息并根据这些描述参与到这个会话中来。SDP会话描述信息通常是通过 RTSP 命令交互来进⾏行传递的，其中携带的媒体类信息主要包括:

  • 媒体的类型(视频，⾳音频等)

  • 传输协议(RTP/UDP/IP，RTP/TCP/IP 等)

  • 媒体编码格式(H.264 视频，AVS 视频等)

  • 流媒体服务器接收媒体流的IP地址和端⼝号

一次基本的RTSP操作过程是:

  • 首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。
  • 流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。
  • 客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。
  • 流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。
  • 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。
  • 最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话

RTSP协议与HTTP协议区别

  • RTSP引入了几种新的方法，比如DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，RTSP为rtsp 1.0,HTTP为http 1.1；

  • HTTP是无状态的协议，而RTSP为每个会话保持状态；

  • RTSP协议的客户端和服务器端都可以发送Request请求，而在HTTPF协议中，只有客户端能发送Request请求。

  • 在RTSP协议中，载荷数据一般是通过带外方式来传送的(除了交织的情况)，及通过RTP协议在不同的通道中来传送载荷数据。而HTTP协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应的消息体中携带的。

  • 使用ISO10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化；

  • RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的标题域中；

RTSP和RTP的关系

RTP不象http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据

RTSP与RTP最大的区别在于：RTSP是一种双向实时数据传输协议，是纯粹的传输控制协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。当然，RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。

RTMP

Real Time Messaging Protocol(实时消息传送协议)基于FLV格式进行开发，最初由Macromedia开发，后被Adobe收购，是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输开发的一种应用层的协议，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题。在基于传输层协议的链接建立完成后，RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMP Connection链接。协议基于TCP，是一个协议族(默认端口1935)，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。市面上绝大部分PC秀场使用的都是它，他有低延迟(2s左右)、稳定性高、技术完善、高支持度、编码兼容性高等特点。但是RTMP协议不使用标准的HTTP接口传输数据(TCP、UDP端口)，所以在一些特殊的网络环境下可能被防火墙屏蔽掉。

之前的时候使用RTMP技术的流媒体系统有一个非常明显的特点：使用 Flash Player作为播放器客户端，而Flash Player 现在已经安装在了全世界将近99%的PC上，因此一般情况下收看RTMP流媒体系统的视音频是不需要安装插件的。用户只需要打开网页，就可以直接收看流媒体，十分方便。

采用RTMP协议时，从采集推流端到流媒体服务器再到播放端是一条数据流，因此在服务器不会有落地文件。这样RTMP相对来说就有这些优点：

  • 实时性高：一般能做到3秒内。
  • 基于 TCP 长连接，不需要多次建连。

缺点就是：

  • 很多防火墙会墙掉RTMP，但是不会墙掉HTTP。

  • RTMP协议是Adobe的私有协议,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。

非常多非常多年前，移动互联网还没那么火。还没有H5。Flash视频和应用非常火的时候，RTMP成为了WEB平台直播的唯一方法，于是各大CDN就开始支持RTMP这个协议，经过了非常多年的发展和磨合，非常多cdn已经对rtmp这个协议非常完美的支持了，这个稳定的过程都是多少运维人员熬夜熬出来的，rtmp的势能惯性，会在中国持续未来非常长的时间。cdn不会对稳定盈利的系统轻易做出变化，相同，越来越多的公司来用rtmp。那么就造成cdn更要做rtmp了。这就是一个循环过程，一般的cdn公司不会轻易去打破，除非你是行业巨头。所以现在RTMP用的很多。

HTTP FLV

类似RTMP流式协议的HTTP长连接，RTMP封装在HTTP协议之上的，可以更好的穿透防火墙等,需由特定流媒体服务器分发的，是真正的HTTP流媒体传输方式，他在延时、首画等体验上跟RTMP等流式协议拥有完全一致的表现，同时继承了部分HTTP的优势。

http+flv ，将音视频数据封装成FLV格式，然后通过HTTP协议传输给客户端。http_flv&rtmp这两个协议实际上传输数据是一样的，数据都是flv文件的tag。相比RTMP，HTTP-FLV会生成一个非常大的http流，只能做拉流，RTMP可以做推流/拉流.所以目前直播常用的方案就是RTMP推流，HTTP-FLV播放。

HTTP协议中有个约定：content-length字段，用于描述HTTP消息实体的传输长度。服务器回复http请求的时候如果有这个字段，客户端就接收这个长度的数据然后就认为数据传输完成了，如果服务器回复http请求中没有这个字段，客户端就一直接收数据，直到服务器跟客户端的socket连接断开。http-flv直播就是利用第二个原理，服务器回复客户端请求的时候不加content-length字段，在回复了http内容之后，紧接着发送flv数据，客户端就一直接收数据了，http-flv这种流，服务器是不可能预先知道内容大小的，这时就可以使用Transfer-Encoding：chunk模式来传输数据了。

rtmp和http-flv比较：

  • RTMP: 基于TCP长链接，不需要多次建立链接，延时小，另外小数据包支持加密，隐私性好。

  • HTTP-FLV: HTTP长链接，将收到的数据立即转发，延时小，使用上只需要在大的音视频数据块头部加一些标记头信息，很简单，在延迟表现和大规模并发上比较成熟，手机端 app 使用很合适，实现方式上分为基于文件和基于包，基于包更实时，基于文件可以看回放。

  • 穿墙：很多防火墙会墙掉RTMP，但是不会墙HTTP，因此HTTP FLV出现奇怪问题的概率很小。

  • 调度：RTMP也有个302，可惜是播放器as中支持的，HTTP FLV流就支持302方便CDN纠正DNS的错误。
  • 容错：SRS的HTTP FLV回源时可以回多个，和RTMP一样，可以支持多级热备。
  • 简单：FLV是最简单的流媒体封装，HTTP是最广泛的协议，这两个组合在一起维护性更高，比RTMP简单多了。

Flash Video:是Adobe公司推出的另一种视频格式，是一种在网络上传输的流媒体数据存储容器格式。其格式相对简单轻量，不需要很大的媒体头部信息。整个FLV由Header和Body以及其他Tag组成。因此加载速度极快。

说到这里不得不说一下Adobe。

Adobe于2020年停止开发和分发Flash浏览器插件。我们先来简单回顾一下Flash的一生。

九十年代的互联网，由于网速的限制，大部分的网站基本上只有纯文本和简单的图片，基本上不能显示太多的图片和视频。当时主流的多媒体制作软件是Macromedia Director，人们可以用它做一些图片视频，它也是现在Adobe Director的前身。并通过Macromedia Shockwave（现为Adobe Shockware）发布到互联网上，人们可以在装有Shockwave的浏览器上浏览这些多媒体信息。

由于带宽的限制，人们对于图片的使用还是很谨慎的，这样做可以让Shockwave文件小一些，但这样做出来的东西也很一般。那个时候使用的格式都是GIF和JPEG，而这样的格式浪费了大量的存储空间。

这时，FutureWave出品的FutureSplash Animator出现了，它和Macromedia Director很类似，不过它的图片是基于矢量存储的，这些的格式可扩展性都非常强，分辨率也很高，存储空间却很小，这是因为矢量图的生成可以通过cpu做到，而当时网速很慢，cpu处理速度越来越快，这样做真的很聪明。后来，FutureWave打算卖给Adobe，但被拒绝了，最后Macromedia 收购了这家公司。FutureSplash Animator也重新定名为Macromedia Flash 1.0。它由两部分组成：图形及动画编辑器，媒体播放器。

随着网速的提升，人们开始使用Flash来播放视频。1999年到2005年之间是Flash发展的黄金时期，无论是Java，RealNetworks，QuickTime，Windows Media Player，所有的媒体播放器在装机量上都远不及它。

Macromedia 对Flash 服务的重视和持续投入改进更加促进了它的增长，后期加入的MovieClips也让它从一个媒体创造平台转型成为了一个网络平台。

2005年，Adobe收购了Macromedia之后，继续开发Flash，业务开始涵盖影片、音乐、游戏等诸多领域，许多电脑都已经预装了Flash，而且增加了边下边播的功能，这样用户就可以在文件刚下载时播放视频，Flash也逐渐成为了“行业标准”。

上世纪90年代，大多数的浏览器还不支持css，而Flash的出现，人们可以在浏览器上播放动画，火柴人，爆笑三国，神啊救救我吧，等无数的的视频，对老网民来说，留下了无数的回忆。超高压占比的格式，矢量图，边下边播，节省带宽的格式，也给人们留下了深刻的印象。那个时候，人们可以不用考虑代码实现就可以通过Flash做出一些炫酷的动画。

业界现在普遍认为，Flash的下坡路是从和苹果的决裂开始的。尤其是乔布斯在2010年发布的一篇《thoughts-on-flash》的文章。乔布斯在里面写下了于Flash的一点看法，说明自己为什么不使用Flash，谈到关于Flash的一些问题，比如开放性，安全性，对于设备续航的影响，不利于触摸屏，等等。最重要的原因。让一个第三方软件插足于开发者和平台之间，只会带来不合标准的应用，阻碍平台的改善与发展，我们不能被第三方的决定所左右。苹果从一开始就作为平台级别的绝对掌控者，从一开始就建立了app store这样的封闭系统策略，Flash 作为一个第三方插件，很难进入苹果自己的平台争利。

移动端的乏力并不是Flash唯一的问题，在PC方面，Flash也遇到了大麻烦，2015年谷歌旗下的Youtube开始将视频格式全部转为html5，甚至还推出了工具Swiffy，可以将Flash转换成html5.

不仅如此，Google旗下的Chrome占据了浏览器市场上的大部分份额，然而Chrome也慢慢把支持Flash变成非默认的选项，用户一般不会主动打开Flash，只有在遇到需要Flash的网站时，Chrome才会提醒用户需不需要打开它。

而Firefox，Safari这些也占有一定份额的浏览器，也开始站在了Flash的对立面上，Pc端和移动端的双面乏力，加速了Flash的衰亡。

真正的致命一击还是来自html5，它是最新一代的web标准，用户不需要安装额外的插件就可以访问视频和玩游戏，因为几乎所有的主流浏览器都支持新的html5标准。之后又由于flv.js的出现，加速了flash时代的结束。

Adobe宣布将于2020年停止对Flash的支持，很快GitHub之上出现一则请愿，请求Adobe将Flash开源。芬兰开发者 Juha Lindstedt 在请愿中提到：Flash是互联网历史上重要的一笔，消灭Flash意味着将来的一代就看不到以前的东西了。这样一来，很多游戏、体验和网站就会被遗忘；所以请求Adobe对Flash进行开源或部分开源，这样一来开源社区就能对Flash插件进行支持，或者至少打造可将swf/fla文件转换至HTML5、WebAssembly代码的工具。

常用的流媒体协议主要有HTTP渐进式下载和基于RTSP/RTP的实时流媒体协议栈等等，这些流媒体协议大多数可以平移到移动流媒体中继续应用。然⽽由于移动互联⽹网及其终端设备的一些独有特性，传统流媒体协议在移动互联⽹中的应⽤用在功能、性能的提供和⽤户体验等⽅方⾯面都会受到不同程度的约束和限制，以及Apple和Adobe的关系，于是一些新的流媒体协议应运而生。例如，苹果公司的 HTTP Live Streaming 就是其中具有代表性且得到较为⼴广泛应⽤用的一个。 但是HLS（Apple）、HDS(Adobe)、MSS(Microsoft) 、DASH（MPEG组织）均属于“伪”HTTP流，之所以说他们“伪”，是因为他们在体验上类似“流”，但本质上依然是HTTP文件下载。以上几个协议的原理都一样，就是将媒体数据（文件或者直播信号）进行切割分块，同时建立一个分块对应的索引表，一并存储在HTTP Web服务器中，客户端连续线性的请求这些分块小文件，以HTTP文件方式下载，顺序的进行解码播放，我们就得到了平滑无缝的“流”的体验。其主要特点是：放弃专门的流媒体服务器，而返回到使用标准的 Web服务器来递送媒体数据；将容量巨大的连续媒体数据进⾏分段，分割为数量众多的小⽂件进行传递，迎合了 Web服务器的⽂件传输特性；采⽤用了⼀个不断更新的轻量级索引⽂件来控制分割后⼩媒体文件的下载和播放，可同时⽀持直播和点播，以及VCR类会话控制操作。HTTP协议的使⽤用降低了HTTP Live Streaming 系统的部署难度，同时也简化了客户端（特别是嵌⼊入式移动终端）软件的开发复杂度。此外，⽂件分割和索引文件的引入也使得带宽⾃适应的流间切换、服务器故障保护和媒体加密等变得更加方便。与RTSP/RTP相比，HTTP Live Streaming的最⼤缺点在于它并非一个真正的实时流媒体系统，在服务器和客户端都存在一定的起始延迟。

HLS

HTTP Live Streaming:是苹果公司实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件。因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。它也解决了RTMP协议存在的一些问题，例如RTMP协议不使用标准的HTTP接口传输数据(TCP、UDP端口)，所以在一些特殊的网络环境下可能被防火墙屏蔽掉，而HLS使用的是HTTP协议传输数据(80端口)，不会遇到被防火墙屏蔽的情况。

HLS相比于http-flv的优点就是不需要任何插件，html5可以直播播放，safari，EDGE等浏览器都可以直接播放HLS的视频流。

在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U(m3u8) playlist文件，用于寻找可用的媒体流(将视频分为一个个视频小分片，然后用m3u8索引表进行管理，由于客户端下载到的视频都是5-10秒的完整数据，所以视频的流畅性很好，但是同样也引入了很大的延迟(一般延迟在10-30s左右))。

上面提到了m3u8，那m3u8构成是？直播中m3u8、ts如何实时更新？

  • 是一个索引地址/播放列表，通过FFmpeg将本地的xxx.mp4进行切片处理，生成m3u8播放列表（索引文件）和N多个 .ts文件，并将其（m3u8、N个ts）放置在本地搭建好的webServer服务器的指定目录下，我就可以得到一个可以实时播放的网址，我们把这个m3u8地址复制到 VLC 上就可以实时观看！ 在 HLS 流下，本地视频被分割成一个一个的小切片，一般10秒一个，这些个小切片被 m3u8管理，并且随着终端的FFmpeg 向本地拉流的命令而实时更新，影片进度随着拉流的进度而更新，播放过的片段不在本地保存，自动删除，直到该文件播放完毕或停止，ts 切片会相应的被删除，流停止，影片不会立即停止，影片播放会滞后于拉流一段时间

HLS的整体流程为:

视频源文件 -> 服务器(编码器、流分割器) -> 分发器(索引文件、*.ts) -> 传输网络 -> 客户端

HLS的最大缺点就是延迟高，但Apple在WWDC2019发布了新的解决方案，可以将延迟从8秒降低到1至2秒。

HLS的详细介绍

HDS

Http Dynamic Streaming:是一个由Adobe公司模仿HLS协议提出的另一个基于Http的流媒体传输协议(传统流媒体解决方案RTMP+FLV的组合)。

Flash Player 和 Flash Media Server 的最新版支持传统的 RTMP 协议和 HTTP 协议。它是RTMP的后继产品，也增加了对自适应流的支持。其模式与HLS类似，也是索引文件和媒体切片文件结合的下载方式，但是又要比HLS协议更复杂。

基于HTTP的流的优势是：

  • 不需要防火墙开普通web浏览器所需端口以外的任何端口
  • 允许视频切片在浏览器、网关和CDN的缓存，从而显著降低源服务器的负载。

HDS 的文件格式为 FLV/F4V/MP4，索引文件为 f4m，同时支持直播和时移。

Smooth Streaming

微软提供的一套解决方案，是IIS的媒体服务扩张，用于支持基于HTTP的自适应串流，它的文件切片为mp4，索引文件为ism/ismc。

在基于HTTP提供流媒体的方面，到目前为止已经看到了三种方案，苹果的HLS，Adobe HTTP Dynamic Streaming (HDS)和Microsoft Smooth Streaming (MSS)，当然，各家用的协议，格式会不一样。于是MPEG呼吁大家做到一起，聊聊出一个统一的标准。

DASH

DASH(MPEG-DASH)全称为Dynamic Adaptive Streaming over HTTP。是国标标准组MPEG( (Moving Picture Experts Group) 2014年推出的技术标准，主要目标是形成IP网络承载单一格式的流媒体并提供高效与高质量服务的统一方案，解决多制式传输方案(HTTP Live Streaming, Microsoft Smooth Streaming, HTTP Dynamic Streaming)并存格局下的存储与服务能力浪费、运营高成本与复杂度、系统间互操作弱等问题。

DASH是基于HTTP的动态自适应的比特率流技术，使用的传输协议是TCP，也是把视频分割成一小段一小段， 通过HTTP协议进行传输，客户端得到之后进行播放；不同的是MPEG-DASH支持MPEG-2 TS、MP4等多种格式, 可以将视频按照多种编码切割, 下载下来的媒体格式既可以是ts文件也可以是mp4文件, 所以当客户端加载视频时, 按照当前的网速和支持的编码加载相应的视频片段进行播放.

因为是分片的，客户端可以自由选择需要播放的媒体分片，可以实现Adaptive Bitrate Streaming技术，不同画质内容无缝切换，提供更好的播放体验。

YouTube采用DASH！其网页端及移动端APP都使用了DASH。

DASH的整个流程:

内容生成服务器(编码模块、封装模块) -> 流媒体服务器(MPD、媒体文件、HTTP服务器) <-> DASH客户端(控制引擎、媒体引擎、HTTP接入容器)

DASH详细介绍

hls_hds_mss_dash

这么多流媒体协议我该选用哪个？需要说明的是，各种流媒体协议都有其生存的理由，比如监控行业、电信行业IPTV就不能没有RTSP，因为这里面所有的监控应用程序太多基于RTSP；比如目前的直播主协议就是RTMP，主要是因为CDN对RTMP支持的最好；再比如Apple终端市场占有率太高，就不能够不去考虑HLS。

每一种流媒体协议都有其应用场景，每一种流媒体协议都有其发展的历史原因，每一种流媒体协议都有其自身的优势和不足。所以，我们需要对各种协议的原理、构成、特性都有所了解，才能在自身应用场景中选择出最佳方案。

参考:

results matching ""

    No results matching ""