著录项信息
专利名称 | 一种多通道视频流的传输方法及系统 |
申请号 | CN201110148239.X | 申请日期 | 2011-06-02 |
法律状态 | 授权 | 申报国家 | 暂无 |
公开/公告日 | 2011-11-02 | 公开/公告号 | CN102231863A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | H04N21/647 | IPC分类号 | H;0;4;N;2;1;/;6;4;7;;;H;0;4;N;2;1;/;6;4;3;7查看分类表>
|
申请人 | 南京中兴力维软件有限公司 | 申请人地址 | 江苏省南京市江宁区东善桥正方中路888号中兴软件园
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 南京中兴力维软件有限公司 | 当前权利人 | 南京中兴力维软件有限公司 |
发明人 | 张欣慰;谢斌;林大镰 |
代理机构 | 深圳市世纪恒程知识产权代理事务所 | 代理人 | 胡海国 |
摘要
本发明公开了一种多通道视频流的传输方法及系统,包括客户端以及服务器,所述客户端包括视频接收模块、视频处理模块以及客户端会话模块,所述服务器包括多个与所述视频接收模块匹配的视频发送模块以及服务器端会话模块,所述客户端会话模块用以与服务器端会话模块完成信令的交互,并控制所述视频接收模块接收服务器发送的视频数据包,所述视频处理模块用以对所述视频接收模块接收的视频数据包进行处理,所述服务器端会话模块还控制视频发送模块向所述客户端发送视频数据包。本发明的客户端通过在视频请求协商过程中增加视频源合法性验证及视频数据包的有效性验证,从而可以提高视频流传输的正确性和可靠性。
1.一种多通道视频流的传输方法,其特征在于,包括:
A、客户端创建视频接收模块,并分配多个数据接收通道资源;
B、客户端向服务器发送媒体协商信息以请求视频,其中,所述媒体协商信息包括视频源验证信息以及数据接收通道资源信息;
C、服务器接受请求并向客户端返回应答消息;
D、客户端根据所述应答消息确认服务器接受视频请求,并向服务器发送确认消息,同时打开视频接收模块;
E、服务器收到客户端发送的确认消息后,向客户端发送携带视频源验证信息和媒体同步源标识的NAT穿越包;
F、客户端收到所述NAT穿越包之后,解析其中的视频源验证信息并进行视频源合法性验证,若验证通过,则创建客户端与服务器之间的数据链路;
G、客户端解析NAT穿越包中的媒体同步源标识,若解析成功,则保存并向服务器发送NAT响应包;
H、服务器确认收到客户端的NAT响应包后,通过多个数据发送通道向客户端发送携带了媒体同步源标识的视频数据包,若服务器未收到NAT响应包,则拒绝向客户端发送视频数据包;
I、客户端依据接收到的视频数据包中的媒体同步源标识判断视频数据包的有效性,若媒体同步源标识合法,则对接收的视频数据包依据视频合并算法进行合并处理,否则,则丢弃相应的视频数据包。
2.如权利要求1所述的多通道视频流的传输方法,其特征在于,在所述步骤B中,客户端通过会话初始协议向服务器请求视频。
3.如权利要求1所述的多通道视频流的传输方法,其特征在于,在所述步骤I中,判断所述媒体同步源标识是否合法的方法是,将客户端接收到的视频数据包中的媒体同步源标识与存储于客户端中的媒体同步源标识进行比较,若两者相同,则为合法,否则,则为非法。
4.如权利要求1所述的多通道视频流的传输方法,其特征在于,在所述步骤I中,所述视频合并算法包括如下步骤:
(1)客户端创建多通道视频数据包的合并转换缓冲区;
(2)客户端将接收到的视频数据包依照视频数据包的序号顺序放入所述合并转换缓冲区;
(3)客户端根据丢包检测方法,检测视频数据包是否存在丢包,若检测到丢包,则对接收到的视频数据包进行容错处理,并进行丢包统计;若未检测到丢包,则按顺序对数据包进行视频合并处理;
(4)将合并转换缓冲区中已处理的视频数据包清空,用于后续客户端接收到的视频数据包的处理。
5.如权利要求4所述的多通道视频流的传输方法,其特征在于,所述丢包检测方法包括:客户端开启定时器,若客户端超过预设的阈值时间仍未收到相应的视频数据包,则判断视频数据包存在丢包。
6.如权利要求4所述的多通道视频流的传输方法,其特征在于,所述丢包检测方法包括:
(1)设定丢包检测半径DS和阈值计算函数F;
(2)设定合并转换缓冲区中已收到的最大视频数据包的序号MAX;
(3)检测视频数据包的序号,若序号小于丢包阈值TS的数据包未收到,则认为发生丢包,其中,所述丢包阈值TS的计算方法为TS=F(MAX,DS)。
7.如权利要求6所述的多通道视频流的传输方法,其特征在于,所述计算函数F为线性函数,其中,F=MAX-DS。
8.如权利要求1所述的多通道视频流的传输方法,其特征在于,所述NAT穿越包为RTSP或XML格式。
9.如权利要求1所述的多通道视频流的传输方法,其特征在于,所述视频数据包为RTP数据包。
10.一种多通道视频流的传输系统,包括客户端以及服务器,其特征在于,所述客户端包括视频接收模块、视频处理模块以及客户端会话模块,所述服务器包括与所述视频接收模块匹配的视频发送模块以及服务器端会话模块,所述客户端会话模块用以与服务器端会话模块完成信令的交互,并控制所述视频接收模块接收服务器发送的视频数据包,所述视频处理模块用以对所述视频接收模块接收的视频数据包进行处理,所述服务器端会话模块还控制视频发送模块向所述客户端发送视频数据包,其中,所述多通道视频流的传输系统进行多通道视频流的传输方法包括:
客户端创建视频接收模块,并分配多个数据接收通道资源;
客户端向服务器发送媒体协商信息以请求视频,其中,所述媒体协商信息包括视频源验证信息以及数据接收通道资源信息;
服务器接受请求并向客户端返回应答消息;
客户端根据所述应答消息确认服务器接受视频请求,并向服务器发送确认消息,同时打开视频接收模块;
服务器收到客户端发送的确认消息后,向客户端发送携带视频源验证信息和媒体同步源标识的NAT穿越包;
客户端收到所述NAT穿越包之后,解析其中的视频源验证信息并进行视频源合法性验证,若验证通过,则创建客户端与服务器之间的数据链路;
客户端解析NAT穿越包中的媒体同步源标识,若解析成功,则保存并向服务器发送NAT响应包;
服务器确认收到客户端的NAT响应包后,通过多个数据发送通道向客户端发送携带了媒体同步源标识的视频数据包,若服务器未收到NAT响应包,则拒绝向客户端发送视频数据包;
客户端依据接收到的视频数据包中的媒体同步源标识判断视频数据包的有效性,若媒体同步源标识合法,则对接收的视频数据包依据视频合并算法进行合并处理,否则,则丢弃相应的视频数据包。
一种多通道视频流的传输方法及系统\n技术领域\n[0001] 本发明属于移动通信网络技术领域,更为具体地,涉及多通道视频流的传输方法及系统。\n背景技术\n[0002] 目前,随着无线技术的不断向前发展,无线带宽不断提升,人类社会已经逐步迈入\n3G、LTE高速无线网络时代。\n[0003] 在高速的无线网络环境下,原有的网络视频监控前端已经可以通过无线网络传输视频流。通常,普通无线前端设备一般提供单通道数据传输服务,在视频码流一定的环境下,单通道数据传输服务已可以满足需求。但是,随着用户对视频的要求越来越高,用户对视频流的分辨率的要求也从原先的QCIF发展到现在的CIF、D1。为了提高无线传输的速率,因此目前出现了采用双/多通道传输视频流的无线前端设备,无线双卡/多卡设备即因此而来,例如,对于无线双卡设备,其原理是使用两个无线网络通道同时传输一路视频码流,以此来提高传输速率。客户端收到视频流之后合并成为一路有效的视频码流。双卡设备具有双通道优势,能够显著提高在目前无线环境下的传输速率,实验显示,其传输速率较单通道数据传输平均能够提高80%的传输速率。\n[0004] 在中国专利《发明名称:一种多路径无线视频传输方法和系统,申请(专利)号:\n200810020904.5》中已经给出一种多路径无线视频传输方法,包括多路径视频的发送及接收处理。但该专利并没有给出多路径视频接收模块的具体方法;并且在多通道环境下接收视频流时,可能存在视频源非法、视频流无效、丢包及抖动乱序等问题,从而使得视频流的传输质量得不到保障。\n发明内容\n[0005] 本发明实施例的目的在于提供一种多通道视频流的传输方法及系统,其能针对多通道视频流在接收过程中进行视频源合法性验证,视频流数据合法性验证等等,从而可以确保在客户端获得的视频流数据的可靠性及准确性。\n[0006] 本发明实施例的目的是通过以下技术方案实现的:\n[0007] 一种多通道视频流的传输方法,其包括:\n[0008] A、客户端创建视频接收模块,并分配多个数据接收通道资源;\n[0009] B、客户端向服务器发送媒体协商信息以请求视频,其中,所述媒体协商信息包括视频源验证信息以及数据接收通道资源信息;\n[0010] C、服务器接受请求并向客户端返回应答消息;\n[0011] D、客户端根据所述应答消息确认服务器接受视频请求,并向服务器发送确认消息ACK(Acknowledge Character,确认字符),同时打开视频接收模块;\n[0012] E、服务器收到客户端发送的确认消息ACK后,向客户端发送携带视频源验证信息和媒体同步源标识(SSRC,Synchronization source)的NAT(网络地址转换,Network Address Translation)穿越包;\n[0013] F、客户端收到所述NAT穿越包之后,解析其中的视频源验证信息并进行视频源合法性验证,若验证通过,则创建客户端与服务器之间的数据链路;\n[0014] G、客户端解析NAT穿越包中的媒体同步源标识SSRC,若解析成功,则保存并向服务器发送NAT响应包;\n[0015] H、服务器确认收到客户端的NAT响应包后,通过多个数据发送通道向客户端发送携带了媒体同步源标识SSRC的视频数据包,若服务器未收到NAT响应包,则拒绝向客户端发送视频数据包;\n[0016] I、客户端依据接收到的视频数据包中的媒体同步源标识SSRC判断视频数据包的有效性,若媒体同步源标识SSRC合法,则对接收的视频数据包依据视频合并算法进行合并处理,否则,则丢弃相应的视频数据包。\n[0017] 优选地,在所述步骤B中,客户端通过会话初始协议向服务器请求视频。\n[0018] 优选地,在所述步骤I中,判断所述媒体同步源标识是否合法的方法是,将客户端接收到的视频数据包中的媒体同步源标识与存储于客户端中的媒体同步源标识进行比较,若两者相同,则为合法,否则,则为非法。\n[0019] 优选地,在所述步骤I中,所述视频合并算法包括如下步骤:\n[0020] (1)客户端创建多通道视频数据包的合并转换缓冲区;\n[0021] (2)客户端将接收到的视频数据包依照视频数据包的序号顺序放入所述合并转换缓冲区;\n[0022] (3)客户端根据丢包检测方法,检测视频数据包是否存在丢包,若检测到丢包,则对接收到的视频数据包进行容错处理,并进行丢包统计;若未检测到丢包,则按顺序对数据包进行视频合并处理;\n[0023] (4)将合并转换缓冲区中已处理的视频数据包清空,用于后续客户端接收到的视频数据包的处理。\n[0024] 优选地,所述丢包检测方法包括:客户端开启定时器,若客户端超过预设的阈值时间仍未收到相应的视频数据包,则判断视频数据包存在丢包。\n[0025] 优选地,所述丢包检测方法包括:\n[0026] (1)设定丢包检测半径DS和阈值计算函数F;\n[0027] (2)设定合并转换缓冲区中已收到的最大视频数据包的序号MAX;\n[0028] (3)检测视频数据包的序号,若序号小于丢包阈值TS的数据包未收到,则认为发生丢包,其中,所述丢包阈值TS的计算方法为TS=F(MAX,DS)。\n[0029] 优选地,所述计算函数F为线性函数,其中,F=MAX-DS。\n[0030] 优选地,所述NAT穿越包为RTSP或XML格式。\n[0031] 优选地,所述视频数据包为RTP数据包。\n[0032] 一种多通道视频流的传输系统,包括客户端以及服务器,其中,所述客户端包括视频接收模块、视频处理模块以及客户端会话模块,所述服务器包括与所述视频接收模块匹配的视频发送模块以及服务器端会话模块,所述客户端会话模块用以与服务器端会话模块完成信令的交互,并控制所述视频接收模块接收服务器发送的视频数据包,所述视频处理模块用以对所述视频接收模块接收的视频数据包进行处理,所述服务器端会话模块还控制视频发送模块向所述客户端发送视频数据包。\n[0033] 由上述本发明实施例的技术方案可以看出,本发明提供的多通道视频流的传输方法及系统具有如下优势:\n[0034] 1、客户端通过在视频请求协商过程中增加视频源验证信息来确保视频源的合法性;\n[0035] 2、对客户端通过多通道接收到的视频数据包进行有效性验证,从而可以有效的过滤掉无效的视频数据包信息。\n[0036] 鉴于以上,采用本发明实施例提供的多通道视频流的传输方法及系统可以提高视频数据包传输以及接收的可靠性。\n附图说明\n[0037] 图1是本发明一实施例提供的多通道视频流的传输方法的方法流程示意图;\n[0038] 图2是本发明一实施例提供的多通道视频流的传输系统的系统组网示意图;\n[0039] 图3是本发明一实施例提供的多通道视频流的传输系统的系统结构示意图;\n[0040] 图4是本发明一实施例提供的视频数据包合并循环队列示意图。\n[0041] 本发明目的的实现、功能特点及优异效果,下面将结合具体实施例以及附图做进一步的说明。\n具体实施方式\n[0042] 下面结合附图和具体实施例对本发明所述技术方案作进一步的详细描述,以使本领域的技术人员可以更好的理解本发明并能予以实施,但所举实施例不作为对本发明的限定。\n[0043] 依照本发明一实施例提供的多通道视频流的传输方法,如图1所示,其包括如下步骤:\n[0044] A、客户端创建视频接收模块,并分配多个数据接收通道资源;\n[0045] B、客户端向服务器发送媒体协商信息以请求视频,其中,所述媒体协商信息包括视频源验证信息以及数据接收通道资源信息;\n[0046] C、服务器接受请求并向客户端返回应答消息;\n[0047] D、客户端根据所述应答消息确认服务器接受视频请求,并向服务器发送确认消息ACK,同时打开视频接收模块;\n[0048] E、服务器收到客户端发送的确认消息ACK后,向客户端发送携带视频源验证信息和媒体同步源标识SSRC的NAT穿越包,其中,所述NAT穿越包可以为RTSP或XML格式的结构化字符串。\n[0049] F、客户端收到所述NAT穿越包之后,解析其中的视频源验证信息并进行视频源合法性验证,若验证通过,则创建客户端与服务器之间的数据链路,其中创建所述数据链路可确保视频源是客户端所要请求的视频源对象,从而防止串流;\n[0050] G、客户端解析NAT穿越包中的媒体同步源标识SSRC,若解析成功,则保存并向服务器发送NAT响应包;\n[0051] H、服务器确认收到客户端的NAT响应包后,通过多个数据发送通道向客户端发送携带了媒体同步源标识SSRC的视频数据包,若服务器未收到NAT响应包,则拒绝向客户端发送视频数据包;\n[0052] I、客户端依据接收到的视频数据包中的媒体同步源标识SSRC判断视频数据包的有效性,若媒体同步源标识SSRC合法,则对接收的视频数据包依据视频合并算法进行合并处理,否则,则丢弃相应的视频数据包。\n[0053] 具体实施方式中,在所述步骤B中,客户端通过会话初始协议(Session Initiation Protocol,SIP)向服务器请求视频,其携带的媒体协商信息可以通过会话描述协议(Session Description Protocol,SDP)表示,其中,此处所述的媒体协商信息包括视频源验证信息以及分配的数据接收通道资源信息。\n[0054] 更为具体的,所述客户端向服务器请求视频的方法,包括步骤如下:\n[0055] (1)客户端向服务器发送媒体协商信息,以描述媒体信息和客户端信息;\n[0056] (2)服务器接收到客户端发送的媒体协商信息,与自身可提供的能力相比较,若可以提供客户端所要求的媒体,则返回服务器的媒体协商信息,并接受客户端的本次媒体请求;若不能提供客户端的所有要求,则返回服务器目前所能提供的所有媒体能力,由客户端决定是否重新请求;\n[0057] (3)客户端收到服务器的媒体协商信息,若客户端媒体请求已接受,则发送确认消息;否则由客户端决定是否修改媒体协商信息并重新请求。\n[0058] 通过上述视频请求流程后,视频请求控制信令的握手交互过程已经完成。为确保视频数据包能够在私网与公网之间正确的传输,客户端和服务器之间需要进行NAT穿越操作,以使网络链路正常从而传输视频数据包。\n[0059] 对于上述的视频数据包的NAT穿越方法,包括如下步骤:\n[0060] (1)客户端向服务器发送NAT穿越数据;\n[0061] (2)服务器接收到所述NAT穿越数据,并返回NAT响应包;\n[0062] (3)若网络环境不稳定,则对1、2步骤定时循环处理。\n[0063] 通过上述NAT穿越操作,视频传输通道已经建立。为确保客户端接收的视频数据包来自合法的视频源,客户端应该对接收到的视频数据包的视频源进行合法性验证。\n[0064] 其中,视频源合法性检测方法,包括如下步骤:\n[0065] (1)客户端向服务器请求视频时,发送的媒体协商信息中添加能够唯一描述当前视频源的视频源验证信息,如视频源信息和客户端随机字符串信息的唯一组合;\n[0066] (2)服务器接收客户端发送的视频源验证信息,并保存到本地;\n[0067] (3)服务器发送媒体协商信息中的视频源验证信息到客户端;\n[0068] (4)客户端接收服务器发送的视频源验证信息,与本地保存的视频源验证信息进行比较,以确定视频源是否合法。\n[0069] 通过检测视频源的合法性仍然不能确保接收到视频流的合法性。在视频流多通道传输情况下,客户端与服务器之间存在多通道数据传输,若出现异常可能会存在悬挂通道(通道未关闭或者延迟关闭),悬挂通道可能会导致客户端接收到异常的视频数据包,因此,这里可以通过RTP数据包中存在的媒体同步源标识SSRC来判断接收到的视频数据包是否有效。\n[0070] 优选地,在所述步骤I中,判断所述媒体同步源标识是否合法的方法是,将客户端接收到的视频数据包中的媒体同步源标识与存储于客户端中的媒体同步源标识进行比较,若两者相同,则为合法,否则,则为非法。\n[0071] 更为具体地,视频数据包的有效性检测方法,包括步骤如下:\n[0072] (1)服务器在进行视频源合法性检测之后,在向客户端发送视频数据包即RTP数据包之前,创建媒体同步源标识SSRC,并保存;\n[0073] (2)服务器将创建的媒体同步源标识SSRC发送给客户端;\n[0074] (3)客户端接收媒体同步源标识SSRC并保存以作为标竿的媒体同步源标识;\n[0075] (4)服务器发送携带媒体同步源标识SSRC的RTP数据包至客户端;\n[0076] (5)客户端接收服务器发送的RTP数据包,并利用存储的标竿的媒体同步源标识与RTP数据包中携带的媒体同步源标识SSRC进行合法性检测,若两者相同,则认为RTP数据包有效;否则,对该RTP数据包丢弃。\n[0077] 从NAT穿越、视频源合法性检测和视频数据包的有效性检测过程来看,在本发明另一实施例中,可以将视频源合法性检测以及视频数据包的有效性检测与NAT穿越过程合并,即在NAT穿越时携带视频源验证信息,由客户端进行视频源合法性验证。同时在服务器发送至客户端的NAT穿越包中携带媒体同步源标识SSRC作为检验后续发送的视频数据包是否有效的标竿的媒体同步源标识。\n[0078] 优选地,在所述步骤I中,所述视频合并算法包括如下步骤:\n[0079] (1)客户端创建多通道视频数据包的合并转换缓冲区;\n[0080] (2)客户端将接收到的视频数据包依照视频数据包的序号顺序放入所述合并转换缓冲区;\n[0081] (3)客户端根据丢包检测方法,检测视频数据包是否存在丢包,若检测到丢包,则对接收到的视频数据包进行容错处理,并进行丢包统计;若未检测到丢包,则按顺序对数据包进行视频合并处理;\n[0082] (4)将合并转换缓冲区中已处理的视频数据包清空,用于后续客户端接收到的视频数据包的处理。\n[0083] 依据本发明一实施例提供的视频合并算法,在本实施例中,给出一种利用循环队列的缓冲区来实现多路RTP数据包的合并,参见图4,为本发明一实施例提供的视频数据包合并循环队列示意图,该循环队列长度L与丢包检测半径R之间的关系为:L>=R。循环队列的节点为一个三元组,其中SEQ表示RTP数据包的序号,BUF表示RTP数据包的指针,LEN表示RTP数据包的长度,其中,循环队列的空节点值为(0,NULL,0)。基于此,本RTP数据包合并算法描述如下:注意:下述算法中提到的RTP数据包的包序号不循环。\n[0084] (1)创建循环队列,队列长度为丢包检测半径;\n[0085] (2)初始化循环队列的首节点位置为0,并将其所有节点值初始化为空;\n[0086] (3)初始化最大已提交包序号为0,初始化最大已接收包序号为0;\n[0087] (4)当接收到任意通道上的RTP数据包后,进行如下处理:\n[0088] a、若包序号小于最大已提交包序号,则直接丢弃该包;\n[0089] b、若包序号大于最大已接收包序号,则更新最大已接收包序号为当前包序号;\n[0090] c、若包序号比最大已提交包序号大1,则提交客户端进行视频处理,并更新最大已提交包序号;\n[0091] d、否则按循环队列的数据包插入算法将RTP数据包缓存到循环队列;\n[0092] (5)算法结束。\n[0093] 上述的丢包检测半径,可以依照如下方法设置:\n[0094] 对于丢包检测半径,在双通道交叉传输的情况下,队列大小理论上可设为2;网络环境较好时可设置为4或者8;若不确定如何选择,则可以进行自适应调整,如当丢包率上升时,按2的幂次函数进行扩大;当丢包率下降时,按2的幂次函数进行缩小。\n[0095] 其中,循环队列的数据包插入算法可以表述如下:\n[0096] (1)计算RTP数据包的缓存位置P,其中,计算方法为:缓存位置P=收到包序号-最大已提交包序号;\n[0097] (2)若计算的缓存位置P溢出循环队列大小,且溢出值为N,则按照循环队列数据包提交算法处理本次缓冲区溢出,处理完成后转到步骤(1);否则转到步骤(3);\n[0098] (3)若缓存位置P=1,则将P直接提交给上层处理,并更新最大已提交RTP数据包的包序号;否则将RTP数据包缓存到循环队列相对于首节点位置为P的节点处,并更新该节点的值为;\n[0099] (4)算法结束。\n[0100] 其中,上述的循环队列数据包提交算法包括如下步骤:\n[0101] (1)初始化已处理的RTP数据包的数量为0;\n[0102] (2)若循环队列首节点为空节点,则将首节点设置为下一结点,将当前节点对应的RTP数据包加入丢包统计,更新最大已提交RTP数据包的包序号,更新已处理RTP数据包的数量;\n[0103] (3)若循环队列首节点为有效RTP数据包,则从首节点开始,将连续的有效RTP数据包提交给上层处理并清空已提交RTP数据包所占据的节点,直到空节点时停止,并将循环队列的首节点移到该空节点处,更新最大已提交的RTP数据包的包序号,更新已处理的RTP数据包的数量;\n[0104] (4)若已处理的RTP数据包的数量小于传入的循环队列溢出值,则转到步骤(2);\n[0105] (5)算法结束。\n[0106] 由于循环队列的RTP数据包的提交是通过不断接收新的RTP数据包来驱动的,当RTP数据包已经全部接收完毕时,对于循环队列中的最后几个RTP数据包的提交处理,可以按照如下方法处理,下述处理步骤也可称为循环队列尾包处理:\n[0107] (1)RTCP(BYE)触发:收到RTCP的BYE消息时,将队列中所有数据包提交处理。\n[0108] (2)丢弃尾包:当循环队列大小较小时,可以丢弃这些RTP数据包而不影响视频质量。\n[0109] (3)定时触发处理:主动清空循环队列中的RTP剩余数据包,但定时出发处理可能会影响效率。\n[0110] 优选地,所述丢包检测方法包括:\n[0111] (1)设定丢包检测半径DS和阈值计算函数F;\n[0112] (2)设定合并转换缓冲区中已收到的最大视频数据包的序号MAX;\n[0113] (3)检测视频数据包的序号,若序号小于丢包阈值TS的数据包未收到,则认为发生丢包,其中,所述丢包阈值TS的计算方法为TS=F(MAX,DS)。\n[0114] 优选地,所述计算函数F为线性函数,其中,F=MAX-DS。\n[0115] 如图1以及图2所示,图1为本发明一实施例提供的多通道视频流的传输系统的系统组网示意图,图2为本发明一实施例提供的多通道视频流的传输系统的系统结构示意图,所述多通道视频流的传输系统包括客户端1以及服务器,其中,所述客户端1包括视频接收模块10、视频处理模块11以及客户端会话模块12,所述服务器2包括与所述视频接收模块10匹配的视频发送模块20以及服务器端会话模块21,所述客户端会话模块12用以与服务器端会话模块21完成信令的交互,并控制所述视频接收模块10接收服务器2发送的视频数据包,所述视频处理模块11用以对所述视频接收模块10接收的视频数据包进行处理,所述服务器端会话模块21还控制视频发送模块20向所述客户端1发送视频数据包。\n其中,所述视频发送模块20可以通过多个数据发送通道向所述客户端1包括的视频接收模块10发送视频流,在具体的实施过程中,所述视频发送模块20可以提供两路数据发送通道或者更多,其对应的硬件可以为无线双卡设备或无线多卡设备,这里对所述设备的具体型号以及参数不做限制。\n[0116] 继续参照图2和图3,客户端1向服务器2请求视频可以通过会话初始协议(Session Initiation Protocol,SIP)发起请求,其携带的媒体协商信息可以通过会话描述协议(Session Description Protocol,SDP)表示,其中,所述媒体协商信息包括视频源验证信息以及分配的数据接收通道资源信息。在媒体协商信息SDP消息中,客户端1主动添加视频源验证信息。视频源验证信息可以表示为视频源信息,例如视频信息的RTSP URL,并增加客户端1随机字符串信息与所述视频源信息进行唯一组合,从而以防止唯一性冲突,若为安全考虑,还可以对验证信息进行加密处理。视频流合法性的验证方法,可以通过服务器向客户端1发送有效的RTP数据包的媒体同步源标识SSRC值作为视频流合法性标识,后续通过所有通道接收到的RTP数据包均需要和该媒体同步源标识SSRC进行比对并判断,若与之相同,则判断出数据包合法,否则非法。当收到多路合法的RTP数据包后,客户端1包括的所述视频处理模块对所述RTP数据包进行数据合并处理,从而完成多通道视频流的传输过程。\n[0117] 由上述本发明实施例的技术方案可以看出,本发明提供的多通道视频流的传输方法及系统具有如下优势:\n[0118] 1、客户端1通过在视频请求协商过程中增加视频源验证信息来确保视频源的合法性;\n[0119] 2、对客户端1通过多通道接收到的视频数据包进行有效性验证,从而可以有效的过滤掉无效的视频数据包信息。\n[0120] 鉴于以上,采用本发明实施例提供的多通道视频流的传输方法及系统可以提高视频数据包传输以及接收的可靠性。\n[0121] 以上所述仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。
法律信息
- 2013-03-27
- 2011-12-14
实质审查的生效
IPC(主分类): H04N 21/647
专利申请号: 201110148239.X
申请日: 2011.06.02
- 2011-11-02
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2008-12-24
|
2008-07-31
| | |
2
| |
2009-06-03
|
2007-11-28
| | |
3
| |
2007-08-01
|
2006-01-23
| | |
4
| |
2005-11-09
|
2005-06-28
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |