CN112135199A - 基于多类型视频源的视频播放方法及相关设备 - Google Patents

Abstract

本发明涉及大数据技术领域，提供一种基于多类型视频源的视频播放方法及相关设备，该方法包括：接收点击指令；通过指定散点对应的商户标识码，从数据库中获取视频列表，并向后台服务器发送携带有视频列表的视频流地址获取请求；接收视频流地址；判断目标传输协议是否为超文本传输HTTP协议；若目标传输协议为HTTP协议，使用视频流地址，向后台服务器发送视频资源获取请求；根据返回信息，轮询判断视频流地址对应的视频资源是否准备齐全；若齐全，加载添加有视频流地址的目标传输协议对应的播放器组件，并执行播放操作。本发明可应用在智慧家居、智慧社区以及智慧生活等需要进行视频处理的领域，从而推动智慧城市的发展。

Description

基于多类型视频源的视频播放方法及相关设备

技术领域

本发明涉及大数据技术领域，尤其涉及一种基于多类型视频源的视频播放方法及相关设备。

背景技术

随着浏览器功能的提升，视频播放功能也日益强大。实践中发现，视频源存在多种形式，比如实时消息传输协议RTMP、实时流传输协议RTSP、超文本传输协议HTTP。

然而实践中发现，由于业务需求存在播放协议改变或视频供应商有多个的风险，导致前端开发的页面不能同时兼容多种形式的视频源，使得视频播放兼容性问题尤为凸显，严重影响了客户满意度。

因此，如何实现前端界面的多种形式的视频源的兼容是一个亟待解决的技术问题。

发明内容

鉴于以上内容，有必要提供一种基于多类型视频源的视频播放方法及相关设备，能够实现前端界面的多种形式的视频源的兼容。

本发明的第一方面提供一种基于多类型视频源的视频播放方法，所述方法包括：

接收用户针对前端界面的指定散点触发的点击指令；

响应所述点击指令，通过所述指定散点对应的商户标识码，从数据库中获取视频列表，并向后台服务器发送携带有所述视频列表的视频流地址获取请求；

接收所述后台服务器返回的视频流地址；

判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议；

若所述目标传输协议为HTTP协议，使用所述视频流地址，向所述后台服务器发送视频资源获取请求；

根据针对所述视频资源获取请求接收到的返回信息，轮询判断所述视频流地址对应的视频资源是否准备齐全；

若所述视频流地址对应的视频资源准备齐全，加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

在一种可能的实现方式中，所述判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议包括：

获取针对传输协议预设的多个正则表达式；

根据每个所述正则表达式以及所述视频流地址，生成多个测试语句；

执行多个所述测试语句，获得多个布尔值；

根据多个所述布尔值，判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议。

在一种可能的实现方式中，所述判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议包括：

根据所述视频流地址，生成配置文件语句；

根据预设的多个传输协议，生成多个索引语句；

执行所述配置文件语句以及所述多个索引语句，获得返回值；

根据所述返回值，判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议。

在一种可能的实现方式中，所述基于多类型视频源的视频播放方法还包括：

在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，在所述前端界面上的层叠样式表CSS上添加默认图片蒙层；在所述默认图片蒙层上显示预设的提示语句；或

在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，加载预设格式的静态视频资源；或

在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，统计轮询失败的次数；若所述次数达到预设次数阈值，停止轮询判断操作，并显示预设按钮。

在一种可能的实现方式中，所述基于多类型视频源的视频播放方法还包括：

若所述目标传输协议为实时消息传输协议RTMP或实时流传输协议RTSP，将所述视频流地址添加至所述目标传输协议对应的播放器组件；

加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

在一种可能的实现方式中，所述基于多类型视频源的视频播放方法还包括：

若所述目标传输协议不属于所述HTTP协议、所述RTMP协议以及所述RTSP协议中的任一种，将所述视频流地址添加至预设的播放器组件，并加载添加有所述视频流地址的所述预设的播放器组件；

若所述预设的播放器组件无法播放，获取静态视频资源；

使用所述预设的播放器组件，播放所述静态视频资源。

在一种可能的实现方式中，所述基于多类型视频源的视频播放方法还包括：

接收针对所述前端界面上的多屏中的第一屏的切换指令；

确定所述第一屏的第一类名；

将所述第一屏的第一类名与指定的第二屏的第二类名进行对调；

基于对调后的屏，执行视频播放。

本发明的第二方面提供一种视频播放装置，所述视频播放装置包括：

传输模块，用于接收用户针对前端界面的指定散点触发的点击指令；

获取模块，用于响应所述点击指令，通过所述指定散点对应的商户标识码，从数据库中获取视频列表；

所述传输模块，还用于向后台服务器发送携带有所述视频列表的视频流地址获取请求；

所述传输模块，还用于接收所述后台服务器返回的视频流地址；

判断模块，用于判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议；

所述传输模块，还用于若所述目标传输协议为HTTP协议，使用所述视频流地址，向所述后台服务器发送视频资源获取请求；

判断模块，用于根据针对所述视频资源获取请求接收到的返回信息，轮询判断所述视频流地址对应的视频资源是否准备齐全；

加载执行模块，用于若所述视频流地址对应的视频资源准备齐全，加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

本发明的第三方面提供一种电子设备，所述电子设备包括处理器和存储器，所述处理器用于执行所述存储器中存储的计算机程序时实现所述的基于多类型视频源的视频播放方法。

本发明的第四方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现所述的基于多类型视频源的视频播放方法。

由以上技术方案可知，本发明可应用在智慧家居、智慧社区以及智慧生活等需要进行视频处理的领域，从而推动智慧城市的发展。本发明中，在接收到后台服务器返回的视频流地址后，可以先判断该视频流地址属于何种类型的视频源，进而将该视频流地址添加到与该类型匹配的播放器中，并加载该播放器，从而实现了不同形式的视频源的兼容问题，避免在生产环境中视频流不确定导致系统需要重构的风险，同时，优化了HTTP视频切片问题，缓解后台对视频切片的压力，提高了前端播放视频的稳定性。

附图说明

图1是本发明公开的一种基于多类型视频源的视频播放方法的较佳实施例的流程图。

图2是本发明公开的一种视频播放装置的较佳实施例的功能模块图。

图3是本发明实现基于多类型视频源的视频播放方法的较佳实施例的电子设备的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在本发明中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。

其中，后台服务器可以是指能对网络中其它设备(如电子设备)提供服务的计算机系统。如果一个个人电脑能够对外提供文件传输协议(File Transfer Protocol，简称FTP)服务，也可以叫服务器。从狭义范围上讲，服务器专指某些高性能计算机，能通过网络，对外提供服务，其相对于普通的个人电脑来说，稳定性、安全性、性能等方面都要求更高，因此在CPU、芯片组、内存、磁盘系统、网络等硬件和普通的个人电脑有所不同。

所述电子设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、数字信号处理器(DSP)、嵌入式设备等。所述电子设备还可包括网络设备和/或用户设备。其中，所述网络设备包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(Cloud Computing)的由大量主机或网络服务器构成的云。所述用户设备包括但不限于任何一种可与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互的电子产品，例如，个人计算机、平板电脑、智能手机、个人数字助理PDA等。

请参见图1，图1是本发明公开的一种基于多类型视频源的视频播放方法的较佳实施例的流程图。其中，根据不同的需求，该流程图中步骤的顺序可以改变，某些步骤可以省略。

S11、接收用户针对前端界面的指定散点触发的点击指令。

其中，在前端页面的可视化地图区域中，预先展示了区域散点集合，每个散点包含了商户信息(比如名称、许可证编号、法人等)。

S12、响应所述点击指令，通过所述指定散点对应的商户标识码，从数据库中获取视频列表，并向后台服务器发送携带有所述视频列表的视频流地址获取请求。

其中，用户通过手动点击指定散点发起ajax请求(即视频流地址获取请求)，将该指定散点对应的商户标识码(比如许可证编号)传向后台服务器。

需要注意的是，由于数据库未录入等原因，散点可能没有相关信息，在发起视频流地址获取请求前，还需要校验散点是否含有商户标识码，若没有，则输出用于提示散点缺少关键信息的提示信息，取消该视频流地址获取请求；若有，则向数据库请求该商户标识码下的视频列表，此视频列表预先存入数据库中。

S13、接收所述后台服务器返回的视频流地址。

其中，在直播和点播情况下，视频流地址并不是一成不变的，为了隐私及安全考虑，每次获取视频流地址都是由后台服务器通过一定的规则组装而成。

视频流地址的组装规则可以自定义，为了通过视频流地址更好的识别出指定的资源，一般是以协议+域名+端口号+区域id(全国行政区划id)+散点识别代码(商户许可证编号)+指定视频id值+当前时间戳组成。这样，在某些视频异常或卡滞情况下，前端界面能够直接通过该视频流地址的链接通知到具体哪个视频终端出现问题，方便后续的维护。

S14、判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议。

其中，实现直播和点播的协议有RTMP(Real Time Messaging Protocol，实时消息传输协议)、RTSP(Real Time Streaming Protocol，实时流传输协议)、HTTP(HyperTextTransfer Protocol，超文本传输协议)，一般做直播用RTMP、RTSP，做点播用HTTP。其中RTMP又有RTMPE和RTMPS加密协议，但其视频流地址都属于同一种类型。

举例来说，RTMP的视频流地址通常为：

rtmp://live.hkstv.hk.lxdns.com/live/hks。

RTSP的视频流地址通常为：rtsp://218.204.223.237:554/live/1/66251FC11353191F/e7ooqwcfbqjoo80j.sdp。

HTTP的视频流地址通常为：

http://live.hkstv.hk.lxdns.com/live/hks/playlist.m3u8。

上面三种为常规的直播流链接地址，从中可以看都是以其协议名称作为开头。同时，HTTP协议链接请求的是m3u8文件，m3u8作为结尾该类型协议的结尾关键字。

具体的，所述判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议包括：

获取针对传输协议预设的多个正则表达式；

根据每个所述正则表达式以及所述视频流地址，生成多个测试语句；

执行多个所述测试语句，获得多个布尔值；

根据多个所述布尔值，判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议。

在该可选的实施方式中，预先可以针对每个不同的传输协议预设正则表达式，并基于每个所述正则表达式以及所述视频流地址，生成多个测试语句。其中，可以采用js中test方法，生成多个测试语句。test方法检查字符串是否与给出的正则表达式模式相匹配，如果是则返回true，否则就返回false。

比如：针对rtmp/rtsp传输协议，测试语句为：

var flag＝/rtmp|rtsp/.test(rtmp://live.hkstv.hk.lxdns.com/live/hks)，其中，/rtmp|rtsp/为正则表达式。

又比如：针对http传输协议，测试语句为：

var flag1＝/http|m3u8/.test(http://live.hkstv.hk.lxdns.com/live/hks/playlist.m3u8)，其中，/http|m3u8/为正则表达式。

执行测试语句后，如果返回的布尔值为true，表明检查的字符串与给出的正则表达式模式相匹配，而正则表达式是根据传输协议预设的，因此，可以根据返回的布尔值来识别视频流地址对应的目标传输协议，从而也可以判断该目标传输协议是否属于HTTP协议。

具体的，所述判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议包括：

根据所述视频流地址，生成配置文件语句；

根据预设的多个传输协议，生成多个索引语句；

执行所述配置文件语句以及所述多个索引语句，获得返回值；

根据所述返回值，判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议。

在该可选的实施方式中，预先可以采用js中indexOf方法，根据预设的多个传输协议，生成多个索引语句。其中，js中indexOf方法可以对视频流地址进行全局搜索，分别对视频流地址进行两种协议的关键字的搜索，若关键字匹配成功，则返回一个数字下标(即协议关键字所在的位置索引)，从而判断属于何种协议，如果匹配失败，则返回-1。

比如var index＝str.indexOf(“rtmp”)；

var index2＝str.indexOf(“http”)。

进一步地，在获取到视频流地址后，可以根据所述视频流地址，生成配置文件语句，比如var str＝“rtmp://live.hkstv.hk.lxdns.com/live/hks”，并执行所述配置文件语句以及所述多个索引语句，获得返回值，通常，如果匹配成功，则返回索引语句中的协议在配置文件语句中的索引位置，如果匹配失败，则返回-1。

本发明中，能够兼容不同协议的视频流，避免在生产环境中视频流不确定导致系统需要重构的风险。

S15、若所述目标传输协议为HTTP协议，使用所述视频流地址，向所述后台服务器发送视频资源获取请求。

其中，HTTP协议请求的是m3u8文件，m3u8格式的直播视频需要被分割成若干个数据包进行异步传输。如果后台服务器还未对视频流进行切片分包处理，即视频资源还未准备好，会导致播放器初始化失败的同时播放也失败。

为了避免这种情况，获取到视频流地址后，不用立马将视频流地址放入播放器中，而是使用所述视频流地址，向所述后台服务器发送视频资源获取请求(即ajax的get请求)，验证视频切片是否成功，以判断后台服务器是否准备好资源。

S16、根据针对所述视频资源获取请求接收到的返回信息，轮询判断所述视频流地址对应的视频资源是否准备齐全。

其中，如果当后台服务器的视频资源的切片未准备好，请求失败，将会返回404代码的返回信息，如果后台服务器的视频资源的切片准备好，请求成功，将会返回200代码，通过返回信息，可以判断视频流地址对应的视频资源是否准备齐全。

通过该方式，可以优化HTTP视频切片问题，缓解后台服务器对视频切片的压力，提高了前端播放视频的稳定性。

S17、若所述视频流地址对应的视频资源准备齐全，加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

具体的，可以将所述视频流地址添加至播放器组件的src中，其中，src为播放器组件的配置属性。通常，HTTP协议对应的播放器组件为Dplayer或Muplayer。

可选的，在步骤S16之后，所述方法还包括：

在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，在所述前端界面上的层叠样式表CSS上添加默认图片蒙层；在所述默认图片蒙层上显示预设的提示语句；或

在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，加载预设格式的静态视频资源；或

在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，统计轮询失败的次数；若所述次数达到预设次数阈值，停止轮询判断操作，并显示预设按钮。

在该可选的实施方式中，前端界面在不断轮询校验视频是否切片成功的过程中，页面长期处于等候状态，此时会出现黑屏，而用户无法知道系统是否异常。在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，可以在校验过渡时期，执行上述实施方式，以提高用户体验。

其中，Dplayer或Muplayer播放器中都有defaultUrl默认连接配置，前端可以预先配置一个MP4格式的静态视频资源，在校验过程中默认播放此资源，待校验成功之后，再切换至直播资源进行播放。此外，若校验请求一直返回404代码信息，视频校验的轮询递归将一直请求下去，会消耗浏览器内存。因此前端配置了计次器count，每次轮询失败再继续执行轮询都会+1，当count到达预设次数阈值(即递归轮询次数，比如50次)，则return跳出轮询，停止校验。此时页面可以显示一个点播按钮，随用户意愿再次触发校验轮询请求，从而可以节省浏览器内存，提高用户体验。

可选的，所述方法还包括：

若所述目标传输协议为实时消息传输协议RTMP或实时流传输协议RTSP，将所述视频流地址添加至所述目标传输协议对应的播放器组件；

加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

在该可选的实施方式中，所述目标传输协议为实时消息传输协议RTMP或实时流传输协议RTSP，通常，RTMP或RTSP对应的播放器组件为VXGplayer或Videojs配合Videojs-flashjs。

可选的，所述方法还包括：

若所述目标传输协议不属于所述HTTP协议、所述RTMP协议以及所述RTSP协议中的任一种，将所述视频流地址添加至预设的播放器组件，并加载添加有所述视频流地址的所述预设的播放器组件；

若所述预设的播放器组件无法播放，获取静态视频资源；

使用所述预设的播放器组件，播放所述静态视频资源。

在该可选的实施方式中，按照播放模式来说，可以分为基于Flash模式的播放器组件(VXGplayer、Videojs)和非Flash模式的播放器组件(Dplayer或Muplayer)。可以预先设置预设的播放器组件为上述两种类型的播放器组件。

当前端识别出所述目标传输协议不属于所述HTTP协议、所述RTMP协议以及所述RTSP协议中的任一种时，可以依次将所述视频流地址添加至预设的播放器组件，并加载添加有所述视频流地址的所述预设的播放器组件，如果加载失败，无法播放，则可以获取静态视频资源，使用所述预设的播放器组件，播放所述静态视频资源，从而解决绝大部分视频流协议的播放问题。

可选的，所述方法还包括：

接收针对所述前端界面上的多屏中的第一屏的切换指令；

确定所述第一屏的第一类名；

将所述第一屏的第一类名与指定的第二屏的第二类名进行对调；

基于对调后的屏，执行视频播放。

在该可选的实施方式中，前端界面被切分为多个屏(通常一个中屏和多个小屏)，多个屏上的多路视频同时播放，用户双击中屏时可以切换至全屏播放该中屏对应的路视频，其他小屏单击后，可与中屏的播放窗口切换。其中，该第一屏可以为任意一个小屏，第二屏可以为中屏。

在播放窗口切换的过程中，播放器的过渡效果一直处于黑屏状态，而且重新请求资源需要耗费一定的初始化等待时间。为了在切换窗口时避免断流现象，可利用前端css样式固定每个窗口，每个窗口自带类名比如：.media__box--0、.media__box--1、.media__box--2、.media__box--3、.media__box--4，这些类名都采用前端相对定位形式，固定大小及位置。在用户点击小屏时，将此小屏的类名“.media__box--x”与中屏类名“.media__box--0”对调，此时，因窗口携带类名的切换，其样式也会随之改变，从而达到视觉上窗口内容对调的方式，该实施方式，只改变前端dom结构，不影响到每个播放器的播放进程，从而能够避免播放器处于黑屏状态，避免在切换窗口时出现断流现象。

通过该实施方式，可以根据用户的需求进行定制化处理，提高用户的视频观看体验。

可选的，所述方法还包括：

接收针对所述前端界面上的多屏中的第一屏的第一点击指令；

响应所述第一点击指令，将所述第一屏的公共开关的状态设置为第一标识，并将所述第一屏与指定的第二屏进行窗口切换；

在接收到针对所述第一屏的第二点击指令时，判断所述公共开关的状态是否由所述第一标识更新为第二标识；

若所述公共开关的状态保持所述第一标识不变，保持所述第一屏与所述第二屏进行窗口切换后的窗口状态。

在该可选的实施方式中，由于每个窗口都绑定了双击全屏事件和单击切换屏幕事件，在双击小窗口时，系统检测是两次单击功能，也就是走了两次单击切换事件而无法实现切换窗口功能。该实施方式中，可以设置一个公共开关flag，第一次点击时改变flag状态为true，并通过setTimeout()方法设置延时器，在延时器执行后把flag状态改为false。当第二次点击，如果该第二次点击与第一次点击的时间间隔很短，则延时器还没执行，flag状态仍然为true时则退出逻辑，这样就起到第二次窗口切换的过滤效果，能够在小屏和中屏之间有效地进行窗口切换功能。

可选的，所述方法还包括：

接收针对所述前端界面上的多屏中的目标屏的双击指令；

获取所述目标屏的类名；

判断所述目标屏的类名是否为具备全屏显示功能的预设类名；

若所述目标屏的类名为具备全屏显示功能的预设类名，对所述目标屏执行全屏显示操作。

在该可选的实施方式中，由于每个窗口都绑定了双击全屏事件和单击切换屏幕事件，只有双击中屏才能全屏显示，而双击小屏是不能全屏显示的。因此，在接收针对所述前端界面上的多屏中的目标屏的双击指令时，可以判断所述目标屏的类名是否为具备全屏显示功能的预设类名，比如中屏的类名.media__box--0，如果所述目标屏的类名为具备全屏显示功能的预设类名，则可以确定是中屏触发双击事件，对所述目标屏执行全屏显示操作，反之，如果所述目标屏的类名不为具备全屏显示功能的预设类名，则可以确定是小屏触发双击事件，跳出全屏显示逻辑。通过该实施方式，可以更好地实现只双击中屏实现全屏显示功能，过滤掉双击小屏的事件。

在图1所描述的方法流程中，在接收到后台服务器返回的视频流地址后，可以先判断该视频流地址属于何种类型的视频源，进而将该视频流地址添加到与该类型匹配的播放器中，并加载该播放器，从而实现了不同形式的视频源的兼容问题，避免在生产环境中视频流不确定导致系统需要重构的风险，同时，优化了HTTP视频切片问题，缓解后台对视频切片的压力，提高了前端播放视频的稳定性。

由以上实施例可知，本发明可应用在智慧家居、智慧社区以及智慧生活等需要进行视频处理的领域，从而推动智慧城市的发展。以上所述，仅是本发明的具体实施方式，但本发明的保护范围并不局限于此，对于本领域的普通技术人员来说，在不脱离本发明创造构思的前提下，还可以做出改进，但这些均属于本发明的保护范围。

请参见图2，图2是本发明公开的一种视频播放装置的较佳实施例的功能模块图。

在一些实施例中，所述视频播放装置运行于电子设备中。所述视频播放装置可以包括多个由程序代码段所组成的功能模块。所述视频播放装置中的各个程序段的程序代码可以存储于存储器中，并由至少一个处理器所执行，以执行图1所描述的基于多类型视频源的视频播放方法中的部分或全部步骤，具体请参考图1中的相关描述，在此不再赘述。

本实施例中，所述视频播放装置根据其所执行的功能，可以被划分为多个功能模块。所述功能模块可以包括：传输模块201、获取模块202、判断模块203及加载执行模块204。本发明所称的模块是指一种能够被至少一个处理器所执行并且能够完成固定功能的一系列计算机程序段，其存储在存储器中。

传输模块201，用于接收用户针对前端界面的指定散点触发的点击指令。

获取模块202，用于响应所述点击指令，通过所述指定散点对应的商户标识码，从数据库中获取视频列表。

所述传输模块201，还用于向后台服务器发送携带有所述视频列表的视频流地址获取请求。

所述传输模块201，还用于接收所述后台服务器返回的视频流地址。

判断模块203，用于判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议。

所述传输模块201，还用于若所述目标传输协议为HTTP协议，使用所述视频流地址，向所述后台服务器发送视频资源获取请求。

所述判断模块203，还用于根据针对所述视频资源获取请求接收到的返回信息，轮询判断所述视频流地址对应的视频资源是否准备齐全。

加载执行模块204，用于若所述视频流地址对应的视频资源准备齐全，加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

在图2所描述的视频播放装置中，在接收到后台服务器返回的视频流地址后，可以先判断该视频流地址属于何种类型的视频源，进而将该视频流地址添加到与该类型匹配的播放器中，并加载该播放器，从而实现了不同形式的视频源的兼容问题，避免在生产环境中视频流不确定导致系统需要重构的风险，同时，优化了HTTP视频切片问题，缓解后台对视频切片的压力，提高了前端播放视频的稳定性。

如图3所示，图3是本发明实现基于多类型视频源的视频播放方法的较佳实施例的电子设备的结构示意图。所述电子设备3包括存储器31、至少一个处理器32、存储在所述存储器31中并可在所述至少一个处理器32上运行的计算机程序33及至少一条通讯总线34。

本领域技术人员可以理解，图3所示的示意图仅仅是所述电子设备3的示例，并不构成对所述电子设备3的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述电子设备3还可以包括输入输出设备、网络接入设备等。

所述至少一个处理器32可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。该处理器32可以是微处理器或者该处理器32也可以是任何常规的处理器等，所述处理器32是所述电子设备3的控制中心，利用各种接口和线路连接整个电子设备3的各个部分。

所述存储器31可用于存储所述计算机程序33和/或模块/单元，所述处理器32通过运行或执行存储在所述存储器31内的计算机程序和/或模块/单元，以及调用存储在存储器31内的数据，实现所述电子设备3的各种功能。所述存储器31可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据电子设备3的使用所创建的数据(比如音频数据)等。此外，存储器31可以包括非易失性和易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他存储器件。

结合图1，所述电子设备3中的所述存储器31存储多个指令以实现一种基于多类型视频源的视频播放方法，所述处理器32可执行所述多个指令从而实现：

接收用户针对前端界面的指定散点触发的点击指令；

响应所述点击指令，通过所述指定散点对应的商户标识码，从数据库中获取视频列表，并向后台服务器发送携带有所述视频列表的视频流地址获取请求；

接收所述后台服务器返回的视频流地址；

判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议；

若所述目标传输协议为HTTP协议，使用所述视频流地址，向所述后台服务器发送视频资源获取请求；

根据针对所述视频资源获取请求接收到的返回信息，轮询判断所述视频流地址对应的视频资源是否准备齐全；

若所述视频流地址对应的视频资源准备齐全，加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

具体地，所述处理器32对上述指令的具体实现方法可参考图1对应实施例中相关步骤的描述，在此不赘述。

在图3所描述的电子设备3中，在接收到后台服务器返回的视频流地址后，可以先判断该视频流地址属于何种类型的视频源，进而将该视频流地址添加到与该类型匹配的播放器中，并加载该播放器，从而实现了不同形式的视频源的兼容问题，避免在生产环境中视频流不确定导致系统需要重构的风险，同时，优化了HTTP视频切片问题，缓解后台对视频切片的压力，提高了前端播放视频的稳定性。

所述电子设备3集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器以及只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)。

在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附关联图标记视为限制所涉及的权利要求。系统权利要求中陈述的多个单元或装置也可以通过软件或者硬件来实现。

最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神和范围。

Claims (10)

1.一种基于多类型视频源的视频播放方法，其特征在于，所述基于多类型视频源的视频播放方法包括：

接收用户针对前端界面的指定散点触发的点击指令；

响应所述点击指令，通过所述指定散点对应的商户标识码，从数据库中获取视频列表，并向后台服务器发送携带有所述视频列表的视频流地址获取请求；

接收所述后台服务器返回的视频流地址；

判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议；

若所述目标传输协议为HTTP协议，使用所述视频流地址，向所述后台服务器发送视频资源获取请求；

根据针对所述视频资源获取请求接收到的返回信息，轮询判断所述视频流地址对应的视频资源是否准备齐全；

若所述视频流地址对应的视频资源准备齐全，加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

2.根据权利要求1所述的基于多类型视频源的视频播放方法，其特征在于，所述判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议包括：

获取针对传输协议预设的多个正则表达式；

根据每个所述正则表达式以及所述视频流地址，生成多个测试语句；

执行多个所述测试语句，获得多个布尔值；

根据多个所述布尔值，判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议。

3.根据权利要求1所述的基于多类型视频源的视频播放方法，其特征在于，所述判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议包括：

根据所述视频流地址，生成配置文件语句；

根据预设的多个传输协议，生成多个索引语句；

执行所述配置文件语句以及所述多个索引语句，获得返回值；

根据所述返回值，判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议。

4.根据权利要求1所述的基于多类型视频源的视频播放方法，其特征在于，所述基于多类型视频源的视频播放方法还包括：

在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，在所述前端界面上的层叠样式表CSS上添加默认图片蒙层；在所述默认图片蒙层上显示预设的提示语句；或

在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，加载预设格式的静态视频资源；或

在轮询判断所述视频流地址对应的视频资源未准备齐全的过程中，统计轮询失败的次数；若所述次数达到预设次数阈值，停止轮询判断操作，并显示预设按钮。

5.根据权利要求1所述的基于多类型视频源的视频播放方法，其特征在于，所述基于多类型视频源的视频播放方法还包括：

若所述目标传输协议为实时消息传输协议RTMP或实时流传输协议RTSP，将所述视频流地址添加至所述目标传输协议对应的播放器组件；

加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

6.根据权利要求1所述的基于多类型视频源的视频播放方法，其特征在于，所述基于多类型视频源的视频播放方法还包括：

若所述目标传输协议不属于所述HTTP协议、所述RTMP协议以及所述RTSP协议中的任一种，将所述视频流地址添加至预设的播放器组件，并加载添加有所述视频流地址的所述预设的播放器组件；

若所述预设的播放器组件无法播放，获取静态视频资源；

使用所述预设的播放器组件，播放所述静态视频资源。

7.根据权利要求1所述的基于多类型视频源的视频播放方法，其特征在于，所述基于多类型视频源的视频播放方法还包括：

接收针对所述前端界面上的多屏中的第一屏的切换指令；

确定所述第一屏的第一类名；

将所述第一屏的第一类名与指定的第二屏的第二类名进行对调；

基于对调后的屏，执行视频播放。

8.一种视频播放装置，其特征在于，所述视频播放装置包括：

传输模块，用于接收用户针对前端界面的指定散点触发的点击指令；

获取模块，用于响应所述点击指令，通过所述指定散点对应的商户标识码，从数据库中获取视频列表；

所述传输模块，还用于向后台服务器发送携带有所述视频列表的视频流地址获取请求；

所述传输模块，还用于接收所述后台服务器返回的视频流地址；

判断模块，用于判断所述视频流地址对应的目标传输协议是否为超文本传输HTTP协议；

所述传输模块，还用于若所述目标传输协议为HTTP协议，使用所述视频流地址，向所述后台服务器发送视频资源获取请求；

所述判断模块，还用于根据针对所述视频资源获取请求接收到的返回信息，轮询判断所述视频流地址对应的视频资源是否准备齐全；

加载执行模块，用于若所述视频流地址对应的视频资源准备齐全，加载添加有所述视频流地址的所述目标传输协议对应的播放器组件，并执行播放操作。

9.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，所述处理器用于执行存储器中存储的计算机程序以实现如权利要求1至7中任意一项所述的基于多类型视频源的视频播放方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有至少一个指令，所述至少一个指令被处理器执行时实现如权利要求1至7任意一项所述的基于多类型视频源的视频播放方法。

Images