从RTSP协议（传输媒体流）的直播到 HTTP TS（ts分片 编码器之后的ts分片,html文件）(APPLE的Live streaming方案)转换工作。
HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8)playlist文件，用于寻找可用的媒体流。
HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。
苹果公司把HLS协议作为一个互联网草案（逐步提交），在第一阶段中已作为一个非正式的标准提交到IETF。但是，即使苹果偶尔地提交一些小的更新，IETF却没有关于制定此标准的有关进一步的动作。
一、RTSP
1、简介
Real Time Streaming Protocol实时流媒体协议，是应用层协议，控制实时数据的传送。它提供了一个可扩展的框架，使得能够可控按需传输实时数据。但RTSP本身并不发送连续媒体流，只充当了多媒体服务器的网络远程控制。
2、协议特点
• 可扩展性：很容易加入新方法和参数。
• 易解析：可由标准HTTP或MIME解析器解析。
• 安全：使用网页安全机制，也可以使用传输层或网络层安全机制。
• 独立传输：可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP）；如果想要实现应用级可靠，也可使用可靠流协议。
• 多服务器支持
• 记录设备控制：协议可控制记录和回放设备。
• 流控与会议开始分离
• 适合专业应用：支持帧级精度，允许远程数字编辑。
• 表示描述中立
• 代理与防火墙友好：可由应用层和传输层防火墙处理。
• HTTP友好：很多定义语法与HTTP/1.1相似
• 传输协调
• 性能协调
3、消息格式
RTSP消息由客户端到服务器的请求和由服务器到客户端的回应组成。
RTSP -message = Request | Response ; RTSP /1.0 messages
请求（Request）和回应（Response）消息都使用RFC822中实体传输部分规定的消息格式。两者的消息都可能包括一起始行，一个或多个报头域（headers）、一行表示报头域结束的空行（即CRLF前没有内容的行），和一个消息主体（message-body）。
generic-message = start-line
*message-header
CRLF
[ message-body ]
tart-line = Request-Line | Status-Line
同时为了健壮性考虑，服务器应该忽略任何在期望收到请求行时收到的空行。换句话说，如果服务器正在读协议流，在一个消息开始时如果首先收到了CRLF，这个CRLF符应被忽略。
RTSP报头域包括主报头、请求报头、回应报头及实体报头，都遵照RFC822给出的通用格式定义。每个报头域由后紧跟冒号的名字，单空格（SP），字符及域值组成。域名是大小写敏感的。
RTSP-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs make up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
报头域接收的顺序并不重要，但良好的习惯是，先发送主报头，然后是请求报头或回应报头，最后是实体报头。当且仅当报头域的全部域值都用逗号分隔的列表示时（即，#（值）），多个有相同域名的RTSP报头域才可以表示在一个消息里。而且必须能在不改变消息语法的前提下，将并发的域值加到第一个值后面，之间用逗号分隔，最终能将多个报头域结合成“域名：域值”对。
RTSP消息的消息主体用来携带请求或回应的主体。仅在使用传输编码(Transfer-Encoding)时消息主体和实体主体才有所不同。
message-body = entity-body
当消息包含消息主体时，消息主体的长度由以下规则来决定（按优先级高低顺序排列）：
• 任何回应消息都不包含消息主体（如1××，204和304回应），并且不管消息中是否存在实体报头域都以消息报头域后的第一行空行表示结束。
• 如果内容长度报头域存在，它在字节中的值就是消息主体的长度。如果内容报头域不存在，则假设值为零。
• 服务器关闭连接时。（关闭连接没有用来表明请求主体结束，否则可能导致服务器不能回应）。
尽管表示描述长度动态产生，但由于可获得了表示描述返回长度，使得服务器总是能决定表示描述长度而不需使用块传输编码方式。只要有实体主体就必须有内容长度项，这些规则保证了即使没有给出明确长度也能做出合理的操作。
4、RTSP连接方式
RTSP请求可以支持几中不同方式传送：
• 持久传输连接，用于多个请求/回应传输。
• 每个请求/回应传输一个连接。
• 无连接模式
传输连接类型由RTSP URI来定义。对 "rtsp" 方案，需要持续连接；而"rtspu"方案，调用RTSP 请求发送，而不用建立连接。
与HTTP不同，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。
二、HTTP
1、简介
HTTP超文本传输协议是分布式、协作的、超媒体信息系统的应用层协议。HTTP遵循请求(Request)/应答(Response)模型，并且是一种无连接无状态的协议，当一个客户端向服务器端发出请求，然后Web服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息。
2、协议特点
• 支持客服/服务器模式
• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。
• 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
• 无状态：无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
3、HTTP的URL说明
HTTP常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。
HTTP URL的格式如下：
http://host[":"port][abs_path]
http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。
输入：www.guet.edu.cn
浏览器自动转换成：http://www.guet.edu.cn/
4、HTTP消息报头说明
HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。
HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。
每一个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。
5、HTTP请求说明
HTTP请求由三部分组成分别是请求行、消息报头、请求正文。
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：
Method Request-URI HTTP-Version CRLF
其中 Method表示请求方法，Request-URI是一个统一资源标识符，HTTP-Version表示请求的HTTP协议版本，CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。
请求方法（所有方法全为大写）有多种，各个方法的解释如下：
GET 请求获取Request-URI所标识的资源
POST 在Request-URI所标识的资源后附加新的数据
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求服务器存储一个资源，并用Request-URI作为其标识
DELETE 请求服务器删除Request-URI所标识的资源
TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求
6、HTTP响应说明
在接收和解释请求消息后，服务器返回一个HTTP响应消息。也由三部分组成：状态行、消息报头、响应正文。
状态行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服务器HTTP协议的版本，Status-Code表示服务器发回的响应状态代码，Reason-Phrase表示状态代码的文本描述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
其中常见状态代码、状态描述、说明：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
响应正文就是服务器返回的资源内容。
三、RTSP与HTTP区别
1、相同点
• RTSP、HTTP都是在应用应用层。
• 理论上RTSP、HTTP都可以做直播和点播，但一般做直播用RTSP，做点播用HTTP。
• RTSP在语法和操作上与HTTP类似。全是基于tcp的链接
2、不同点
• RTSP引入了很多新方法并且有不同的协议标识符。
• RTSP服务器在大多数默认情况下需要维持一个状态，但HTTP是无状态协议。
• RTSP客户机和服务器都可以发出请求。
• RTSP的数据由另一个协议传送（有一特例除外）。
• RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。
• RTSP使用URI请求时包含绝对URI。而HTTP1只在请求中包含绝对路径，把主机名放入单独的报头域中。
2. HTTP本质上是一个非对称协议，客户端提出请求而服务器响应；而RTSP是对称的，服务器和客户端都可发送和响应请求。
rtsp和http的区别和联系
（1）联系：两者都用纯文本来发送消息，且rtsp协议的语法也和HTTP类似。Rtsp一开始这样设计，也是为了能够兼容使用以前写的HTTP协议分析代码 。
（2）区别：rtsp是有状态的，不同的是RTSP的命令需要知道现在正处于一个什么状态，也就是说rtsp的命令总是按照顺序来发送，某个命令总在另外一个命令之前要发送。Rtsp不管处于什么状态都不会去断掉连接。，而http则不保存状态，协议在发送一个命令以后，连接就会断开，且命令之间是没有依赖性的。rtsp协议使用554端口，http使用80端口。