一种基于RTSP协议的网络播放协商处理方法转让专利

申请号 : CN201210584947.2

文献号 : CN103067504B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 李东旭申及

申请人 : 四川九洲电器集团有限责任公司

摘要 :

本发明涉及流媒体数据播放技术,尤其是一种基于RTSP协议的流媒体数据播放的RTSP命令协商处理方法。本发明所要解决的技术问题是:针对上述存在的问题,提供一种基于RTSP协议的网络播放协商处理方法。通过协商处理线程与播放线程等的配合完成对不同类型客户端数据的处理,使得客户端播放控制命令处理不受限于服务器。本发明通过解析客户端地址类型,利用协商处理线程进行处理,完成本设计。本发明主要应用与流媒体数据播放领域。

权利要求 :

1.一种基于RTSP协议的网络播放协商处理方法,其特征在于包括

步骤1:解析客户端地址,分别对其数据队列初始化,并初始化SOCKET建立连接;

步骤2:判断客户端地址类型,若客户端地址类型是IGMP,则进行组播播放后退出播放任务;若客户端地址类型是RTSP,则进行协商处理线程;若客户端地址类型是IGMP与RTSP同时存在,则开始播放,当接收到中间状态控制命令后,进行协商处理线程;

步骤3:协商处理中不响应中间状态控制命令,若协商处理线程判断成功,则开始播放操作,播放命令执行完毕后退出播放任务;若协商处理线程判断不成功,则直接退出播放任务;其中中间状态控制命令包括快进操作命令、快退操作命令、查找操纵命令、暂停操作命令;所述步骤3中协商处理线程具体过程是:步骤31:客户端地址类型是RTSP,协商处理线程向服务器发送OPTION请求,同时协商处理线程判断是否接收到客户端发送退出命令,若协商处理线程未接收到退出命令,则判断是否接收到服务器返回数据,若服务器有返回,并且返回处理正确标志位时,则进行DESCRIBE请求,若协商处理线程收到退出命令或者服务器对OPTION请求返回错误标志位时,协商处理线程退出播放任务;

步骤32:若服务器对OPTION请求有响应后,进行DESCRIBE请求,即协商处理线程向服务器发送DESCRIBE请求,同时协商处理线程判断是否收到客户端发送退出命令,若协商处理线程未收到退出命令,则判断协商处理线程是否接收到服务器反馈数据,若服务器有返回,并且返回正确标志位时,则进行SETUP请求,若协商处理线程收到退出命令或服务器对DESCRIBE请求返回错误标识位时,协商处理线程退出播放任务;

步骤33:若服务器对DESCRIBE请求有响应后,进行SETUP请求,即协商处理线程向服务器发送SETUP请求,同时判断协商处理线程是否收到客户端发送退出命令,若协商处理线程为收到退出命令,则判断是否接收到服务器反馈数据,若服务器有返回,并且返回正确标志位时,则进行PLAY请求,若协商处理线程收到退出命令或服务器对SETUP请求返回错误标志位时,协商处理线程退出播放任务;

步骤34:若服务器对SETUP请求有响应后,进行PLAY请求,即协商处理线程向服务器发送PLAY请求,同时判断协商处理线程是否接收到客户端发送退出命令,若协商处理线程未接收到退出命令,则判断是否收到服务器返回数据,若服务器有返回,并且返回正确标志位时,则开始播放,若协商处理线程收到退出命令或者服务器对PLAY请求返回错误标志位时,协商处理线程退出播放任务。

2.根据权利要求1所述的一种基于RTSP协议的网络播放协商处理方法,其特征在于所述步骤3中协商处理线程判断成功后,播放线程响应中间状态控制命令。

3.根据权利要求1所述的一种基于RTSP协议的网络播放协商处理方法,其特征在于所述退出命令是客户端发送的命令,服务器响应客户端发送的退出命令,并关闭SOCKET连接以完成本次播放任务。

4.根据权利要求1至3之一所述的一种基于RTSP协议的网络播放协商处理方法,其特征在于所述退出播放任务具体步骤是:协商处理线程判断当前播放客户端地址类型,若地址类型是RTSP类型,则通知服务器关闭RTSP连接并退出播放;若地址类型是IGMP类型直接退出播放。

说明书 :

一种基于RTSP协议的网络播放协商处理方法

技术领域

[0001] 本发明涉及流媒体数据播放技术,尤其是一种基于RTSP协议的流媒体网络数据播放的协商处理方法。

背景技术

[0002] RTSP(Real Time Streaming Protocol,实时流媒体协议)是由Real Network和Netscape共同提出的一种应用层协议,RTSP充当多媒体服务器的万罗远程控制,它定义了如何在IP网络上有效地传输流媒体数据。RTSP提供了一种机制,使音频、视频等数据可以按照需要进行实时传输,并且可以实施诸如暂停、快进等控制。网络中的媒体服务器基本上都是基于RTSP协议的媒体服务器,IPTV机顶盒是基于网络的产品,所以播放网络中的媒体流是一个必须的基本功能。但是通常服务器无法快速响应客户端播放控制命令。

发明内容

[0003] 本发明所要解决的技术问题是:针对上述存在的问题,提供一种基于RTSP协议的网络播放协商处理方法。通过协商处理线程与播放线程等的配合完成对不同类型客户端数据的处理,使得客户端播放控制命令处理不受限于服务器。
[0004] 本发明采用的技术方案如下:
[0005] 一种基于RTSP协议的网络播放协商处理方法包括
[0006] 步骤1:解析客户端地址,分别对其数据队列初始化,并初始化SOCKET建立连接;
[0007] 步骤2:判断客户端地址类型,若客户端地址类型是IGMP,则进行组播播放后退出播放任务;若客户端地址类型是RTSP,则进行协商处理线程;若客户端地址类型是IGMP与RTSP同时存在,则开始播放,当接收到中间状态控制命令后,进行协商处理线程;
[0008] 步骤3:协商处理中不响应中间状态控制命令,若协商处理线程判断成功,则开始播放操作,播放命令执行完毕后退出播放任务;若协商处理线程判断不成功,则直接退出播放任务;
[0009] 其中中间状态控制命令包括快进操作命令、快退操作命令、查找操纵命令、暂停操作命令。
[0010] 所述步骤3中协商处理线程判断成功后,播放线程响应中间状态控制命令。
[0011] 所述步骤3中协商处理线程具体过程是:
[0012] 步骤31:客户端地址类型是RTSP,协商处理线程向服务器发送OPTION请求,同时协商处理线程判断是否接收到客户端发送退出命令,若协商处理线程未接收到退出命令,则判断是否接收到服务器返回数据,若服务器有返回,并且返回处理正确标志位时,则进行DESCRIBE请求,若协商处理线程收到退出命令或者服务器对OPTION请求返回错误标志位时,协商处理线程退出播放任务;
[0013] 步骤32:若服务器对OPTION请求有响应后,进行DESCRIBE请求,即协商处理线程向服务器发送DESCRIBE请求,同时协商处理线程判断是否收到客户端发送退出命令,若协商处理线程未收到退出命令,则判断协商处理线程是否接收到服务器反馈数据,若服务器有返回,并且返回正确标志位时,则进行SETUP请求,若协商处理线程收到退出命令或服务器对DESCRIBE请求返回错误标识位时,协商处理线程退出播放任务;
[0014] 步骤33:若服务器对DESCRIBE请求有响应后,进行SETUP请求,即协商处理线程向服务器发送SETUP请求,同时判断协商处理线程是否收到客户端发送退出命令,若协商处理线程为收到退出命令,则判断是否接收到服务器反馈数据,若服务器有返回,并且返回正确标志位时,则进行PLAY请求,若协商处理线程收到退出命令或服务器对SETUP请求返回错误标志位时,协商处理线程退出播放任务;
[0015] 步骤34:若服务器对SETUP请求有响应后,进行PLAY请求,即协商处理线程向服务器发送PLAY请求,同时判断协商处理线程是否接收到客户端发送退出命令,若协商处理线程未接收到退出命令,则判断是否收到服务器返回数据,若服务器有返回,并且返回正确标志位时,则开始播放,若协商处理线程收到退出命令或者服务器对PLAY请求返回错误标志位时,协商处理线程退出播放任务。
[0016] 所述退出命令是客户端发送的命令,服务器响应客户端发送的退出命令,并关闭SOCKET连接以完成本次播放任务。
[0017] 所述退出播放任务具体步骤是:协商处理线程判断当前播放客户端地址类型,若地址类型是RTSP类型,则通知服务器关闭RTSP连接并退出播放;若地址类型是IGMP类型直接退出播放。
[0018] 综上所述,由于采用了上述技术方案,本发明的有益效果是:
[0019] 基于并行化处理技术接收和处理RTSP命令,各种并行消息多进程同时处理,提高了命令协商效率,使得服务器快速响应客户端播放控制命令。

附图说明

[0020] 本发明将通过例子并参照附图的方式说明,其中:
[0021] 图1本发明流程图;
[0022] 图2是协商处理线程流程图;
[0023] 图3是退出播放任务流程图。

具体实施方式

[0024] 本说明书中公开的所有特征,或公开的所有方法或过程中的步骤,除了互相排斥的特征和/或步骤以外,均可以以任何方式组合。
[0025] 本说明书(包括任何附加权利要求、摘要和附图)中公开的任一特征,除非特别叙述,均可被其他等效或具有类似目的的替代特征加以替换。即,除非特别叙述,每个特征只是一系列等效或类似特征中的一个例子而已。
[0026] 本发明相关说明
[0027] 1、IGMP(互联网组管理协议)是一种互联网协议,提供这样一种方法, 使得互联网上的主机向临近路由器报告它的广播组成员。 广播使得互联网上的一个主机向网上确认对于源主机发送内容感兴趣的计算机发送信息。
[0028] 2、OPTION请求作用:获取服务器支持方法。
[0029] 3、DESCRIBE请求作用:获取指定流媒体信息。
[0030] 4、SETUP请求:设置流媒体传输方式。
[0031] 5、PLAY请求:设置流媒体传输启始时间并开始传输媒体数据。
[0032] 6、快进操作请求:请求服务器传输快进快退数据。
[0033] 7、快退操作请求:请求服务器传输快退数据。
[0034] 8、定位操纵请求:请求服务器从指定时间开始传输媒体数据。
[0035] 9、暂停操作:临时停止流,而不释放服务器资源;
[0036] 10、播放线程作用:处理所有播放相关内容并分发到协商处理线程。
[0037] 11、协商处理线程作用:具体处理与服务器协商过程事务,负责处理协商数据。
[0038] 12、服务器返回正确标志位(如图1中,服务器返回ok):在RTSP协议中指的是返回值是“200,代表ok”的状态代码;服务器返回的错误标识位:在RTSP协议中指的是返回除“200,代表ok”之外的状态代码,详见《Real Time Streaming Protocal(RTSP)》中状态代码定义。
[0039] 13、实施例一:如图1所示,一种基于RTSP协议的网络播放协商处理方法包括[0040] 步骤1:解析客户端地址,分别对其数据队列初始化,并初始化SOCKET建立连接;
[0041] 步骤2:判断客户端地址类型,若客户端地址类型是IGMP,则进行组播播放后退出播放任务;若客户端地址类型是RTSP,则进行协商处理线程;若客户端地址类型是IGMP与RTSP同时存在,则开始播放,当接收到中间状态控制命令后,进行协商处理线程;
[0042] 步骤3:协商处理中不响应中间状态控制命令,若协商处理线程判断成功,则开始播放操作,播放命令执行完毕后退出播放任务;若协商处理线程判断不成功,则直接退出播放任务;
[0043] 其中中间状态控制命令包括快进操作命令、快退操作命令、查找操纵命令、暂停操作命令。
[0044] 实施例二:在实施例一基础上,所述步骤3中协商处理线程判断成功后,播放线程响应中间状态控制命令。
[0045] 实施例三:如图2所示,在实施例一或二基础上,所述步骤3中协商处理线程具体过程是:
[0046] 步骤31:客户端地址类型是RTSP,协商处理线程向服务器发送OPTION请求,同时协商处理线程判断是否接收到客户端发送退出命令,若协商处理线程未接收到退出命令,则判断是否接收到服务器返回数据,若服务器有返回,并且返回处理正确标志位时,则进行DESCRIBE请求,若协商处理线程收到退出命令或者服务器对OPTION请求返回错误标志位时,协商处理线程退出播放任务;
[0047] 步骤32:若服务器对OPTION请求有响应后,进行DESCRIBE请求,即协商处理线程向服务器发送DESCRIBE请求,同时协商处理线程判断是否收到客户端发送退出命令,若协商处理线程未收到退出命令,则判断协商处理线程是否接收到服务器反馈数据,若服务器有返回,并且返回正确标志位时,则进行SETUP请求,若协商处理线程收到退出命令或服务器对DESCRIBE请求返回错误标识位时,协商处理线程退出播放任务;
[0048] 步骤33:若服务器对DESCRIBE请求有响应后,进行SETUP请求,即协商处理线程向服务器发送SETUP请求,同时判断协商处理线程是否收到客户端发送退出命令,若协商处理线程为收到退出命令,则判断是否接收到服务器反馈数据,若服务器有返回,并且返回正确标志位时,则进行PLAY请求,若协商处理线程收到退出命令或服务器对SETUP请求返回错误标志位时,协商处理线程退出播放任务;
[0049] 步骤34:若服务器对SETUP请求有响应后,进行PLAY请求,即协商处理线程向服务器发送PLAY请求,同时判断协商处理线程是否接收到客户端发送退出命令,若协商处理线程未接收到退出命令,则判断是否收到服务器返回数据,若服务器有返回,并且返回正确标志位时,则开始播放,若协商处理线程收到退出命令或者服务器对PLAY请求返回错误标志位时,协商处理线程退出播放任务。
[0050] 实施例四:在实施例一、二或三基础上,所述退出命令是客户端发送的命令,服务器响应客户端发送的退出命令,并关闭SOCKET连接以完成本次播放任务。
[0051] 实施例五:如图3所示,在实施例四基础上,所述退出播放任务具体步骤是:协商处理线程判断当前播放客户端地址类型,若地址类型是RTSP类型,则通知服务器关闭RTSP连接并退出播放;若地址类型是IGMP类型直接退出播放
[0052] 本发明并不局限于前述的具体实施方式。本发明扩展到任何在本说明书中披露的新特征或任何新的组合,以及披露的任一新的方法或过程的步骤或任何新的组合。