一种基于websocket的视频实时监视方法及系统与流程

文档序号:28055646发布日期:2021-12-17 22:09阅读:372来源:国知局
一种基于websocket的视频实时监视方法及系统与流程

1.本发明属于视频监视技术领域,具体涉及一种基于websocket的视频实时监视方法及系统。


背景技术:

2.视频实时监视是很多工业生产、公共安全等领域的重要应用,b/s架构具有使用方便、灵活,不需要客户端安装特定软件的优点。然后随着adobe公司的flash插件退出历史舞台,浏览器实时视频流往往需要利用定制的特定厂家插件来实现,背离了b/s架构的客户端无需安装特定软件的优点,用户体验不佳。目前存在一些无插件解决方案,但是对于实时浏览的场景,其存在实时性能不足的问题。


技术实现要素:

3.为解决现有技术中的不足,本发明提供一种基于websocket的视频实时监视方法及系统,能实时进行播放策略调整,解决了实时浏览的场景实时性能不足的问题。
4.为达到上述目的,本发明所采用的技术方案是:
5.第一方面,提供一种基于websocket的视频实时监视方法,浏览器与视频服务器之间通过websocket通信,方法由浏览器执行,包括:分别请求主码流视频和辅码流视频;播放主码流视频,同时按照设定的时间周期计算主码流视频的播放延迟时间;当主码流视频的播放延迟时间大于第一阈值时,跳过部分帧继续播放主码流视频;当主码流视频的播放延迟时间小于第一阈值时,播放辅码流视频并重新请求主码流视频,当重新请求的主码流视频满足设定条件后,重新播放主码流视频。
6.进一步地,所述主码流视频和辅码流视频均在其头部添加视频服务器当前采集到的实时视频的时标。
7.进一步地,浏览器与视频服务器之间的通信采用应用控制的滑动窗口管理,即浏览器端代码在任意时刻,都维持一个连续的允许发送的帧的序号,称为发送窗口;同时,视频服务器端也维持了一个连续的允许接收的帧的序号,称为接收窗口;视频服务器端在发完一个数据帧后,不停下来等待应答帧,而是连续发送k1个数据帧后等待浏览器端确认;同时视频服务器端在每一帧报文内部均填入视频服务器端的本机当前时标t
s
;当浏览器端代码接收到视频服务器端的数据帧超过k2个数据帧(k2≤k1)时,回复已收到数据帧的序号到服务器端;视频服务器端接收到浏览器端的数据帧应答帧,计算已确认数据帧和已发送数据帧的差值,当差值大于零时,继续发送差值个数的帧;接收端保持一个已接收到的码流缓冲区,并记录当前收到的发送端发送的最后一帧报文的本机时间t
clast
和最后一帧报文内存储的时标t
slast

8.进一步地,播放主码流视频前,先将主码流视频转换为fmp4格式,包括建立fmp4播放头,fmp4播放头中的moovbox部分包含每秒播放的h.264帧数。
9.进一步地,所述设定的第一阈值时间周期为2秒。
10.进一步地,所述计算主码流视频的播放延迟时间t
play
的方法为:
11.t
play
=t
diff

t
d0

t
skip
12.t
diff
=t
slast

t
clast
13.t
d0
=t
s0

t
c0
14.其中,t
slast
表示当前收到的发送端发送的最后一帧报文内存储的时标,t
diff
表示当前收到的发送端发送的最后一帧报文与浏览器端接收的最后一帧报文内存储的时标的差值,t
clast
表示当前收到的发送端发送的最后一帧报文的本机时间,t
d0
表示浏览器本地时标与服务器端时标的差值,即浏览器端连接上服务端后,websocket接收到的第一帧报文内的视频服务器端的本机时标t
s0
与接收到第一帧报文的浏览器端本机时标t
c0
的差值,t
skip
表示已跳过播放时长。
15.进一步地,所述当主码流视频的播放延迟时间大于第一阈值时,跳过部分帧继续播放主码流视频,具体为:在已接收的缓冲区中,寻找到最新的i帧报文,从最新的i帧报文开始播放,同时根据之前最后播放的帧序号至最新的i帧报文的帧序号差值更新已跳过播放时长t
skip
=已跳过的帧数/每秒h.264帧数。
16.进一步地,所述当主码流视频的播放延迟时间小于第一阈值时,播放辅码流视频并重新请求主码流视频,当重新请求的主码流视频满足设定条件后,重新播放主码流视频,具体为:将播放主码流视频切换为播放辅码流视频,同时强制断开主码流视频的请求,而后重新请求主码流视频,同时,抛弃辅码流视频的历史部分,从辅码流视频的最新i帧开始重新构建辅码流视频的fmp4头,从而播放h.264辅码流视频,通过降低清晰度保证视频实时性;与此同时,对重新请求的主码流视频,当重新请求的主码流视频满足设定条件后,重新播放主码流视频。
17.进一步地,所述设定条件为:主码流视频稳定时间持续20秒以上。
18.第二方面,提供一种基于websocket的视频实时监视系统,浏览器与视频服务器之间通过websocket通信,浏览器包括:第一模块,用于分别请求主码流视频和辅码流视频;第二模块,用于播放主码流视频,同时按照设定的时间周期计算主码流视频的播放延迟时间;第三模块,用于当主码流视频的播放延迟时间大于第一阈值时,跳过部分帧继续播放主码流视频;第四模块,用于当主码流视频的播放延迟时间小于第一阈值时,播放辅码流视频并重新请求主码流视频,当重新请求的主码流视频满足设定条件后,重新播放主码流视频。
19.与现有技术相比,本发明所达到的有益效果:本发明通过按照设定的时间周期计算主码流视频的播放延迟时间;当主码流视频的播放延迟时间大于第一阈值时,跳过部分帧继续播放主码流视频;当主码流视频的播放延迟时间小于第一阈值时,播放辅码流视频并重新请求主码流视频,当重新请求的主码流视频满足设定条件后,重新播放主码流视频;利用浏览器应用层滑动窗口通信方式及同时多路websocket连接承载不同清晰度码流荷载,通过服务器、客户机时标计算播放延迟,进行实时播放策略调整,解决了实时监视应用场景下实时性能不足的问题。
附图说明
20.图1是本发明实施例提供的一种基于websocket的视频实时监视方法的主要流程示意图。
具体实施方式
21.下面结合附图对本发明作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案,而不能以此来限制本发明的保护范围。
22.实施例一:
23.如图1所示,一种基于websocket的视频实时监视方法,浏览器与视频服务器之间通过websocket通信,方法由浏览器执行,包括:分别请求主码流视频和辅码流视频;播放主码流视频,同时按照设定的时间周期计算主码流视频的播放延迟时间;当主码流视频的播放延迟时间大于第一阈值时,跳过部分帧继续播放主码流视频;当主码流视频的播放延迟时间小于第一阈值时,播放辅码流视频并重新请求主码流视频,当重新请求的主码流视频满足设定条件后,重新播放主码流视频。
24.在b/s架构进行视频实时监控应用时,采用websocket技术进行实时视频流推送方式可以实现免浏览器插件播放实时视频功能,但是由于websocket技术基于tcp协议,且网络存在通信延迟,波动等情况,会导致采用此种监视手段的视频播放内容实时性逐渐降低;
25.为解决此问题,本实施例具体采用以下技术方案:
26.a)视频服务器同时获取视频摄像头或视频通信设备传输的主码流视频和辅码流视频;
27.b)视频服务器将主码流视频和辅码流视频中的视频h.264信号抽取出来;
28.c)视频服务器实时计算每秒h.264(isom)码流的帧数;
29.d)web浏览器加载的html页面中引用或嵌入了视频处理和信号连接代码。
30.浏览器端代码逻辑为:
31.分别请求主码流视频和辅码流视频;
32.(1)浏览器生成2路websocket链接,链接至视频服务器,一路websocket链接请求主码流视频,(下称websocket链接1)、另一路请求辅码流视频(下称websocket链接2),主码流视频和辅码流视频均在其头部添加视频服务器当前采集到的实时视频的最新时标(至少精确到0.5秒);
33.(2)视频服务器与web浏览器间通过websocket通信,在websocket内承载的信息包括时间头信息、帧序号和视频码流(包括主码流视频和辅码流视频);
34.(3)两路websocket链接与视频服务器间的通信采用应用控制的滑动窗口管理,即浏览器端代码在任意时刻,都维持一个连续的允许发送的帧的序号,称为发送窗口;同时,视频服务器端也维持了一个连续的允许接收的帧的序号,称为接收窗口。在发送方在发完一个数据帧后,不停下来等待应答帧,而是连续发送k1(k1≤9)个数据帧;浏览器端代码接收到视频服务器端的数据帧超过k2,(k2≤k1)时(一般取),后信息回复即使在连续发送过程中收到了接收方发来的应答帧,也可以继续发送。其中k1的选择为0.1~0.5秒时间的视频流的报文帧数目(具体数值可根据实际网络情况调优)。接收端保持一个已接收到的码流缓冲区,并记录当前收到的发送端发送的最后一帧报文的本机时间t
clast
和最后一帧报文内存储的时标t
slast

35.播放主码流视频,同时按照设定的时间周期计算主码流视频的播放延迟时间;
36.(4)首次链接上视频服务器后,记录运行浏览器的计算机时间t
c0
;记录码流头部的
服务器时标t
s0
当前时间;计算t
c
、t
s
的时间差t
d0
=t
s0

t
c0

37.(5)首先将视频服务器的主视频流转换为fmp4格式,包括建立fmp4播放头,特别的播放头中的moovbox部分包含每秒播放的h.264帧数,该帧数由视频服务器提供;
38.(6)设置已跳过播放时长的初始值t
skip
=0;
39.(7)获取当前最后收到的码流中的头部信息获取的服务器当前时标t
s
;计算当前播放时长与已传输的报文可播放的时长的差,即主码流视频的播放延迟时间,t
play
的方法为:
40.t
play
=t
diff

t
d0

t
skip
41.t
diff
=t
slast

t
clast
42.t
d0
=t
s0

t
c0
43.其中,t
slast
表示当前收到的发送端发送的最后一帧报文内存储的时标,t
diff
表示当前收到的发送端发送的最后一帧报文与浏览器端接收的最后一帧报文内存储的时标的差值,t
clast
表示当前收到的发送端发送的最后一帧报文的本机时间,t
d0
表示初始连接时浏览器本地时标与服务器端时标的差值,即浏览器端连接上服务端后,websocket接收到的第一帧报文内的视频服务器端的本机时标t
s0
与接收到第一帧报文的浏览器端本机时标t
c0
的差值,t
skip
表示已跳过播放时长。
44.当主码流视频的播放延迟时间大于第一阈值时,跳过部分帧继续播放主码流视频;
45.本实施例中,第一阈值设置为2秒,当t
play
>2秒时,表示浏览器端出现渲染卡顿等可能,这时执行如下操作:在已接收的缓冲区中,寻找到最新的i帧报文,从最新的i帧报文开始播放,同时根据之前最后播放的帧序号至最新的i帧报文的帧序号差值更新已跳过播放时长t
skip
=已跳过的帧数
÷
每秒h.264帧数。
46.当主码流视频的播放延迟时间小于第一阈值时,播放辅码流视频并重新请求主码流视频,当重新请求的主码流视频满足设定条件后,重新播放主码流视频;
47.当t
play
<2秒时,将播放码流切换至辅码流视频,同时强制断开websocket链接1,而后重新链接websocket,再次连接视频服务器获取主码流视频,形成新的websocket链接1;于此同时,抛弃辅码流视频的历史部分,从辅码流视频最新i帧开始重新构建辅码流视频fmp4头,从而播放h.264辅码流视频,通过降低清晰度保证视频实时性;与此同时,对重新链接上的websocket链接1,计算t
d0
,依次顺序按照上述步骤(6)、步骤(7)处理,并计算t
play
=t
diff

t
d0

t
skip
,当t
play
>1秒,且稳定一定时间(实践中配置为20秒以上),表示网络拥塞降低,切换至主码流,重新按主码流播放,跳至步骤(4)开始继续执行。
48.本实施例通过按照设定的时间周期计算主码流视频的播放延迟时间;当主码流视频的播放延迟时间大于第一阈值时,跳过部分帧继续播放主码流视频;当主码流视频的播放延迟时间小于第一阈值时,播放辅码流视频并重新请求主码流视频,当重新请求的主码流视频满足设定条件后,重新播放主码流视频;利用浏览器应用层滑动窗口通信方式及同时多路websocket连接承载不同清晰度码流荷载,通过服务器、客户机时标计算播放延迟,能实时进行播放策略调整,解决了实时浏览的场景实时性能不足的问题。
49.实施例二:
50.基于实施例一所述的基于websocket的视频实时监视方法,本实施例提供一种基
于websocket的视频实时监视系统,浏览器与视频服务器之间通过websocket通信,浏览器包括:
51.第一模块,用于分别请求主码流视频和辅码流视频;
52.第二模块,用于播放主码流视频,同时按照设定的时间周期计算主码流视频的播放延迟时间;
53.第三模块,用于当主码流视频的播放延迟时间大于第一阈值时,跳过部分帧继续播放主码流视频;
54.第四模块,用于当主码流视频的播放延迟时间小于第一阈值时,播放辅码流视频并重新请求主码流视频,当重新请求的主码流视频满足设定条件后,重新播放主码流视频。
55.以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明技术原理的前提下,还可以做出若干改进和变形,这些改进和变形也应视为本发明的保护范围。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1