流媒体协议RTMP，RTSP与HLS有什么不同

　流媒体协议RTMP,RTSP与HLS有什么不同？

　　HLS (HTTP Live Streaming)

　　Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。

　　常用的流媒体协议主要有 HTTP 渐进下载和基于 RTSP/RTP 的实时流媒体协议，这二种基本是完全不同的东西，目前比较方便又好用的是用 HTTP 渐进下载方法。在这个中 apple 公司的 HTTP Live Streaming 是这个方面的代表。它最初是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的流现在见到在桌面也有很多应用了，HTML5 是直接支持这个。

　　但是HLS协议的小切片方式会生成大量的文件，存储或处理这些文件会造成大量资源浪费。如果要实现数天的时移，索引量将会是个巨额数字，并明显影响请求速度。因此，HLS协议对存储I/O要求相当苛刻。对此，也有公司提出了非常好的解决方案。

　　新型点播服务器系统，独创了内存缓存数据实时切片技术，颠覆了这种传统实现方法，从根本上解决了大量切片的碎片问题，使得单台服务器的切片与打包能力不再是瓶颈。其基本原理如下：

　　不将TS切片文件存到磁盘，而是存在内存当中，这种技术使得服务器的磁盘上面不再会有“数以吨计”的文件碎片，极大减少了磁盘的I/O次数，延长了服务器磁盘的使用寿命，极大提高了服务器运行的稳定性。同时，由于使用这种技术，使得终端请求数据时直接从服务器的内存中获取，极大提高了对终端数据请求的反应速度，优化了视频观看体验。

　　RTSP协议，这应该是实时性最好的了，如果要想实时性要求很高，比如05s以内，这个是不错的选择。前阵子模仿spydroid写了个建议的rtsp 服务器，其实就是options，describe，setup，play，pause，teardown这几步了，这个协议用的最广泛，网上介绍也比较 多。要想真正深入了解rtsp协议，c++语言功底好的可以查看live555 。

打开“媒体——流”选项

点击“添加”按钮选择流媒体文件，然后点击“串流”按钮

点击“下一个”后，在“目标设置”界面选择“RTSP”，然后点击添加 + 按钮

填上目标ip地址，并在“转码选项”中选择相应的编码类型（这个视情况而定），目标IP地址就是PC机器本机的IP地址

客户端, 点击“媒体——打开网络串流”，在弹出的框中输入“rtsp://19216812:1234/tcp1”，点击“播放”按钮即可。

　　实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。

　　63 RTSP协议

　　实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。

　　631 简介

　　6311 目的

　　实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP 请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与HTTP/11类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下：

　　从媒体服务器上检索媒体：

　　用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。

　　媒体服务器邀请进入会议：

　　媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。

　　将媒体加到现成讲座中：

　　如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/11中类似，RTSP请求可由代理、通道与缓存处理。

　　6312 协议特点

　　RTSP 特性如下：

　　可扩展性：

　　新方法和参数很容易加入RTSP。

　　易解析：

　　RTSP可由标准 HTTP或MIME解吸器解析。

　　安全：

　　RTSP使用网页安全机制。

　　独立于传输：

　　RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。

　　多服务器支持：

　　每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。

　　记录设备控制：

　　协议可控制记录和回放设备。

　　流控与会议开始分离：

　　仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H323

　　可用来邀请服务器入会。

　　适合专业应用：

　　通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑

　　演示描述中立：

　　协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP URI。

　　代理与防火墙友好：

　　协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个"缺口"。

　　HTTP友好：

　　此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。

　　适当的服务器控制：

　　如用户启动一个流，他必须也可以停止一个流。

　　传输协调；

　　实际处理连续媒体流前，用户 可协调传输方法。

　　性能协调：

　　如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。

　　6313扩展RTSP

　　由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP 可以如下三种方式扩展，这里以改变大小排序：

　　以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。

　　加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。

　　定义新版本协议，允许改变所有部分。（除了协议版本号位置）

　　6314操作模式

　　每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。

　　为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：

　　单播：

　　以用户选择的端口号将媒体发送到RTSP请求源。

　　组播，服务器选择地址：

　　媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。

　　组播，用户选择地址：

　　如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。

　　6315 RTSP状态

　　RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：

　　SETUP：

　　让服务器给流分配资源，启动RTSP连接。

　　PLAY与RECORD：

　　启动SETUP 分配流的数据传输。

　　PAUSE：

　　临时停止流，而不释放服务器资源。

　　TEARDOWN：

　　释放流的资源，RTSP连接停止。

　　标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连

　　接产生连接标识。

　　6316 与其他协议关系

　　RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠HTTP。

　　但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。

　　当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。

　　632 协议参数

　　633 RTSP 信息

　　RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual Basic与Perl）实现研究原型。

　　10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx。RTSP信息可通过任何低层传输协议携带。

　　请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：

　　不管实体头段是否出现在信息中，不包括信息体的的响应信息总以头段后第一和空行结束。

　　如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。

　　服务器关闭连接。

　　注意：RTSP目前并不支持HTTP/11"块"传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。

　　从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。

　　634 实体

　　如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和试题体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。

　　实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。

　　635 连接

　　RTSP请求可以几种不同方式传送：

　　1、持久传输连接，用于多个请求/响应传输。

　　2、每个请求/响应传输一个连接。

　　3、无连接模式。

　　传输连接类型由RTSP URI来定义。对 "rtsp" 方案，需要持续连接；而"rtspu"方案，调用RTSP 请求发送，而不用建立连接。

　　不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。

　　636 方法定义

　　方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。

　　某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器操作复杂，并强加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通过TCP传输时才可使用。流数据（如RTP包）用一个ASCII美圆符号封装，后跟一个一字节通道标识，其后是封装二进制数据的长度，两字节整数。流数据紧