基于浏览器的封面生成方法和系统

技术领域

本申请实施例涉及浏览器技术领域，尤其涉及一种基于浏览器的封面生成方法、系统、计算机设备及计算机可读存储介质。

背景技术

随着互联网技术的发展，Youtube、Bilibilli等网络平台逐渐发展出了UGC(UserGenerated Content，用户原创内容)形式的内容生产模式。UGC的核心在于提倡每个用户将自己原创的内容(如，视频文件)通过平台进行展示或者提供给其他用户。UGC使得人人都可以是内容生产者，从而可以快速生产海量视频以丰富人们的精神生活。但是，海量视频也同时导致每个用户的视频文件容易被淹没在这海量视频中。因此，用户在发布其视频文件时，通常会为其发布的视频文件设置一个视频封面，从而使得其他用户能够更直观地获知视频文件的内容以提高用户点击量。

在现有技术中，设置视频封面的流程如下：①服务器接收用户通过浏览器上传的视频文件；②在视频文件接收完成之后提取和评估视频文件中的每个帧；③根据评估结果选取适宜成为视频封面的一些帧反馈给浏览器，以供用户从这些帧中选取其中一个帧作为该视频文件的视频封面。本发明人意识到，现有技术有以下技术缺陷：获取视频封面需要视频文件接收、帧提取和评估等多个服务器侧的处理步骤，导致视频文件的封面生成耗时严重，视频封面无法及时生成；亦造成了服务器资源的严重消耗。

发明内容

本申请实施例的目的是提供一种基于浏览器的封面生成方法、系统、计算机设备及计算机可读存储介质，用于解决视频文件的封面生成耗时严重的问题和服务器资源消耗严重的问题。

本申请实施例的一个方面提供了一种基于浏览器的封面生成方法，所述方法包括：监测浏览器是否进入目标页面；响应于所述浏览器进入所述目标页面，初始化主线程并创建帧提取线程和画面评估线程，所述帧提取线程用于加载webassembly视频解析器，所述画面评估线程用于加载训练好的画面评估模型；监测基于所述目标页面的目标操作，所述目标操作关联本地视频文件；及响应于所述目标操作，执行以下操作：通过运行在所述帧提取线程中的所述webassembly视频解析器从所述本地视频文件中提取多个目标帧；基于所述多个目标帧，通过运行在所述画面评估线程中的所述画面评估模型得到各个目标帧的画面评估参数；及通过主线程获取所述画面评估线程提供的所述各个目标帧的画面评估参数，根据所述各个目标帧的画面评估参数从所述多个目标帧选取出一个或多个候选帧，并根据所述一个或多个候选帧生成视频封面。

可选的，通过运行在所述帧提取线程中的所述webassembly视频解析器从所述本地视频文件中提取多个目标帧，包括：通过所述webssembly视频解析器确定所述本地视频文件是否为竖屏方向；通过所述webssembly视频解析器从所述本地视频文件中提取出多个帧；如果所述本地视频文件是所述竖屏方向，则将所述多个帧中的各个帧进行图像翻转以得到竖屏方向的各个帧；及将所述竖屏方向的各个帧确定为相应的目标帧。

可选的，通过所述webssembly视频解析器从所述本地视频文件中提取出多个帧，包括：获取N个时间节点对应的N个帧，包括：获取最邻近时间节点M的关键帧，将这个关键帧确定为与所述时间节点M对应的帧，1≤M≤N。

可选的，通过运行在所述帧提取线程中的所述webassembly视频解析器从所述本地视频文件中提取多个目标帧，包括：对所述本地视频文件执行检测操作，根据检测结果确定是否从所述本地视频文件提取所述多个目标帧；其中，所述检测操作用于检测：所述本地视频文件是否为损坏文件，所述本地视频文件中是否包括视频流，和/或所述视频流的视频格式是否被所述webassembly视频解析器支持。

可选的，通过运行在所述画面评估线程中的所述画面评估模型得到各个目标帧的画面评估参数，包括：通过所述画面评估模型中的特征提取层，提取目标帧M的图像特征，1≤M≤N，N为所述多个目标帧的数量；根据所述目标帧M的图像特征和所述画面评估模型中的第一全连接层，得到所述目标帧M对应于各个场景类别的置信度；根据所述目标帧M的图像特征和所述画面评估模型中的第二全连接层，得到所述目标帧M的图像质量评估值；及根据所述目标帧M对应于各个场景类别的置信度和所述目标帧M的图像质量评估值，得到对应于所述目标帧M的画面评估参数。

可选的，根据所述目标帧M对应于各个场景类别的置信度和所述目标帧M的图像质量评估值，得到对应于所述目标帧M的画面评估参数，包括：通过以下公式得到所述目标帧M的画面评估参数P：

P＝p2∑

其中，p1

可选的，根据所述一个或多个候选帧生成视频封面，包括：将所述一个或多个候选帧显示于所述目标页面的预定区域；根据用户指令从所述一个或多个候选帧中选择出一个候选帧；及根据这个被选择的候选帧生成所述视频封面，所述视频封面关联于所述本地视频文件并被提供至服务器中。

本申请实施例的一个方面又提供了一种基于浏览器的封面生成系统，所述基于浏览器的封面生成系统包括：第一监测模块，用于监测浏览器是否进入目标页面；第一响应模块，用于响应于所述浏览器进入所述目标页面，初始化主线程并创建帧提取线程和画面评估线程，所述帧提取线程用于加载webassembly视频解析器，所述画面评估线程用于加载训练好的画面评估模型；第二监测模块，用于监测基于所述目标页面的目标操作，所述目标操作关联本地视频文件；及第二响应模块，用于响应于所述目标操作，执行以下操作：通过运行在所述帧提取线程中的所述webassembly视频解析器从所述本地视频文件中提取多个目标帧；基于所述多个目标帧，通过运行在所述画面评估线程中的所述画面评估模型得到各个目标帧的画面评估参数；通过主线程获取所述画面评估线程提供的所述各个目标帧的画面评估参数，根据所述各个目标帧的画面评估参数从所述多个目标帧选取出一个或多个候选帧，并根据所述一个或多个候选帧生成视频封面。

本申请实施例的一个方面又提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述基于浏览器的封面生成方法的步骤。

本申请实施例的一个方面又提供了一种计算机可读存储介质，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述基于浏览器的封面生成方法的步骤。

本申请实施例提供的基于浏览器的封面生成方法、系统、计算机设备及计算机可读存储介质，具有以下技术优势：(1)通过帧提取线程加载和运行webassembly视频解析器，浏览器可以从本地视频文件中提取多个目标帧，而不需要将本地视频文件上传到服务器中，通过服务器提取并返回多个目标帧。(2)浏览器通过画面评估线程加载和运行画面评估模型，使得在浏览器可以独立地进行画面评估操作，而不需要将本地视频文件上传到服务器中并通过服务器评估并返回画面评估参数等。综上所述，本实施例可以通过浏览器独立完成帧提取、画面评估等一系列操作，避免了现有技术中需要借助服务器完成所导致的封面生成时间长的问题，也避免了现有技术中需要借助服务器完成所导致的服务器资源的严重消耗的问题。可知，本实施例封面生成时间短且不消耗服务器资源。

附图说明

图1示意性示出了根据本申请实施例的基于浏览器的封面生成方法的运行环境图；

图2示意性示出了根据本申请实施例一的基于浏览器的封面生成方法的流程图；

图3示意性示出目标页面的示意图；

图4示意性示出了webassembly视频解析器的编译流程图；

图5示意性示出了帧提取操作的子流程图；

图6示意性示出了帧提取操作的另一子流程图；

图7示意性示出了帧提取操作的另一子流程图；

图8示意性示出了画面评估操作的子流程图；

图9示意性示出了主线程中视频封面生成操作的子流程图；

图10示意性示出了生成视频封面的示例性流程图；

图11示意性示出了根据本申请实施例二的基于浏览器的封面生成系统的框图；及

图12示意性示出了根据本申请实施例三的适于实现基于浏览器的封面生成方法的计算机设备的硬件架构示意图。

具体实施方式

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

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

以下为本申请可能涉及到的一些术语的术语解释：

ffmpeg：由C语言写成，可以运行音频和视频多种格式的录影、解析、转换、流等功能。

Libjpeg：是一个用C语言编写的处理JPEG图像数据格式的自由库。

Emcc：用于将文件编译为LLVM字节码。

javascript/js：是一种在浏览器内运行的脚本语言。

WebAssembly/wasm：是基于堆栈的虚拟机的二进制指令格式，运行在浏览器内一个沙箱化的执行环境中；它被设计为C/C++/Rust等高级语言的可移植目标，可在Web上部署客户端应用程序和服务器应用程序。

asm.js：可以解决js引擎的执行效率问题，尤其是使用Emscripten从C/C++语言编译成js的程序的效率。本申请中，asm.js用于作为不支持WebAssembly技术的浏览器的兜底方案。

LLVM(low level virtual machine，底层虚拟机)：是一种编译器基础设施，通过C++写成，包含一系列模块化的编译器组件和工具链，用来开发编译器前端和后端。LLVM字节码，指是已经经过编译，但与特定机器代码无关，需要LLVM解释器转译后才能成为机器代码的中间代码。

Emscripten：是基于LLVM的asm.js&WebAssembly编译工具链。本申请中Emscripten可以将由C语言生成的ffmpeg相关代码编译成为asm.js&WebAssembly。

画面评估模型，可以是基于Tensorflow的深度学习框架。TensorFlow是用于机器学习的端到端开源软件库，其可以用于机器学习应用程序，例如深度神经网络等。

帧提取：从视频文件提取一个或多个帧。

画面评估：用于评估各个帧是否适合作为视频文件的视频封面。

以下对本申请所解决的问题进行阐述。

用户通过浏览器将某个视频文件发布到网络平台时，通常会为其发布的视频文件设置一个视频封面，从而使得其他用户能够更直观地获知视频文件的内容以提高用户点击量。在设置视频文件的视频封面的过程中，需要“帧提取”和“画面评估”等步骤。所述“帧提取”在于根据待提取画面在视频文件中的时间节点，使用ffmpeg技术从视频文件中提取出画面。所述“画面评估”在于对视频文件中提取到的每一帧进行画面评估，以评估这些帧是否适合成为视频文件的视频封面。其中：在现有技术中，“帧提取”操作主要包括以下两种实现方式，其一：将视频文件上传到服务器中，待视频文件上传完成之后，依托服务器运行ffmpeg命令以从视频文件中提取出每一帧；其二：使用web端的canvas内嵌video标签，在用户不可见的场景下播放视频文件并实施截图操作，但该技术仅支持少数视频编码格式(视浏览器支持情况而定)，无法完成对市场上绝大多数视频格式的覆盖。且不同浏览器对视频格式的支持情况也不同，因此该“帧提取”操作目前需要在服务端执行。在现有技术中，“画面评估”操作主要通过以下流程实现：预先将画面评估模型运行在服务器上，对服务器提取出的各个帧进行画面评估操作，根据评估结果选取一些帧反馈给浏览器，以供用户从这些帧中选取其中一个帧作为视频文件的视频封面。因此，现有技术中设置视频封面的流程如下：用户通过浏览器上传视频文件→视频文件被完整上传至服务器→服务器对视频文件进行帧提取→服务器对每一帧进行画面评估→服务器根据评估结果选取一些帧反馈给浏览器，以供用户从这些帧中选取其中一个帧作为视频文件的视频封面。该现有技术存在的主要问题为：推荐封面的生成耗时严重，需等待服务器的多步处理结果，如上传完成、帧提取、画面评估，造成部分用户提交投稿时，推荐封面尚未及时生成；亦造成了服务器资源的严重消耗。

下文将提供多个实施例，不难理解，下文提供的各个实施例可以用于解决上文描述的技术问题。

图1示意性示出了根据本申请实施例一的基于浏览器的封面生成方法的运行环境图。在示例性的实施例中，计算机设备2可以通过网络4连接内容发布平台3，并通过内容发布平台3发布内容。所述内容可以包括计算机设备2中的本地视频文件等。

计算机设备2，可以被配置为通过浏览器2A访问内容发布平台3并可以通过浏览器2A将本地视频文件上传到内容发布平台3中，以在内容发布平台3上发布其视频文件。计算机设备2可以包括任何类型的计算设备，诸如移动设备，平板设备，膝上型计算机等。

内容发布平台3，可以由多个服务器组成，用于为计算机设备2提供视频文件发布服务。该多个服务器可以包括虚拟化计算实例。虚拟化计算实例可以包括虚拟机，诸如计算机系统的仿真，操作系统，服务器等。服务器可以基于定义用于仿真的特定软件(例如，操作系统，专用应用程序，服务器)的虚拟映像和/或其他数据来加载虚拟机。随着对不同类型的处理服务的需求改变，可以在一个或多个服务器上加载和/或终止不同的虚拟机。可以实现管理程序以管理同一服务器上的不同虚拟机的使用。

网络4可以包括各种网络设备，例如路由器，交换机，多路复用器，集线器，调制解调器，网桥，中继器，防火墙，代理设备和/或等等。网络4可以包括物理链路，例如同轴电缆链路，双绞线电缆链路，光纤链路，它们的组合和/或类似物。网络4可以包括无线链路，例如蜂窝链路，卫星链路，Wi-Fi链路和/或类似物。

实施例一

图2示意性示出了根据本申请实施例一的基于浏览器的封面生成方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。下面以计算机设备2为执行主体进行示例性描述。

如图2所示，该基于浏览器的封面生成方法可以包括步骤S200～S206，其中：

步骤S200，监测浏览器2A是否进入目标页面。

所述浏览器2A中每个标签页对应一个独立的进程(process)，每个进程对应一个或多个线程(thread)。所述浏览器2A进入所述目标页面，则说明所述浏览器2A打开了一个新标签页。如图3所示，在示例性的实施例中，所述目标页面可以为投稿页面，用于提供用户将本地视频文件上传到内容发布平台3中的界面入口。

步骤S202，响应于所述浏览器2A进入所述目标页面，初始化主线程并创建帧提取线程和画面评估线程。

所述目标页面可以关联有多个线程，该多个线程中的其中一个线程为所述主线程(mainthread)，所述主线程可以用于负责所述目标页面的渲染、展示以及页面交互等操作。在示例性的实施例中，本实施例另外创建新的帧提取线程和新的画面评估线程，使得帧提取和画面评估等操作不需要在主线程中实施，从而确保所述主线程中的渲染、展示、页面交互等不受帧提取和画面评估等操作的影响。

所述帧提取线程用于加载webassembly视频解析器。如图4所示，webassembly视频解析器的编译过程可以如下：(1)准备C入口文件、ffmpeg依赖库、libjpeg依赖库和emscipten依赖库；(2)通过emcc编译(1)中的文件，得到LLVM字节码；(3)通过Emscripten编译LLVM字节码，得到webassembly和asm.js。webassembly和asm.js可以使得ffmpeg可以适用于浏览器中并能够提供基于浏览器的帧提取服务。由于asm.js属于webassembly的降级方案，因此，本申请将webassembly和asm.js统称为webassembly视频解析器。本实施例基于webassembly技术，通过编译ffmpeg的c语言源码及自主实现，使得浏览器2A可以获得ffmpeg赋予的能力，即，使得浏览器2A能够对多种不同编码格式的视频独立地完成帧提取等操作。

所述画面评估线程用于加载训练好的画面评估模型。所述画面评估模型可以是深度神经网络模型。该画面评估模型可以以天或星期为周期进行迭代训练以提升评估精度。所述迭代训练在于将新增用户数据和原用户数据进行正比例混合并根据混合后的用户数据进行重新训练。

步骤S204，监测基于所述目标页面的目标操作，所述目标操作关联本地视频文件。

在示例性的实施例中，所述目标操作可以是上传操作。如图3所示，如果计算机设备2监测到上传按钮上的点击操作，则说明监测到了基于所述目标页面上的目标操作，该目标操作在于将本地视频文件“(1991)中环英雄(粤语)”上传到内容发布平台3，以通过内容发布平台3发布这个本地视频文件。

步骤S206，响应于所述目标操作，执行以下操作：

步骤S206A，通过运行在所述帧提取线程中的所述webassembly视频解析器从所述本地视频文件中提取多个目标帧。

在示例性的实施例中，为了确保各个目标帧能够被正确地展示以及确保各个目标帧能够在画面评估线程中被正确的识别和评估，如图5所示，所述步骤S206A可以包括步骤S500～S506。步骤S500，通过所述webssembly视频解析器确定所述本地视频文件是否为竖屏方向；步骤S502，通过所述webssembly视频解析器从所述本地视频文件中提取出多个帧；步骤S504，如果所述本地视频文件是所述竖屏方向，则将所述多个帧中的各个帧进行图像翻转以得到竖屏方向的各个帧；步骤S506，将所述竖屏方向的各个帧确定为相应的目标帧。需要说明的是，如果所述本地视频文件是横屏方向，则在不需要执行翻转操作的情形下将所述多个帧中的各个帧直接确定为相应的目标帧。作为示例，如果本地视频文件Y是在手机X处于竖屏状态下拍摄得到的，因此，该本地视频文件Y是一个竖屏文件。当解析一个竖屏文件时，所述webssembly视频解析器会将该竖屏文件转化为横屏文件。上述做法可能会导致这样一个问题：从竖屏文件中提取出来的帧处于横屏方向，使得这些帧的展示方向和本地视频文件Y的展示方向不同，因此，这些帧并不能够被正确显示并且在画面评估线程也是不可用的。为了解决上述问题，所述浏览器2A可以通过所述webassembly视频解析器解析所述本地视频文件Y，得到手机X在拍摄所述本地视频文件Y时在所述本地视频文件Y中写入的翻转信息，并通过该翻转信息获知该本地视频文件Y属于竖屏文件或横屏文件。如果所述本地视频文件Y属于竖屏文件，则浏览器2A通过所述webassembly视频解析器对从本地视频文件Y中提取的多个帧进行翻转操作，使得翻转操作后的多个帧的展示方向与所述本地视频文件Y的展示方向保持一致。

在示例性的实施例中，如图6所示，为了降低计算机设备2的计算资源消耗，同时确保从所述本地视频文件中提取出来的多个帧是高质量的且最具代表性的，步骤S502可以通过以下步骤实现：步骤S600，获取N个时间节点对应的N个帧，包括：获取最邻近时间节点M的关键帧，将这个关键帧确定为与所述时间节点M对应的帧，1≤M≤N。M、N均是正整数。M是一个自变量。N可以是一个预设值，也可以是能够根据计算机设备2的当前工作负担调整的动态值。例如，在计算机设备2处于高负荷状态时，N可以动态调整为每10秒一个时间节点。当计算机设备2处于空闲状态时，N可以动态调整为每5秒一个时间节点。例如，所述N个时间节点包括：第一个时间节点(对应本地视频文件在进度条上的0秒)、第二个时间节点(对应本地视频文件在进度条上的5秒)、第三个时间节点(对应本地视频文件在进度条上的15秒)、第四个时间节点(对应本地视频文件在进度条上的20秒)、第五个时间节点(对应本地视频文件在进度条上的25秒)、…。浏览器2A可以通过webassembly视频解析器解析所述本地视频文件中各个帧的帧信息(I帧、P帧、B帧)，然后可以执行以下操作：根据各个帧的帧信息找到最邻近所述第一个时间点的I帧并根据最邻近第一个时间的这个I帧作为所述第一个时间点的关键帧；根据各个帧的帧信息找到最邻近所述第二个时间点的I帧并根据最邻近第二个时间的这个I帧作为所述第二个时间点的关键帧；并且以此类推。需要说明的是，I帧又称为内部画面(intra picture)。

在示例性的实施例中，如图7所示，为确保本地视频文件的可用性，在进行帧提取操作之前，所述浏览器2A还需要通过所述webassembly视频解析器执行以步骤S700：对所述本地视频文件执行检测操作，根据检测结果确定是否从所述本地视频文件提取所述多个目标帧。其中，所述检测操作用于检测：所述本地视频文件是否为损坏文件，所述本地视频文件中是否包括视频流，和/或所述视频流的视频格式是否被所述webassembly视频解析器支持。

步骤S206B，基于所述多个目标帧，通过运行在所述画面评估线程中的所述画面评估模型得到各个目标帧的画面评估参数。

在示例性的实施例中，所述主线程可以获取所述帧提取线程提供的所述多个目标帧，并将所述多个目标帧的图像数据或经格式转换后的多个目标帧的图像数据传输至所述画面评估线程中。所述画面评估线程运行所述画面评估模型，并将所述多个目标帧的图像数据或经格式转换后的多个目标帧的图像数据输入到所述画面评估模型中，以通过所述画面评估模型输出各个目标帧的画面评估参数。

所述画面评估模型可以是深度神经网络模型或其他模型。

在示例性的实施例中，所述画面评估模型包括特征提取层、第一全连接层和第二全连接层，所述特征提取层可以是由一个或多个卷积层构成，用于通过卷积操作提取各个目标帧的图像特征。需要说明的是，所述第一全连接层和所述第二全连接层是并列关系，所述第一全连接层和所述第二全连接层共用所述特征提取层。其中，所述第一全连接层用于场景识别，所述第二全连接层用于图像质量评估。相较于现有技术中分别设置场景识别模型和图像质量评估模型，本实施例通过一个画面评估模型就实现了场景识别和图像质量评估，且通过共用特征提取层有效降低了计算量。

如图8所示，所述步骤S206B可以包括步骤S800～S806，其中：步骤S800，通过所述画面评估模型中的特征提取层，提取目标帧M的图像特征，1≤M≤N，N为所述多个目标帧的数量；步骤S802，根据所述目标帧M的图像特征和所述画面评估模型中的第一全连接层，得到所述目标帧M对应于各个场景类别的置信度；步骤S804，根据所述目标帧M的图像特征和所述画面评估模型中的第二全连接层，得到所述目标帧M的图像质量评估值；步骤S806，根据所述目标帧M对应于各个场景类别的置信度和所述目标帧M的图像质量评估值，得到对应于所述目标帧M的画面评估参数；以及重复执行步骤S800～S806直至所述多个目标帧全部评估完成。

在示例性的实施例中，所述场景类别可以如下：“ACG(Animation Comic Game，动漫)”、“ACG_Object(动漫对象)”、“Animal(动物)”、“Food(食物)”、“Game(游戏)”、“Multi-Person(多人)”、“Object(对象)”、“Person(单人)”、“Scenery(风景)”、“Text(文本)”、“Other(其他)”。所述图像质量评估值的范围在在0到1之间，其受到亮度、色度等影响。如果一个目标帧的图像质量评估值越接近1，则说明这个目标帧的画面质量越高。

在示例性的实施例中，通过以下公式得到所述目标帧M的画面评估参数P：

P＝p2∑

其中，p1

arg max p1表示置信度最大的目标场景。当通过所述第一全连接层得到某个目标帧Z的场景类别是“Person(单人)”，需要考虑以下：在识别目标帧Z的场景类别为“Person(单人)”的情形下，该目标帧Z的场景类别有一定可能是“Multi-Person(多人)”，甚至该目标帧Z的场景类别有可能是“Scenery(风景)”。为了解决上述问题，通过∑

步骤S206C，通过主线程获取所述画面评估线程提供的所述各个目标帧的画面评估参数，根据所述各个目标帧的画面评估参数从所述多个目标帧选取出一个或多个候选帧，并根据所述一个或多个候选帧生成视频封面。

所述画面评估线程将所述画面评估模型得到的各个目标帧的画面评估参数(如，分数)传送到所述主线程中。所述主线程得到所述各个目标帧的画面评估参数之后，可以根据各个目标帧的画面评估参数对所述多个目标帧进行排序，将排序靠前的一些目标帧选择作为候选帧，将这些候选帧以一定顺序显示在目标页面中，如图3所示。

在示例性的实施例中，如图9所示，根据所述一个或多个候选帧生成视频封面，可以包括步骤S900～S904，其中：步骤S900，将所述一个或多个候选帧显示于所述目标页面的预定区域；步骤S902，根据用户指令从所述一个或多个候选帧中选择出一个候选帧；步骤S902，根据这个被选择的候选帧生成所述视频封面，所述视频封面关联于所述本地视频文件并被提供至服务器(如，内容发布者3)中。

为了使得本申请更加清晰易懂，以下提供生成视频封面的示例性流程。如图10所示：

S1：根据用户指令打开投稿页。

S2：主线程初始化。

S3：创建帧提取线程。

S4：在帧提取线程中加载webassembly视频解析器。

S5：创建画面评估线程。

S6：在画面评估线程加载画面评估模型(如tensorflow.js)。

S7：用户点击上传按钮以上传本地视频文件。

S8：主线程通知帧提取线程进入运行状态(postmsg：RUN)。

S9：运行webassembly视频解析器以提取多个目标帧。

S10：帧提取线程将所述多个目标帧传送到主线程中(postmsg：多个目标帧)。

S11：转换得到各个目标帧的imgdata。主线程对各个目标帧的图像数据格式转换为可以被画面评估模型识别的数据格式。imgdata即是可以被画面评估模型识别的数据格式的图像数据。需要说明的是，该步骤也可以在画面评估线程中进行，本申请不做限定。

S12：主线程将imgdata传动到画面评估线程中(postmsg：imgdata)。

S13：画面评估线程通过画面评估模型评估各个目标帧。画面评估线程在于将各个帧的imgdata输入到画面评估模型中，以便画面评估模型各个目标帧的画面评估参数。

S14：画面评估线程将各个目标帧的画面评估参数传送到主线程中(postmsg：画面评估参数)。

S15：主线程执行以下操作：根据各个目标帧的画面评估参数，对所述多个目标帧进行排序，将排序靠前的一些目标帧选择作为候选帧，将这些候选帧以一定顺序显示在目标页面中，以供用户选择。

示例性的，如果用户需要将某个本地视频文件发布到bilibili平台上，用户可以通过浏览器打开bilibili投稿页并点击“投稿”这个上传按钮。在这个上传按钮被触发之后，浏览器会并行执行以下操作：(1)将本地视频文件上传到bilibili平台，(2)通过本地计算资源获取并呈现用于作为视频封面的候选帧，供用户选择。

本实施例所述的封面生成方法，包括以下技术优势：

(1)本实施例在所述目标页面下提供了三个独立且相互协作的线程(即，主线程、帧提取线程和画面评估线程)，使得帧提取和画面评估等操作不需要在主线程中实施，从而确保所述主线程中的渲染、展示、页面交互等不受帧提取和画面评估等操作的影响，即保障了主线程的流畅度。

(2)本实施例采用了webassembly技术，通过帧提取线程加载和运行webassembly视频解析器，浏览器可以独立地从本地视频文件中提取多个目标帧，而不需要将本地视频文件上传到服务器(如内容发布者3)中并通过服务器提取并返回多个目标帧。

基于webassembly技术，本实施例可以使得浏览器能够对多种不同编码格式的视频独立地完成帧提取等操作，减轻了服务器的负担。例如，本实施例的浏览器至少可以支持以下视频编码格式：MPEG(Moving Picture Experts Group，活动图像专家组)系列、WMV(Windows Media Video，Windows媒体视频格式)系列、FLV(flash video，)、msvideo1(Microsoft Video 1，由微软提供的一个AVI编码)、mss2、H264(即，由国际标准化组织和国际电信联盟共同提出的继MPEG4之后的新一代数字视频压缩格式)、HEVC(High EfficiencyVideo Coding，高效率视频编码)、H263(即，由ITU-T制定的视频会议用的低码率视频编码标准)、RV40(RealVideo 9，基于H.264草案改的一种编码格式)、RV20(RealVideo G2或RealVideo G2+SVT)、dvvideo(Digital Video Format，数字视频编码)、rawvideo(未经任何后期加工或修饰的视频格式)、v210(即，一种UYVY的格式)、TSCC系列(TechSmith ScreenCapture Codec，Techsmith公司开发的一种视频编码解码器)、prores(即，由苹果公司开发的破坏性压缩影片压缩技术)、vp6f、PNG(Portable Network Graphics，便携式网络图形)、MJPEG(Motion Joint Photographic Experts Group，技术即运动静止图像(或逐帧)压缩技术)、GIF(Graphics Interchange Format，图像互换格式)、VP系列(即，由Google开发的开放格式、无使用授权费的视频压缩标准)、theora(即，一个由Xiph.Org基金会开发格式的有损影像压缩技术)。

(3)在本实施例中，通过画面评估线程加载和运行画面评估模型，浏览器可以独立地进行画面评估操作，而不需要将本地视频文件上传到服务器(如内容发布者3)中并通过服务器评估并返回画面评估参数等。

也就是说，本实施例使用了tensorflow-javascript技术，将原先运行在服务器上的画面评估模型打包成可以在浏览器运行的格式并且分发给浏览器，使得浏览器可以在本地运行画面评估模型完成对目标帧的画面评估，从而避免了借助服务器进行画面评估导致的服务器等待的时间。

(4)在现有技术中，封面生成所需要的如下步骤：用户通过浏览器上传视频文件→视频文件被完整上传至服务器→服务器对视频文件进行帧提取→服务器对每一帧进行画面评估→服务器根据评估结果选取一些帧反馈给浏览器，以供用户从这些帧中选取视频文件的视频封面。

本实施例节省了上述繁琐的步骤。在本实施例中，浏览器可以独立完成帧提取、画面评估等一系列操作，避免了现有技术中需要借助服务器导致的封面生成时间长的问题，也避免了服务器资源的严重消耗的问题。

(5)在现有技术中，服务器需要本地视频文件上传完毕之后才开始实施帧提取和画面评估等操作。因此，当本地视频较大或网络质量不好时，利用现有技术实现封面生成所需要的时间会非常长。

在本实施例中，浏览器可以独立完成帧提取、画面评估和封面生成等操作。当用户通过浏览器上传本地视频文件时，浏览器可以一边执行本地视频文件的上传流程一边执行本地视频文件的封面生成流程，极大的缩短了封面生成所需的时间。通常，本地视频文件的封面生成的完成时间短于该本地视频文件的上传流程的完成时间。

(6)经过测试表明：使用了本实施例的封面生成方法，封面展现率和完成率均有提高，并且封面生成时间明显下降。

封面展现率：用户提交投稿时，推荐封面的综合展现率由约60％升至75％以上；

完成率：约50％的投稿用户在完成一次投稿前，可以完成视频封面的生成；

运行时间：经过大量样本测试得到大约有50％的测试样本可以在10秒内生成视频封面，大约80％的测试样本可以在20秒内生成视频封面，大约98％的测试样本可以在30秒内生成视频封面。而，现有技术的运行时间则取决于多个维度，如稿件大小、网络传输速度、服务器运行压力等等，完成时间长和完成时间非常不稳定。

实施例二

图11示意性示出了根据本申请实施例二的基于浏览器的封面生成系统的框图，该基于浏览器的封面生成系统可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例中各程序模块的功能。

如图11所示，该基于浏览器的封面生成系统1100可以包括第一监测模块1110、第一响应模块1120、第二监测模块1130和第二响应模块1140，其中：

第一监测模块1110，用于监测浏览器是否进入目标页面；

第一响应模块1120，用于响应于所述浏览器进入所述目标页面，初始化主线程并创建帧提取线程和画面评估线程，所述帧提取线程用于加载webassembly视频解析器，所述画面评估线程用于加载训练好的画面评估模型；

第二监测模块1130，用于监测基于所述目标页面的目标操作，所述目标操作关联本地视频文件；及

第二响应模块1140，用于响应于所述目标操作，执行以下操作：通过运行在所述帧提取线程中的所述webassembly视频解析器从所述本地视频文件中提取多个目标帧；基于所述多个目标帧，通过运行在所述画面评估线程中的所述画面评估模型得到各个目标帧的画面评估参数；通过主线程获取所述画面评估线程提供的所述各个目标帧的画面评估参数，根据所述各个目标帧的画面评估参数从所述多个目标帧选取出一个或多个候选帧，并根据所述一个或多个候选帧生成视频封面。

在示例性的实施例中，所述第二响应模块1140还用于：通过所述webssembly视频解析器确定所述本地视频文件是否为竖屏方向；通过所述webssembly视频解析器从所述本地视频文件中提取出多个帧；如果所述本地视频文件是所述竖屏方向，则将所述多个帧中的各个帧进行图像翻转以得到竖屏方向的各个帧；及将所述竖屏方向的各个帧确定为相应的目标帧。

在示例性的实施例中，所述第二响应模块1140还用于：获取N个时间节点对应的N个帧，包括：获取最邻近时间节点M的关键帧，将这个关键帧确定为与所述时间节点M对应的帧，1≤M≤N。

在示例性的实施例中，所述第二响应模块1140还用于：对所述本地视频文件执行检测操作，根据检测结果确定是否从所述本地视频文件提取所述多个目标帧；其中，所述检测操作用于检测：所述本地视频文件是否为损坏文件，所述本地视频文件中是否包括视频流，和/或所述视频流的视频格式是否被所述webassembly视频解析器支持。

在示例性的实施例中，所述第二响应模块1140还用于：通过所述画面评估模型中的特征提取层，提取目标帧M的图像特征，1≤M≤N，N为所述多个目标帧的数量；根据所述目标帧M的图像特征和所述画面评估模型中的第一全连接层，得到所述目标帧M对应于各个场景类别的置信度；根据所述目标帧M的图像特征和所述画面评估模型中的第二全连接层，得到所述目标帧M的图像质量评估值；及根据所述目标帧M对应于各个场景类别的置信度和所述目标帧M的图像质量评估值，得到对应于所述目标帧M的画面评估参数。

在示例性的实施例中，所述第二响应模块1140还用于：通过以下公式得到所述目标帧M的画面评估参数P：

P＝p2∑

其中，p1

在示例性的实施例中，所述第二响应模块1140还用于：将所述一个或多个候选帧显示于所述目标页面的预定区域；根据用户指令从所述一个或多个候选帧中选择出一个候选帧；及根据这个被选择的候选帧生成所述视频封面，所述视频封面关联于所述本地视频文件并被提供至服务器中。

实施例三

图12示意性示出了根据本申请实施例三的适于实现基于浏览器的封面生成方法的计算机设备2的硬件架构示意图。本实施例中，计算机设备2是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是智能手机、平板电脑、笔记本电脑、台式计算机等终端设备。如图12所示，计算机设备2至少包括但不限于：可通过系统总线相互通信链接存储器1210、处理器1220、网络接口1230。其中：

存储器1210至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器1210可以是计算机设备2的内部存储模块，例如该计算机设备2的硬盘或内存。在另一些实施例中，存储器1210也可以是计算机设备2的外部存储设备，例如该计算机设备2上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(FlashCard)等。当然，存储器1210还可以既包括计算机设备2的内部存储模块也包括其外部存储设备。本实施例中，存储器1210通常用于存储安装于计算机设备2的操作系统和各类应用软件，例如基于浏览器的封面生成方法的程序代码等。此外，存储器1210还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器1220在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器1220通常用于控制计算机设备2的总体操作，例如执行与计算机设备2进行数据交互或者通信相关的控制和处理等。本实施例中，处理器1220用于运行存储器1210中存储的程序代码或者处理数据。

网络接口1230可包括无线网络接口或有线网络接口，该网络接口1230通常用于在计算机设备2与其他计算机设备之间建立通信链接。例如，网络接口1230用于通过网络将计算机设备2与外部终端相连，在计算机设备2与外部终端之间的建立数据传输通道和通信链接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(GlobalSystem of Mobile communication，简称为GSM)、宽带码分多址(Wideband Code DivisionMultiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。

需要指出的是，图12仅示出了具有部件1210-1230的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。

在本实施例中，存储于存储器1210中的基于浏览器的封面生成方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器1220)所执行，以完成本申请实施例。

实施例四

本申请还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的基于浏览器的封面生成方法的步骤。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中基于浏览器的封面生成方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。