RTSP

RTSP被用于创建的控制媒体流的传输,它为多媒体服务扮演“网络远程控制”的角色。尽管有时能够把RTSP控制信息和媒体数据流交织在一块儿传送,但通常状况RTSP自己并不用于转送媒体流数据。媒体数据的传送可经过RTP/RTCP等协议来完成。服务器

一次基本的RTSP操做过程是:首先,客户端链接到流服务器并发送一个RTSP描述命令(DESCRIBE)。流服务器经过一个SDP描述来进行反馈,反馈信息包括流数量、媒体类型等信息。客户端再分析该SDP描述,并为会话中的每个流发送一个RTSP创建命令(SETUP),RTSP创建命令告诉服务器客户端用于接收媒体数据的端口。流媒体链接创建完成后,客户端发送一个播放命令(PLAY),服务器就开始在UDP上传送媒体流(RTP包)到客户端。 在播放过程当中客户端还能够向服务器发送命令来控制快进、快退和暂停等。最后,客户端可发送一个终止命令(TERADOWN)来结束流媒体会话。网络

1、并发

一、OPTIONS.net


功能:
获取服务器/客户端支持的能力集
关键字段:无
特殊说明:IPTV系统中未使用该方法orm

 

 二、DESCRIBEblog


主要功能:
从服务器获取流媒体文件格式信息
从服务器获取流媒体文件传输信息
关键字段:
Content-Type:通常是SDP
Content-length:通常是SDP的长度
特殊说明:媒体信息经过SDP协议给出io

 

 

 


3.SETUP
主要功能:
与服务器协商流媒体传输方式
此过程当中,创建RTP通道
关键字段:
Transport——传输方式
Transport: MP2T/RTP/UDP;unicast;destination=121.60.21.53;client_port=8342-8343,MP2T/RTP/TCP;unicast;destination=121.60.21.53;interleaved=0-1ast

 

 

 

 


四、PLAY
主要功能:
与服务器协商流媒体播放
关键字段:
Range——播放时间
•Range: npt=0.0-end
•Range:clock=20100318T021919.35Z-20100318T031919.80Z
Scale——播放速度
•Scale: 1.0cli

相对时间描述——npt(normalplay time)
方法1 位置描述
•beginning      节目起始点
•now               当前播放点
•end                节目结束点
方法2 时间描述
•直接用数字形式表示与起始点的时间
绝对时间描述——clock
ISO 8601时间戳标准服务器端

 

 

 

 

五、TEARDOWN

主要功能:拆除链接
关键字段:无

 

 

 

 

六、PAUSE
主要功能:
暂停流媒体播放
关键字段:无从服务器获取参数,目前主要获取时间范围
保持RTSP链接(发送空的GET_PARAMETER)
关键字段(电信扩展):
x-Timeshift_Range: clock=20100318T021915.84Z-20100318T031915.84Z
x-Timeshift_Current: clock=20100318T031915.84Z
可能存在的问题:
长时间Pause后,RTSP的TCP链接超时中断。解决办法——按期发送心跳包维持链接(参见GetParam)

七、GET PARAMETER
从服务器获取参数,目前主要获取时间范围
保持RTSP链接(发送空的GET_PARAMETER)
关键字段(电信扩展):
x-Timeshift_Range: clock=20100318T021915.84Z-20100318T031915.84Z
x-Timeshift_Current: clock=20100318T031915.84Z

 

 

 

 


2、简单的rtsp消息交互的

1. 第一步:查询服务器端可用方法
 1.C->S:OPTION request       //询问S有哪些方法可用
1.S->C:OPTION response    //S回应信息的public头字段中包括提供的全部可用方法过程。

2. 第二步:获得媒体描述信息
2.C->S:DESCRIBE request      //要求获得S提供的媒体描述信息
2.S->C:DESCRIBE response    //S回应媒体描述信息,通常是sdp信息
3. 第三步:创建RTSP会话
3.C->S:SETUP request             //经过Transport头字段列出可接受的传输选项,请求S创建会话
3.S->C:SETUP response          //S创建会话,经过Transport头字段返回选择的具体转输选项,

并返回创建的Session ID;

4. 第四步:请求开始传送数据
4.C->S:PLAY request        //C请求S开始发送数据
4.S->C:PLAY response            //S回应该请求的信息
5. 第五步: 数据传送播放中
S->C:发送流媒体数据    // 经过RTP协议传送数据
6. 第六步:关闭会话,退出
6.C->S:TEARDOWN request      //C请求关闭会话
6.S->C:TEARDOWN response //S回应该请求

上述的过程只是标准的、友好的rtsp流程,但实际的需求中并不必定按此过程。
其中第三和第四步是必需的!第一步,只要服务器客户端约定好,有哪些方法可用,则option请求能够不要。

第二步,若是咱们有其余途径获得媒体初始化描述信息(好比http请求等等),

则咱们也不须要经过rtsp中的describe请求来完成。————————————————版权声明:本文为CSDN博主「Richard-Rong」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处连接及本声明。原文连接:https://blog.csdn.net/rongdeguoqian/article/details/17888407

相关文章
相关标签/搜索