阅读说明：本技术 视频播放方法、装置及计算机设备 (Video playing method and device and computer equipment ) 是由 彭浩 于 2019-08-13 设计创作，主要内容包括：本申请实施例提供了一种视频播放方法,对于需要加载的待播放的多个视频文件,在其中的任一视频文件(记为第一视频文件)加载或播放过程中,可以对与其相邻播放的视频文件(记为第二视频文件)进行预加载,从而利用该第一视频文件的属性信息(如播放进度、最后一帧图像的播放时间等),获取第二视频文件的起始播放时间,相对于直接利用未分段的整个视频文件的总时长的分割点,确定分段后的各视频文件的起始播放时间,本申请提高了各视频文件的起始播放时间的准确性,这样按照各视频文件的起始播放时间,实现多个视频文件的无缝拼接播放,保证了整个视频播放过程的流畅性。(The embodiment of the application provides a video playing method, which comprises the steps of for a plurality of video files to be played which need to be loaded, during the loading or playing process of any video file (marked as a first video file), the video file (marked as a second video file) played adjacent to the video file can be preloaded, therefore, the method and the device utilize the attribute information (such as playing progress, playing time of the last frame image and the like) of the first video file to obtain the initial playing time of the second video file, and compared with the method and the device which directly utilize the dividing point of the total time length of the whole video file which is not divided to determine the initial playing time of each divided video file, the method and the device improve the accuracy of the initial playing time of each video file, therefore, seamless splicing playing of a plurality of video files is realized according to the initial playing time of each video file, and the smoothness of the whole video playing process is ensured.)

视频播放方法、装置及计算机设备

技术领域

本申请涉及通信技术领域，更具体的说，是涉及一种视频播放方法、装置及计算机设备。

背景技术

随着计算机技术及多媒体技术的发展，目前的浏览器可以不用安装专用插件，就能够实现音视频文件的播放，为如提供视频点播业务等视频网站提供了很大便利。其中，在视频文件的加载播放过程中，可以采用视频分段加载并播放的方式，避免在播放之前出现长时间的缓冲时间，降低用户观看视频感受。

然而，现有的多个视频文件播放过程中，通常是对整个视频文件的总时长分割，确定出各视频文件的起始播放时间，这往往会出现播放卡顿、闪屏等问题，降低了分段后的多个视频文件的播放流畅性。

发明内容

有鉴于此，本申请提供了一种视频播放方法、装置及计算机设备，将在加载或播放一个视频文件时，利用该视频文件的属性信息，确定出下一个视频文件的起始播放时间，实现了多个视频文件之间的无缝拼接播放，保证了视频播放流畅性。

为实现上述目的，本申请提出了一种视频播放方法，所述方法包括：

确定待播放的多个视频文件；

在第一视频文件加载或播放过程中，对第二视频文件进行预加载，并利用所述第一视频文件的属性信息，得到所述第二视频文件的起始播放时间；其中，所述第一视频文件和所述第二视频文件是所述多个视频文件中任意相邻播放的两个视频文件，且第二视频文件与所述第一视频文件的最后一帧图像相衔接；

按照所述第二视频文件的起始播放时间，从所述第一视频文件切换到所述第二视频文件播放。

可选的，所述利用所述第一视频文件的属性信息，得到所述第二视频文件的起始播放时间，包括：

对所述第一视频文件的头文件进行解析，得到所述第一视频文件的最后一帧图像的播放时间及第一起始播放时间；

利用所述第一视频文件的最后一帧图像的播放时间，对所述第一起始播放时间进行偏移累加，得到第二视频文件的第二起始播放时间。

可选的，所述在第一视频文件加载或播放过程中，对第二视频文件进行预加载，并利用所述第一视频文件的属性信息，得到所述第二视频文件的起始播放时间，播放所述第二视频文件，包括：

预先激活第一视频文件和第二视频文件；

在当前播放窗口播放所述第一视频文件，并监测所述第一视频文件的播放进度；

若所述播放进度满足预设条件，对所述第二视频文件进行预加载；

在所述第一视频文件播放结束时，在所述当前播放窗口播放所述第二视频文件中已加载的视频数据；

其中，在所述第一视频文件播放结束之前，后台输出所述第二视频文件中的至少一帧图像。

可选的，在所述对所述第二视频文件进行预加载过程中，所述方法还包括：

将所述第二视频文件的第二视频标签的显示属性切换为隐藏状态，输出所述第二视频文件的至少一帧图像；

所述在所述第一视频文件播放结束时，在所述当前播放窗口播放所述第二视频文件中已加载的视频数据，包括：

在所述第一视频文件播放结束时，将所述第一视频文件的第一视频标签的显示属性从所述显示状态切换为所述隐藏状态，并将所述第二视频标签的显示属性从所述隐藏状态切换为显示状态，以使所述当前播放窗口播放所述第二视频文件中已加载的视频数据；

其中，视频标签的显示属性为隐藏状态是指相应视频文件的播放窗口的高和宽均为0，且处于静音状态下输出。

本申请实施例还提供了一种视频播放装置，所述装置包括：

视频文件确定模块，用于确定待播放的多个视频文件；

起始播放时间获取模块，用于在第一视频文件加载或播放过程中，对第二视频文件进行预加载，并利用所述第一视频文件的属性信息，得到所述第二视频文件的起始播放时间；其中，所述第一视频文件和所述第二视频文件是所述多个视频文件中任意相邻播放的两个视频文件，且第二视频文件与所述第一视频文件的最后一帧图像相衔接；

视频播放模块，用于按照所述第二视频文件的起始播放时间，播放所述第二视频文件。

本申请实施例还提供了一种计算机设备，所述计算机设备包括：

通信接口，用于接收视频源服务器发送的视频文件；

存储器，用于存储实现如上所述的视频播放方法的程序；

处理器，用于加载并执行所述存储器存储的程序，实现如上所述的视频播放方法的各步骤。

经由上述的技术方案可知，与现有技术相比，本申请实施例提供了一种视频播放方法，对于需要加载的待播放的多个视频文件，在其中的任一视频文件(记为第一视频文件)加载或播放过程中，可以对与其相邻播放的视频文件(记为第二视频文件)进行预加载，从而利用该第一视频文件的属性信息(如播放进度、最后一帧图像的播放时间等)，获取第二视频文件的起始播放时间，相对于直接利用未分段的整个视频文件的总时长的分割点，确定分段后的各视频文件的起始播放时间，本申请提高了各视频文件的起始播放时间的准确性，这样按照各视频文件的起始播放时间，实现多个视频文件的无缝拼接播放，保证了整个视频播放过程的流畅性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为实现本申请提供的视频播放方法的系统结构示意图；

图2为本申请提供的视频播放方法的一种可选示例的流程图；

图3为本申请提供的视频播放方法的又一种可选示例的流程图；

图4为本申请提供的视频播放方法中，数据缓存空间记录多个视频流文件的示意图；

图5为本申请提供的视频播放方法的又一种可选示例的流程图；

图6为本申请提供的视频播放方法中，多个视频标签的切换方法的示意图；

图7为本申请提供的视频播放方法的又一种可选示例的流程图；

图8为本申请提供的视频播放装置的一种可选示例的结构图；

图9为本申请提供的视频播放装置的又一种可选示例的结构图；

图10为本申请提供的视频播放装置的又一种可选示例的结构图；

图11为本申请实施例提供的一种计算机设备的硬件结构示意图。

具体实施方式

结合上文背景技术部分的描述，现有的视频播放方法，是因无法做到不同视频文件之间的无缝拼接播放，导致不同视频文件切换播放时，出现短暂的卡顿、闪屏等异常情况，影响整个视频播放过程的流畅性。所以，本申请希望做到多个视频文件之间的无缝拼接，以保证视频播放过程的流畅性。

经过研究注意到，市面上的浏览器类型很多，不同类型的浏览器所能够支持的视频播放标准可能不同，如MSE(Media Source Extension，媒体源扩展)标准，并不是所有的浏览器都支持MSE标准，本申请可以将浏览器分为支持MSE标准的第一客户端，以及不支持MSE标准的第二客户端，但并不局限于这种分类方式。

其中，MSE标准提供了可以让开发者精准控制缓存时间、媒体指令、内存释放的接口，开发者可以使用Mediasource(媒体资源)对象替换视频(video)标签的src(source，源)属性，该src属性规定了要播放的视频的URL(Uniform Resource Locator，统一资源定位符)，并且，可以创建多个SourceBuffer(源缓冲区，即一个用来存放流的容器)对象，来渐进式往video标签中添加数据，具体添加过程不做详述。

在实际应用中，对于支持MSE标准的浏览器，可以使用fmp4转封装的方式播放视频，对于不支持MSE标准的浏览器，可以采用多个视频文件对应的多个video标签切换的方式进行视频播放。所以，对于这两种类型的浏览器，实现多个视频文件的无缝拼接播放的过程中，需要结合该类型浏览器采用的视频播放模式对应的视频加载方式实现，具体实现过程可以参照下文相应实施例的描述。

其中，无论是哪种视频播放模式，本申请提出在加载或播放一个视频文件时，对下一个视频文件进行预加载，并利用此时加载的该视频文件的属性信息，确定出该下一个视频文件的起始播放时间，相对于直接利用分段前的整个视频文件的总时长的分割点，确定各视频文件的起始播放时间，大大提高了分段后的各视频文件的起始播放时间的准确性，进而保证了多个视频文件的无缝拼接播放。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参照图1，为实现本申请提出的视频播放方法的系统架构图，该系统可以包括至少一个客户端11及至少一个流媒体服务器12，其中：

客户端11可以是用户使用的终端设备安装的应用程序，如浏览器，用户可以通过浏览器登录某视频播放网站，如各种视频点播/直播网站等，本申请对客户端11的类型不做限定。

在实际应用中，对于同一流媒体资源，可能会由多个视频网站共享，也就是说，多个客户端11都可以播放同一视频文件，用户可以根据自己喜好，选择观看视频所使用的客户端。因此，该系统可以包括多个不同类型的客户端，如图1所示的客户端1、客户端2、…等等，但并不局限于图1所示的系统架构。

流媒体服务器12可以是提供流媒体数据的服务设备，可以与上述客户端11相匹配，为该客户端提供其能够播放的各视频文件的流媒体数据，因此，对于不同类型的客户端，为其提供流媒体数据的流媒体服务器可能不同，在客户端包括多个不同类型的客户端的情况下，系统可以包括相应类型的流媒体服务器，本申请对该流媒体服务器类型及工作过程不做详述。

其中，对于不同类型的流媒体服务器相互之间可以通信，以使得客户端1通过流媒体服务器1，从流媒体服务器2下载流媒体数据进行播放，实现同一视频文件的跨应用平台播放，但并不局限于本实施例描述的这种实现方式。

应该理解的是，在本申请实际应用中，本实施例提出的系统架构并不局限于图1示出的结构组成，根据需要还可以包括浏览器服务器，以使网页客户端通过浏览器服务器，获取相应流媒体服务器发送的流媒体数据等等；还可以包括数据服务器，用来记录视频播放过程中产生的各种中间数据，如视频下载记录等等，可以根据实际需要进行配置，本申请不再一一详述。

结合上图1示出的系统架构，参照图2，示出了本申请提出的视频播放方法的一种可选示例流程图，该方法可以应用于终端设备，具体是该终端设备的客户端，本申请中该客户端主要指网页客户端，适用于通过浏览器播放视频的场景，如图2所示，该方法可以包括但并不局限于以下步骤：

步骤S11，获取客户端运行环境信息；

步骤S12，选择与该客户端运行环境信息匹配的目标视频播放模式；

结合上文的描述，对于视频播放所用的MSE标准，并不是所有的浏览器环境都能够支持，对于支持MSE标准的浏览器，可以按照该MSE标准对从流媒体服务器获取的视频文件进行处理，将得到数据流渐进式添加到video标签中，再进行video标签切换播放视频；而对于不支持MSE标准的浏览器，直接从流媒体服务器获取video，直接进行video标签切换播放视频。可见，对于不同类型浏览器实现视频播放所采用的方式是不同的。

因此，在播放多个视频文件之前，可以先检测浏览器环境，确定其是否支持MSE标准，再决定采用哪种视频播放模式，对从流媒体服务器下载的视频文件进行处理。基于此，获取的客户端运行环境信息可以包括客户端配置信息，主要是可以表明该客户端是否支持MSE标准的信息，本申请对具体的信息内容不做限定。

可选的，本申请可以预先建立不同客户端运行环境信息，与不同视频播放模式的对应关系，如对应关系表等，这样，在获取当前用户所使用的客户端运行环境信息后，可以按照该对应关系，即可得到与客户端运行环境信息匹配的视频播放模式，本申请对步骤S12的具体实现方式不作限定。

步骤S13，执行该目标视频播放模式，确定待播放的多个视频文件；

步骤S14，在第一视频文件加载或播放过程中，对第二视频文件进行预加载，并利用第一视频文件的属性信息，得到第二视频文件的起始播放时间；

步骤S15，按照该第二视频文件的起始播放时间，从第一视频文件切换到第二视频文件播放。

其中，第一视频文件可以是从视频源服务器加载的任意一个视频文件，第二视频文件是指与第一视频文件的最后一帧图像相衔接的视频文件。也就是说，第一视频文件和第二视频文件是待播放的多个视频文件中，任意两个相邻播放的视频文件，本申请仅以第一视频文件和第二视频文件为例，说明相邻播放的两个视频文件如何实现无缝拼接播放，对于其他相邻的任意两个视频文件的无缝拼接处理过程类似，本申请不做一一详述。

另外，上述第一视频文件的属性信息可以是第一视频文件的最后一帧图像的播放时间，也可以是第一视频文件的播放进度等参数，具体可以依据当前客户端运行环境确定，即依据所选择的目标视频播放模式确定，可以参照下文实施例相应部分的描述。

结合上文分析，针对不同客户端运行环境，如不同浏览器环境，所适配的目标视频播放模式不同，可以记为第一视频播放模式、第二视频播放模式等，从而使本申请提供的视频播放方法能够适用于多种浏览器环境，扩大了使用范围。

其中，第一视频播放模式可以是MSE播放模式，第二视频播放模式可以是视频标签(即video标签)播放模式，在本申请中，MSE播放模式可以适用于将一个视频拆分成多个视频文件的场景，可以采用渐进式加载这多个视频文件，并利用前一个视频文件的最后一帧图像的播放时间，对视频起始播放时间进行不断累加偏移，得到当前加载的视频文件(即与前一个视频文件相邻播放的视频文件)的起始播放时间，在此基础上累加当前加载的视频文件的最后一帧图像的播放时间，得到下一个视频文件的起始播放时间，依次类推，可以得到多个视频文件各自的起始播放时间，从而按照起始播放时间，实现多个视频文件的无缝拼接播放。

这种情况下，视频文件的起始播放时间可以是起始DTS时间(baseMediaDecodeTime，基本媒体解码时间)，本申请对获取该DTS时间的具体方法不做限定。

对于video标签播放模式，可以适用于多个视频互动播放的场景，但并不局限于此，通常能够预先得知待播放的多个视频文件各自的视频标签，本申请可以采用预加载的方式，并通过调整进行播放切换的两个视频文件的视频标签的显示属性，实现多个视频文件的无缝拼接播放。

关于按照这两种视频播放模式，实现多个视频文件无缝拼接播放的具体实现过程，可以参照下文相应实施例的描述，但并不局限于下文实施例描述的实现方式，可以根据实际需求进行灵活适当调整，本申请不做一一详述。

由此可见，本申请能够保证用户使用的各种类型的客户端播放视频，能够自动选择合适的视频播放模式，实现视频的边加载边播放，且在播放多个视频文件的过程中，本申请是在加载或播放第一视频文件，预加载第二视频文件过程中，利用第一视频文件的属性信息(如播放进度、最后一帧图像的播放时间等)，得到第二视频文件的起始播放时间，相对于传统方案中直接利用未分段的整个视频文件的总时长的分割点，确定分段后的各视频文件的起始播放时间的方法，大大提高了各视频文件的起始播放时间的准确性，这样按照各视频文件的起始播放时间，实现了多个视频文件的无缝拼接播放，保证了整个视频播放过程的流畅性，即解决了现有的视频分段加载播放的过程中，经常会出现的卡顿、闪屏等问题。

下面将针对支持MSE标准的客户端运行环境，客户端执行第一视频播放模式，实现多个视频文件无缝拼接播放的过程进行描述，如图3，示出了本申请提出的视频播放方法的另一可选示例的流程图，该方法的各步骤可以由客户端执行，具体可以包括但并不局限于以下步骤：

步骤S21，向视频源服务器发送视频分段加载请求；

步骤S22，按照渐进式加载方式，从该视频源服务器加载多个视频文件；

本实施例中，使用MSE标准播放视频，可以采用渐进式加载方式，即分段式渐进加载，如将一个完整的视频文件切分成多个小的视频文件，然后，按照每个视频文件的下载地址及播放顺序，依次下载，再进行播放。

其中，本申请可以利用一个加载窗口实现视频文件的加载，可以预先对该加载窗口配置一个最大缓冲数据阀值，以及驱动数据继续加载的偏移指针，本申请对如何利用加载窗口的缓冲数据阀值和偏移指针，实现多个视频文件的加载过程不做详述。

且上述加载的多个视频文件可以是与目标视频标签关联的视频文件，该目标视频标签可以是当前浏览器页面的标签，本申请对多个视频文件的内容不做限定。

步骤S23，对加载的第一视频文件的头文件进行解析，得到第一视频配置信息；

对于从视频源服务器加载的视频文件通常是mp4(一套用于音频、视频信息的压缩编码标准)格式的文件，按照MSE实现视频流播放的原理，需要将mp4格式的视频文件，转换为fmp4(fragment mp4)格式的视频流文件，fmp4格式是一种使用h.264/AAC编码的视频格式，其区别于non-fragment-mp4文件，fmp4将视频文件分割成多个视频文件，可以更方便的做渐进式加载和自适应播放，本申请对fmp4格式视频文件的处理过程不做限定，并不局限于下文描述的处理方式。

由于从视频源服务器加载的mp4文件的视频配置信息，通常记录在其头文件(moov)中，因此，在视频加载过程中，可以对加载的第一视频文件(待播放的多个视频文件中的任一视频文件)的头文件进行解析时，得到本次加载的第一视频文件的第一视频配置信息，如音视频信息、视频的各帧信息，具体如视频文件的宽高、时长、码率、编码格式、帧列表、关键帧列表，以及所对应的时戳和在文件中的位置等等，本申请对视频配置信息的内容不做限定。

步骤S24，利用该第一视频配置信息，得到第一视频文件的最后一帧图像的播放时间及第一起始播放时间；

步骤S25，由第一视频配置信息及第一起始播放时间，拼装得到第一视频流头文件；步骤S26，利用第一视频文件的最后一帧图像的播放时间，对第一起始播放时间进行偏移累加，得到第二视频文件的第二起始播放时间，以写入第二视频文件对应的第二视频流头文件；

其中，第一视频文件可以是从视频源服务器加载的任意一个视频文件，第二视频文件是指与第一视频文件的最后一帧图像相衔接的视频文件。本申请仅对第一视频文件和第二视频文件这两个相邻的视频文件，如何实现无缝拼接为例进行说明，对于其他相邻的任意两个视频文件的无缝拼接处理过程类似，本申请不做一一详述。

视频流头文件可以是标准fmp4格式的头文件，本申请对其拼装方式不作限定，本实施例中，对于加载的每个视频文件的头文件，需要按照上述方式拼装成fmp4格式的头文件，不再一一详述。

本实施例中，为了保证该视频文件与其相邻播放的下一个视频文件之间的无缝拼接播放，可以依据该视频文件的最后一帧图像的播放时间，通过累加起始偏移时间的方式，得到相邻下一个视频文件的起始播放时间。具体可以采用但并不局限于如下代码实现：

lastDts(n)＝getLastDts(boxes stsz)；

startDts(n)＝startDts(n-1)+lastDts(n-1)；

其中，lastDts(n)可以表示第n个视频文件的最后一帧图像的播放时间，即DTS时间(baseMediaDecodeTime，基本媒体播放时间)，利用get()函数从mp4文件的头文件中获取，具体实现过程不做详述。startDts(n)可以表示第n个视频文件的起始播放时间，也就是该视频文件n的第一帧图像的编码时间。由上述计算代码可知，其可以利用相邻的上一个视频文件(n-1)的最后一帧图像的播放时间lastDts(n-1)，及第一帧图像的播放时间startDts(n-1)求和得到，也就是说，在相邻的上一个视频文件(n-1)的起始播放时间startDts(n-1)基础上，偏移了最后一帧图像的播放时间lastDts(n-1)，得到了该视频文件n的起始播放时间。

基于此，可以按照startDts(n+1)＝startDts(n)+lastDts(n)这种计算方式，得到与当前加载的视频文件n相邻的下一个视频文件n+1的起始播放时间。可见，本申请在解析当前加载的某一视频文件的过程中，就确定出加载相邻的下一个视频文件的起始播放时间后，在解析该下一个视频文件的头文件，并将其拼装成对应的标准的fmp4的头文件(即initialization segments)时，可以将得到的该下一个视频文件的起始播放时间写入其头文件中，具体拼装方式可以依据mp4与fmp4之间的区别确定，本申请不做详述。

因此，在得到第二视频文件的第二起始播放时间后，可以按照上文描述的方式，对第二视频文件的头文件进行解析，得到第二视频配置信息，再由其拼装成第二视频流头文件，同时将第二起始播放时间写入该第二视频流头文件中，如此，可以利用第二视频文件的最后一帧图像的播放时间，累加得到第三视频文件(即与第二视频文件的最后一帧图像相衔接的视频文件)的第三起始播放时间，以此类推，可以得到多个视频文件各自的起始播放时间，并添加至对应的视频流头文件中，本申请不再一一详述。

步骤S27，将加载的视频文件的视频数据转封装成相应的视频流文件，并将相应的视频流头文件添加至该视频流文件中；

步骤S28，将该视频流文件写入任务队列；

按照上述方式完成不同mp4格式到fmp4格式的头文件的转换后，可以根据关键帧间隔，将从视频源服务器下载的原始mp4数据(即一视频文件中的s视频数据)转封装成fmp4格式的视频流文件(即media segments)，fmp4封装方法不做详述。

对于从视频源服务器渐进式下载的视频文件，按照上述处理方式得到相应的视频流文件后，可以写入一个padding队列(填充队列)即本实施例的任务队列，本申请对该padding队列的数据写入/读取过程，可以依据队列的数据读写原理确定，本申请不做详述。

步骤S29，从该任务队列中依次读取存储的视频流文件，写入与目标视频标签关联的数据缓存空间；

本实施例中，在从视频源服务器渐进式加载视频文件过程中，每一个视频文件均可以按照上文描述的方式进行转封装处理，得到相应的视频流文件，并依次写入padding队列，以使得MSE可以直接从该padding队列获取视频流片段，增补(append)至视频标签(video标签)关联的数据缓存空间中。

这样，MSE可以从padding队列不断获取视频流数据作为新的待播放视频文件，padding队列中空闲出的位置将会不断写入新加载的视频流文件，保证视频的不间断播放。

其中，video标签属于超文本标记语言html5中的一种标签定义，用于播放(加载)视频，本申请对传统视频播放中对video标签的应用方法，以及html5视频在浏览器的播放过程不做详述。

需要说明，获取多个视频文件各自的起始播放时间，并处理成相应的视频流文件，写入目标视频标签的数据缓存空间的过程中，可以在某一个视频文件的视频流文件成功写入数据缓存空间中，再对加载的下一个视频文件进行处理，依次类推，渐进式得到各视频文件的视频流文件；当然，在上述不同阶段的处理过程中，如截止到写入任务队列的过程，可以是将多个视频文件的视频流文件写入任务队列中，再写入数据缓存区等等，也就是说，本申请对将加载的多个视频文件的视频流文件写入数据缓存空间过程中，各视频文件的处理时间间隔不做限定，可以同步也可以一个一个处理，或者间隔预设时间处理等等，本申请不做一一详述。

步骤S210，按照该数据缓存空间已缓存的视频流文件的起始播放时间，播放相应视频流文件。

依据上文分析，本实施例能够得到各视频流文件(即各fmp4格式的视频文件)的起始播放时间，MSE可以将SourceBuffer(源缓冲区)的mode设置为“segment(片段)”。其中，mode这一字段决定了视频文件是怎样进行播放的，其取值通常为segment或sequence序列，segment可以表示视频播放时，根据视频流中的视频播放时间pts(本实施例指上述起始播放时间)来确定，本申请对mode的设置方法不做限定。

这样，上述数据缓存空间已缓存的各视频流文件，可以按照如图4所示的方式缓存，即按照起始播放时间的大小，确定各视频流文件(如图4中的stream0、stream1、streamp等等)的存储顺序及播放顺序，保证相邻播放的两个视频流文件之间的无缝拼接，给用户的观看感受就是在观看一个已加载的完整视频，保证了视频播放流畅性，且本申请采用渐进式加载方式，相对于直接加载完整视频后才能够播放的方式，减少了用户等待时间。

在实际应用中，某些浏览器是不支持MSE标准的视频播放的，对于这类浏览器客户端，本申请具体可以采用以下方式实现多个视频文件的无缝拼接播放，保证视频播放的流畅性，但并不局限于本实施例描述的这种视频播放方式。具体可以参照图5示出的本申请提供的视频播放方法的又一可选示例的流程图，该方法可以包括：

步骤S31，预先激活第一视频文件和第二视频文件；

其中，第一视频文件可以是用户会先播放的视频文件，第二视频文件可以是继续播放的视频文件，即与第一视频文件的最后一帧图像相衔接的视频文件，也就是说，第一视频文件和第二视频文件是将要播放的任意两个相邻播放的视频文件。

在实际应用中，客户端通常需要预先确定有哪些视频文件可用于用户的播放，可以将这些视频文件按照顺序预先激活。例如，在使用浏览器页面播放视频的场景下，每一个视频文件可以配置一个视频标签，其包含了该视频文件的下载地址URL，浏览器可以对该视频标签进行预先激活，以获取该视频标签对应的视频文件。

步骤S32，在当前播放窗口播放第一视频文件，并监测第一视频文件的播放进度；

在本实施例实际应用中，对于在当前显示界面播放的视频文件，可以通过将其视频标签的显示状态切换为显示状态，如图6所示，可以将该视频标签的显示属性中播放窗口的宽高比例切换为1:1，如宽width＝100％，高height＝100％，或者是其他比例的满屏状态，从而使该视频文件在浏览器页面中显示出来，即在当前处于满屏状态的播放窗口播放第一视频文件。

步骤S33，在该播放进度满足预设条件，对第二视频文件进行预加载，得到缓存的视频数据；

由于本申请需要实现多个视频文件的无缝拼接播放，因此，在播放第一视频文件过程中，可以对其播放进度进行监控，该播放进度可以是播放时长、播放时间比等，以便在其将要播放结束或播放到某个时长或某时间比等，及时对将要相邻播放的第二视频文件进行预加载。

可见，上述预设条件可以是视频文件的当前播放时长是否达到预设播放时长、当前播放时间比是否达到预设时间比等，可以依据该播放进度的具体内容确定，本申请对该预设条件的内容不做限定。

依据上述分析，本申请可以不用同时加载多个视频文件，而是在一个视频文件快要播放结束之前，再对另一个相邻的视频文件进行预加载，这样，在不影响无缝拼接播放的效果同时，避免了同时加载多个视频文件，影响当前播放的视频文件的播放效果，如播放卡顿等。

步骤S34，将第二视频文件的第二视频标签的显示属性切换为隐藏状态，输出第二视频文件的至少一帧图像；

步骤S35，在第一视频文件播放结束时，将第一视频文件的第一视频标签的显示属性从显示状态切换为隐藏状态，并将第二视频文件的第二视频标签的显示属性从隐藏状态切换为显示状态，以使当前播放窗口播放第二视频文件的已缓存的视频数据。

继上文分析，将视频文件的视频标签的显示属性切换为隐藏状态，可以是将该显示属性的中宽高比例切换为0，如将播放视频文件的播放窗口的高和宽均设置为0，容量也为0，从而使该视频文件在浏览器页面中隐藏起来，同时，还可以设置该视频文件处于静音状态下输出，其视频标签设置为0x0，即对于后台预加载的视频文件，将从0x0起始地址开始采用静音状态输出；相对应的，将视频文件的视频标签的显示属性切换为显示状态，可以是该显示属性的中宽高比例切换为1，即播放窗口的高和宽均可以为100％(但并不局限于这一设置)，从而使前台播放的视频文件铺满播放器的样式输出。

本实施例中，在对第二视频文件进行预加载过程中，可以在后台静默播放已缓存的视频数据，即在其视频标签的显示属性切换为隐藏状态的情况下，播放第二视频文件已缓存的视频数据，并不会影响用户对当前播放窗口播放视频的观看。

在前台播放的第一视频文件播放结束时，可以将后台播放的第二视频文件的第二视频标签切换为铺满状态，即将其显示属性切换为显示状态，从而使当前显示界面对已缓存的第二视频文件进行视频播放，与此同时，可以将当前已播放完毕的第一视频文件的第一视频标签切回后台，即使其隐藏起来并处于静音状态，同时会按照上述方式，后台会继续加载并静默播放第三视频文件，依次类推，实现多个视频文件的无缝拼接播放，第三视频文件是与第二视频文件的最后一帧图像衔接的视频文件。

可选的，在实际应用中，为了保证后台看到预缓存的视频文件的视频标签的画面后才进行切换，在对不同视频文件的视频标签的显示属性进行切换之前，可以先验证将要播放的视频文件是否已经成功加载，若否，继续等待其加载，若是，再按照本实施例描述的方式进行加载，具体过程可以参照但并不局限于图7示出的流程图。

在图7中，前台video可以指上述第一视频文件、后台video可以指上述第二视频文件，结合上文实施例的描述，第一视频文件在前台播放playing时，可以由后台对开始预加载第二视频文件，并播放至少一帧图像，使其播放时间playtime大于0，将暂停播放(如执行pause()函数)，等待第一视频文件播放完毕playover，或者用户触发播放下一个视频的操作playNext，前台可以先检测后台的第二视频文件是否准备好，如果没有，等待后台预加载的第二视频文件播放至少一帧图像，即后台视频文件准备好后，前台将从第一视频文件切换到第二视频文件播放。其中，检测后台的第二视频文件是否准备好，可以将后台发送请求seek，若反馈seeked(ready)，可以认为后台第二视频文件已经准备好。

由此可见，本实施例按照上述方式实现多个视频标签切换，实现了多个视频文件的无缝拼接播放，使得用户感官上视频的衔接无卡顿、闪烁等现象。

参照图8，为本申请提供的视频播放装置的一种可选实例的流程图，该装置可以应用于计算机设备，如终端设备，该装置可以包括：

视频确定模块21，用于确定待播放的多个视频文件；

起始播放时间获取模块22，用于在第一视频文件加载或播放过程中，对第二视频文件进行预加载，并利用所述第一视频文件的属性信息，得到所述第二视频文件的起始播放时间；其中，所述第一视频文件和所述第二视频文件是所述多个视频文件中任意相邻播放的两个视频文件，且第二视频文件与所述第一视频文件的最后一帧图像相衔接；

视频播放模块23，用于按照所述第二视频文件的起始播放时间，播放所述第二视频文件。

可选的，如图9所示，该起始播放时间获取模块22可以包括：

文件解析单元2211，用于对所述第一视频文件的头文件进行解析，得到所述第一视频文件的最后一帧图像的播放时间及第一起始播放时间；

起始播放时间获取单元2212，用于利用所述第一视频文件的最后一帧图像的播放时间，对所述第一起始播放时间进行偏移累加，得到第二视频文件的第二起始播放时间。

作为本申请一可选实施例，该装置还可以包括：

头文件解析模块，用于对已加载的第二视频文件的头文件进行解析，得到第二视频配置信息；

视频流头文件拼装模块，用于由所述第二视频配置信息及所述第二起始播放时间，拼装得到第二视频流头文件；

转封装模块，用于将所述第二视频文件的视频数据转封装成第二视频流文件，并将所述第二视频流头文件添加至所述第二视频流文件中；

相应地，上述视频播放模块具体可以用于按照所述第二视频流文件的起始播放时间进行视频播放。

可选的，在上述实施例的基础上，上述装置还可以包括：

写入模块，用于将所述第二视频流文件写入任务队列；

读取模块，用于从所述任务队列中依次读取存储的视频流文件，写入与目标视频标签关联的数据缓存空间；

相应地，上述视频播放模块23具体还可以用于按照所述数据缓存空间已缓存的视频流文件的起始播放时间，播放相应视频流文件。

作为本申请另一可选实施例，如图10所示，上述起始播放时间获取模块22可以包括：

激活单元2221，用于预先激活第一视频文件和第二视频文件；

播放监测单元2222，用于在当前播放窗口播放所述第一视频文件，并监测所述第一视频文件的播放进度；

预加载单元2223，用于在播放进度满足预设条件的情况下，对所述第二视频文件进行预加载。

相应地，视频播放模块23具体用于在所述第一视频文件播放结束时，在所述当前播放窗口播放所述第二视频文件中已加载的视频数据。

其中，在所述第一视频文件播放结束之前，后台输出有所述第二视频文件中的至少一帧图像，以实现视频文件实现无缝切换，保证视频播放流畅性。

可选的，如图10所示，该装置还可以包括：

后台输出模块24，用于将所述第二视频文件的第二视频标签的显示属性切换为隐藏状态，输出所述第二视频文件的至少一帧图像；

相应地，上述视频播放模块23可以包括：

调整播放单元231，用于在所述第一视频文件播放结束时，将所述第一视频文件的第一视频标签的显示属性从所述显示状态切换为所述隐藏状态，并将所述第二视频标签的显示属性从所述隐藏状态切换为显示状态，以使所述当前播放窗口播放所述第二视频文件中已加载的视频数据；

其中，视频标签的显示属性为隐藏状态是指播放相应视频文件的播放窗口的高和宽均为0，且处于静音状态下输出。

在上述各实施例的基础上，视频播放装置还可以包括：

信息获取模块，用于获取客户端运行环境信息；

模式选择模块，用于选择与所述客户端运行环境信息匹配的目标视频播放模式，所述目标视频播放模式为第一视频播放模式或第二视频播放模式。

可见，用户使用各种类型的客户端播放视频，均能够实现边加载边播放，且能够保证整个播放过程的流畅性。

本申请实施例还提供了一种存储介质，其上存储有程序，该程序被处理器调用并执行，实现上述方法实施例描述的视频播放方法的各步骤。

参照图11，为本申请实施例提供的一种计算机设备的硬件结构图，该计算机设备可以包括：通信接口31、存储器32和处理器33；

在本发明实施例中，通信接口31、存储器32、处理器33可以通过通信总线实现相互间的通信，且该通信接口31、存储器32、处理器33及通信总线的数量可以为至少一个。

可选的，通信接口31可以为通信模块的接口，如WIFI模块的接口、GSM模块的接口等，用来接收视频源服务器发送的视频文件；当然，该通信接口31还可以包括实现计算机设备内部数据交互的接口，如串/并口等。

处理器33可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。

存储器32可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

其中，存储器32存储有程序，处理器33调用存储器32所存储的程序，以实现上述应用于计算机设备的视频播放方法的各步骤，具体实现过程可以参照上述方法实施例相应部分的描述。

在实际应用中，上述计算机设备可以是用户的终端设备，如笔记本电脑、手机等，因此，该计算机设备还可以包括输入设备、显示器、麦克风等组成部件，可以依据该计算机设备的具体产品类型，确定其包含的硬件组成结构，并不局限于上文描述的结构。

本说明书中各个实施例采用递进或并列的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、计算机设备而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。