阅读说明：本技术 一种处理视频画面的方法、相关装置及存储介质 (Method for processing video pictures, related device and storage medium ) 是由 何鑫 邱良雄 梁沁 林锦涛 张晓文 李相如 吴桂盛 李煜彬 刘宜鑫 周宇 胡玮 于 2020-03-31 设计创作，主要内容包括：本申请实施例提供一种处理视频画面的方法、相关装置及存储介质,该方法包括：在前端平台,对目标视频的首帧数据拆解为视频播放数据和业务数据,基于该视频播放数据和渲染后的业务数据生成首帧画面,并发送给终端。终端获取目标视频的首帧画面,将视频播放数据关联到第一界面控件以及将业务数据关联到第二界面控件；其中,第一界面控件用于控制播放组件播放视频播放数据的播放逻辑；第二界面控件用于控制所述业务数据在用户界面上的显示以及控制业务逻辑；通过第一界面控件和第二界面控件,将首帧画面生成目标视频画面。本方案能够加快目标视频画面的生成速度和播放速度。(The embodiment of the application provides a method for processing video pictures, a related device and a storage medium, wherein the method comprises the following steps: and at the front-end platform, disassembling the first frame data of the target video into video playing data and service data, generating a first frame picture based on the video playing data and the rendered service data, and sending the first frame picture to the terminal. The terminal acquires a first frame of picture of a target video, associates video playing data to a first interface control and associates service data to a second interface control; the first interface control is used for controlling the playing assembly to play the playing logic of the video playing data; the second interface control is used for controlling the display of the service data on the user interface and controlling service logic; and generating a target video picture from the first frame picture through the first interface control and the second interface control. The scheme can accelerate the generation speed and the playing speed of the target video picture.)

一种处理视频画面的方法、相关装置及存储介质

技术领域

本申请实施例涉及视频处理技术领域，尤其涉及一种处理视频画面的方法、相关装置及存储介质。

背景技术

移动端动态化框架技术是一种让开发者可以使用前端开发技术来开发移动端原生应用的新技术，基本原理是移动端底层提供一个与前端通信的桥接器，桥接器接收到前端传过来的命令来去生成各种移动端特有的View元素，因为前端的动态性，所以是其生成的移动端页面也具有动态性。基于移动端的产品需求时，通常会将播放器自身包装成一个UI相关的View元素，将纯播放器添加到其中来满足不同的业务场景，如视频标题展示、播放标志的显示隐藏、音量条控制等业务逻辑。

在对现有技术的研究和实践过程中，本申请实施例的发明人发现，播放器封装成UI相关的View元素在移动端动态化框架的场景下，一方面要接收框架侧传来的绘制UI的指令，一方面要执行播放相关的逻辑，导致终端的性能损耗增加。

发明内容

本申请实施例提供了一种处理视频画面的方法、相关装置及存储介质，能够加快目标视频画面的生成速度和播放速度，以及提高客户端的性能。

第一方面中，本申请实施例提供一种处理视频画面的方法，所述方法包括：

获取目标视频的首帧画面，所述首帧画面包括视频播放数据和已渲染的业务数据；

将所述视频播放数据关联到第一界面控件以及将所述业务数据关联到第二界面控件；其中，所述第一界面控件用于控制播放组件播放所述视频播放数据的播放逻辑；所述第二界面控件用于控制所述业务数据在用户界面上的显示以及控制业务逻辑；

通过所述第一界面控件和所述第二界面控件，将所述首帧画面生成目标视频画面。

一种可能的设计中，所述将所述首帧画面生成目标视频画面之后，所述方法还包括：

通过所述第一界面控件展示所述目标视频画面中的视频播放数据，以及通过所述第二界面控件展示所述目标视频画面中的业务数据；

接收用户的第一消息，所述第一消息用于请求播放所述目标视频；

通过所述第一界面控件启动所述播放组件，以控制所述播放组件播放所述目标视频画面。

一种可能的设计中，所述方法基于页面控件框架实现，所述第一界面控件和所述第二界面控件属于同一个父界面控件，所述将所述首帧画面生成目标视频画面之前，所述方法还包括：

将所述第一界面控件与所述播放组件关联；

设置所述父界面控件与所述第一界面控件之间的调用方式和通信方式；

所述通过所述第一界面控件启动所述播放组件，以显示所述目标视频画面，接收用户的第一消息，包括：

通过所述父界面控件调用所述第一界面控件，以启动所述播放组件显示所述目标视频画面；

通过所述父界面控件接收所述第一消息。

一种可能的设计中，所述页面控件框架还包括抽象类，所述方法还包括：

接收第二消息，所述第二消息用于请求对所述目标视频的第一播放界面进行放大显示；

将所述第一界面控件从所述父界面控件移动至所述抽象类中；

将所述第一播放界面的尺寸更新为所述抽象类中的尺寸设置信息；

通过调用所述抽象类显示所述第一播放界面；

旋转所述第一播放界面，以生成第二播放界面；

显示所述第二播放界面。

一种可能的设计中，所述将所述第一界面控件从所述父界面控件中移动至抽象类中，包括：

将所述第一界面控件从所述父界面控件中移除，记录所述第一界面控件在所述父界面控件中的初始索引和初始布局信息；

清空设置在所述第一界面控件上的所述初始布局信息；

将所述第一界面控件添加到所述抽象类中。

一种可能的设计中，所述将所述第一播放界面的尺寸更新为所述抽象类中的尺寸设置信息，包括：

为所述第一界面控件设置新布局信息；

按照所述父界面控件中的尺寸设置信息，设置所述第一播放界面的目标尺寸；

根据所述新布局信息和所述目标尺寸生成所述第二播放界面。

一种可能的设计中，所述接收第二消息之后，所述旋转所述第一播放界面之前，所述方法还包括：

将所述第二界面控件从所述父界面控件移动至所述抽象类中；

将所述第二界面控件设置为不可见。

一种可能的设计中，所述页面控件框架还包括抽象类，所述方法还包括：

接收第三消息，所述第三消息用于请求对所述目标视频的第一播放界面进行缩小显示；

将所述第一界面控件从所述抽象类移动至所述父界面控件中；

通过调用所述第一界面控件显示所述第一播放界面；

旋转所述第一播放界面，以生成第二播放界面；

显示所述第二播放界面。

一种可能的设计中，所述接收第三消息之后，所述旋转所述第一播放界面之前，所述方法还包括：

将所述第二界面控件从所述抽象类中移动至所述父界面控件的初始层级；

将所述第二界面控件设置为可见。

一种可能的设计中，所述目标视频画面保存在区块链节点上。

第二方面中，本申请实施例提供一种处理视频画面的方法，所述方法包括：

从待处理的目标视频中获取首帧数据；

从所述首帧数据中获取视频播放数据和业务数据；

对所述业务数据进行渲染；

根据所述视频播放数据和已渲染的业务数据，生成首帧画面；

向终端发送包括所述首帧画面的目标视频。

一种可能的设计中，所述对所述业务数据进行渲染，包括：

将所述业务数据拆分为至少一个类的数据；

按照数据所属的类，分别为各类的数据设置用户界面UI标签；

将所述至少一个类的数据生成至少一张视频简介；

对所述至少一张视频简介分别进行渲染，得到业务UI元素，所述业务UI元素用于展示业务的业务形态和业务逻辑。

一种可能的设计中，所述首帧画面保存在区块链节点上。

第三方面中，本申请实施例提供一种视频画面处理装置，具有实现对应于上述第一方面提供的处理视频画面的方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。

一种可能的设计中，所述视频画面处理装置包括：

输入输出模块，用于获取目标视频的首帧画面，所述首帧画面包括视频播放数据和已渲染的业务数据；

处理模块，用于将所述输入输出模块获取的所述视频播放数据关联到第一界面控件以及将所述业务数据关联到第二界面控件；通过所述第一界面控件和所述第二界面控件，将所述首帧画面生成目标视频画面，其中，所述第一界面控件用于控制播放组件播放所述视频播放数据的播放逻辑；所述第二界面控件用于控制所述业务数据在用户界面上的显示以及控制业务逻辑。

第四方面中，本申请实施例提供一种视频画面处理装置，具有实现对应于上述第二方面提供的处理视频画面的方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。

一种可能的设计中，所述视频画面处理装置包括：

处理模块，用于从待处理的目标视频中获取首帧数据；从所述首帧数据中获取视频播放数据和业务数据；

渲染模块，用于对所述处理模块获取的所述业务数据进行渲染；

所述处理模块还用于根据所述视频播放数据和已渲染的业务数据，生成首帧画面；

输入输出模块，用于向终端发送包括所述首帧画面的目标视频。

本申请实施例又一方面提供了一种视频画面处理装置，其包括至少一个连接的处理器、存储器和输入输出单元，其中，所述存储器用于存储计算机程序，所述处理器用于调用所述存储器中的计算机程序来执行上述各方面所述的方法。

本申请实施例又一方面提供了一种计算机可读存储介质，其包括指令，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

相较于现有技术，本申请实施例提供的方案中，由于从前端平台获取的首帧画面中的业务数据和视频播放数据已经在逻辑上分离且业务数据为渲染状态，所以转移了一部分本应在客户端上执行的渲染操作，因此能够提升客户端的性能。此外，由于客户端侧分别针对视频播放数据和业务数据使用单独的界面控件，所以客户端抽离业务相关的冗余代码，一方面，让第一界面控件只关注播放逻辑，避免关注其他无关的UI操作，即将UI相关的操作以及播放器的操作逻辑分离。另一方面，终端侧也无需执行UI相关的渲染指令。进一步减少性能损耗，加快视频卡片的生成速度和起播速度。

附图说明

图1为本申请实施例中前端平台与终端的一种交互示意图；

图2为本申请实施例中处理视频画面的方法的一种流程示意图；

图3为本申请实施例中处理视频画面的方法的一种流程示意图；

图4为本申请实施例中目标视频画面的一种界面示意图；

图5a为本申请实施例中父界面控件的一种结构示意图；

图5b为本申请实施例中页面控件框架的一种结构示意图；

图6a为本申请实施例中对播放界面放大显示的一种流程示意图；

图6b为本申请实施例中对播放界面放大显示前后对比的一种界面示意图；

图7a为本申请实施例中页面控件框架中video view移动前的一种结构示意图；

图7b为本申请实施例中页面控件框架中video view移动后的一种结构示意图；

图8为本申请实施例中对播放界面缩小显示的一种流程示意图；

图9为本申请实施例中现有方案与本方案在客户端的开发周期的一种对比示意图；

图10为本申请实施例中现有方案与本方案在首帧画面的平均播放耗时的一种对比示意图；

图11为本申请实施例中区块链系统的一种结构示意图；

图12为本申请实施例中视频画面处理装置的一种结构示意图；

图13为本申请实施例中视频画面处理装置的一种结构示意图；

图14为本申请实施例中视频画面处理装置的一种实体结构示意图；

图15为本申请实施例中终端的一种结构示意图；

图16为本申请实施例中前端平台的一种结构示意图。

具体实施方式

本申请实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块，本申请实施例中所出现的模块的划分，仅仅是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式，例如多个模块可以结合成或集成在另一个系统中，或一些特征可以忽略，或不执行，另外，所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块之间的间接耦合或通信连接可以是电性或其他类似的形式，本申请实施例中均不作限定。并且，作为分离部件说明的模块或子模块可以是也可以不是物理上的分离，可以是也可以不是物理模块，或者可以分布到多个电路模块中，可以根据实际的需要选择其中的部分或全部模块来实现本申请实施例方案的目的。

本申请实施例供了一种处理视频画面的方法、相关装置及存储介质，可用于在线播放、本地播放等应用场景。该方案可用于终端侧，终端侧可用于对待播放的首帧画面进行生成和显示操作。本申请实施例仅以终端为例，终端侧可部署客户端(也可称作视频画面处理装置，该客户端可为视频客户端或音视频客户端，本申请实施例不对此作限定)，本申请实施例中终端可以是区块链系统中的节点。一些实施方式中，本申请实施例主要涉及前端平台和终端，如图1所示的前端平台与终端的一种交互示意图，以下进行详细说明。

如图1所示，在前端平台对待处理的目标视频进行拆解，得到视频播放数据和业务数据，编写脚本代码，以生成一系列与UI相关的渲染指令，对业务数据进行渲染，根据视频播放数据和业务数据生成首帧画面，然后将包含首帧画面的目标视频通过终端底层的页面控件框架中的桥接器发送到终端内安装的客户端。客户端中的video view和播放组件关联，且业务view和video view受页面控件组件的控制。

其中，需要特别说明的是，本申请实施例涉及的前端平台是指网站前台部分，运行在计算机端，移动端等浏览器上展现给用户浏览的网页。前端平台可为服务器或网页服务器。

本申请实施例涉及的终端，可以是指向用户提供语音和/或数据连通性的设备，具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备。例如移动电话(或称为“蜂窝”电话)和具有移动终端的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语音和/或数据。例如，个人通信业务(英文全称：Personal Communication Service，英文简称：PCS)电话、无绳电话、会话发起协议(SIP)话机、无线本地环路(Wireless Local Loop，英文简称：WLL)站、个人数字助理(英文全称：Personal Digital Assistant，英文简称：PDA)等设备。

本申请实施例主要提供以下技术方案：

一、从提升终端的性能和生成首帧卡片的生成速度上

前端平台对待播放的视频a中的首帧数据进行拆解，得到视频播放数据和业务数据，然后对业务数据进行渲染，再基于已渲染的业务数据和视频播放数据生成首帧画面并将包含首帧画面的视频a’发送给终端。终端从前端平台获取待播放的视频a’，分别采用两个单独的界面控件去控制首帧画面中的业务数据以及视频播放数据，进而在生成首帧卡片(即面向用户提供播放入口的目标视频画面)时，能够更加关注视频播放数据的处理，因此能够降低终端的性能损耗和提高首帧卡片的生成速度。

二、从视频画面的缩放显示上

例如，以对播放的视频画面进行全屏显示和退出全屏显示为例。通过采用点击图标选项、拖拽、抓取等方式即可实现，本申请实施例不对此作限定。

其中，对视频画面的缩放显示，本申请实施例主要涉及以下场景：

(1)、对视频界面进行缩小的场景包括：

a、对无任何缩小或放大的界面进行缩小显示。

b、对已经放大的视频界面进行缩小显示。

c、对已经缩小过的界面进行缩小显示。其中，第c点包括：缩小过1次，非首次缩小。

(2)、对视频界面进行放大的场景包括：

a、对无任何缩小或放大的界面进行放大显示。

b、对已经放大的视频界面进行放大显示。其中，第b点包括：放大过1次，非首次放大。

c、对已经缩小过的视频界面进行放大显示。

参照图2，以下先从前端平台角度介绍本申请实施例所提供的一种处理视频画面的方法，本申请实施例包括：

201、从待处理的目标视频中获取首帧数据。

其中，所述目标视频为将传送至终端进行在线播放的视频。所述首帧数据包括视频播放数据和业务数据，所述首帧数据为初始状态下的视频数据，并未将视频播放数据和业务数据进行逻辑分离。也可将首帧数据称作视频卡片，首帧画面等，具体本申请实施例不对此作限定。

业务数据是指与视频相关的业务数据，例如，业务数据包括标题、头像、播放量以及评论数等。

202、从所述首帧数据中获取视频播放数据和业务数据。

一些实施方式中，可通过拆解首帧数据的方式获取视频播放数据和业务数据。获取到的业务数据可以单独设置前端的UI标签。

203、对所述业务数据进行渲染。

一些实施方式中，此外，对业务数据再次拆解成单个类数据，分别设置给前端的UI标签。具体来说，所述对所述业务数据进行渲染，包括：

将所述业务数据拆分为至少一个类的数据；

按照数据所属的类，分别为各类的数据设置用户界面UI标签；

将所述至少一个类的数据生成至少一张视频简介；

对所述至少一张视频简介分别进行渲染，得到业务UI元素，所述业务UI元素用于展示业务的业务形态和业务逻辑。

例如，头像图片数据设置给前端的Image标签，播放量数据设置给前端的text标签来实现复杂的业务逻辑。

一些实施方式中，可采用native自带的渲染引擎和UI框架对业务数据进行渲染，或者采用Flutter对业务数据进行渲染，本申请实施例不对业务数据的渲染方式和渲染工具作限定。

可见，在前端平台侧，将业务数据和视频播放数据相互拆解。这样，当终端侧基于视频播放数据和已渲染的业务数据生成目标视频画面时，就可以仅将视频播放数据设置给video view，进而使得video view只专注于播放逻辑，加快目标视频画面的生成速度。此外，由于将业务数据再次拆解成单个类的数据，并分别设置给前端的UI标签，所以，能够将渲染的操作在前端平台侧实现，那么，使得第一界面控件无需执行来自前端平台的UI相关的渲染指令，即使得终端侧无须去处理冗余的业务代码，因此，能够有效的降低终端的性能损耗，也不会因为执行渲染指令拖慢播放组件播放视频播放数据的逻辑。并且，通过对首帧数据进行拆解和渲染，能够让终端侧的video view更多的只关注于视频播放数据本身的播放逻辑，无须去处理冗余的业务代码，进而加快目标视频画面的生成速度和起播速度。

204、根据所述视频播放数据和已渲染的业务数据，生成首帧画面。

其中，首帧画面为将视频播放数据和业务数据进行逻辑分离的视频画面，可参考图4所示的一种首帧画面示意图，用户可通过点击操作即可进入播放该目标视频的播放界面。

205、向终端发送包括所述首帧画面的目标视频。

与现有技术相比，本申请实施例中，通过将原始的首帧数据中的视频播放数据和业务数据进行逻辑分离处理，然后对业务数据进行渲染，根据所述视频播放数据和已渲染的业务数据，生成首帧画面。一方面中，通过将原始的首帧数据中的视频播放数据和业务数据进行逻辑分离处理，能够降低终端侧处理首帧数据的复杂度，另一方面中，对业务数据进行渲染，即将渲染操作在前端平台实现，终端侧在处理首帧数据时更加关注播放逻辑，由于不用渲染UI元素，所以能够降低性能损耗、提高首帧画面的生成速度，进而减少用户看到首帧画面的时间。

参照图3，以下从终端侧的角度介绍本申请实施例所提供的一种处理视频画面的方法，该方法由终端侧执行，在图2所对应的实施例中，对上述目标视频的首帧数据进行处理，得到包含首帧画面的目标视频后，该目标视频由终端侧获取后，会对该目标视频中的首帧画面进行处理，以在终端侧进行播放。本申请实施例中的目标视频可以是在线播放，也可以是终端侧本地播放，本申请实施例不限定目标视频的获取渠道和获取方式。本申请实施例仅以前端平台与终端之间的在线播放这种交互场景为例，其他播放场景不作限定。具体来说，本申请实施例包括：

301、获取目标视频的首帧画面。

其中，所述首帧画面包括视频播放数据和已渲染的业务数据。

所述目标视频为将传送至终端进行在线播放的视频。所述首帧数据包括视频播放数据和业务数据，所述首帧数据为初始状态下的视频数据，并未将视频播放数据和业务数据进行逻辑分离。也可将首帧数据称作视频卡片，首帧画面等，具体本申请实施例不对此作限定。

业务数据是指与视频相关的业务数据，例如，业务数据包括标题、头像、播放量以及评论数等。

需要说明的是，本申请实施例中的目标视频可以是在线播放，也可以是终端侧本地播放，本申请实施例不限定目标视频的获取渠道和获取方式。

302、将所述视频播放数据关联到第一界面控件以及将所述业务数据关联到第二界面控件。

其中，所述第一界面控件用于控制播放组件播放所述视频播放数据的播放逻辑，例如控制播放器的换链、播放、暂停和续播等操作。

所述第二界面控件用于控制所述业务数据在用户界面上的显示以及控制业务逻辑，例如播放量、热度、评论数、视频标签、作者信息等业务数据的显示逻辑。所述第二界面控件是指业务view。所述第二界面控件承载了需要展示的业务UI元素，例如播放按钮、播放量、标题等。

对于业务而言，播放器主要关注和提供播放需求(即提供播放、暂停、续播等功能)，并不能很好的展示播放中视频具体的业务形态(例如展示视频热度、视频的总播放量、视频评论数等业务数据)，但是如果将业务数据夹杂在video view中，会使原本复杂的播放器逻辑更加复杂，所以本申请实施例采用一种新的播放业务展示组件满足播放和业务相辅相成，且易于后续扩展开发的需求。该播放业务展示组件可包括第一界面控件(即专用于控制播放逻辑)和第二界面控件(即用于控制业务逻辑)。

在本申请的一些实施例中，本方法可基于页面控件框架实现，该页面控件框架包括父界面控件、所述第一界面控件、所述第二界面控件和所述播放组件。其中，所述第一界面控件和所述第二界面控件属于同一个父界面控件。页面控件框架可为动态化框架，例如为Viola、Weex或Hippy等动态化框架。如图5a所示的父界面控件框架的一种结构示意图，图5a揭示了父界面控件(即parent view)、video view(即第一界面控件)和业务view(即第二界面控件)三者之间的从属关系。

将首帧画面进行拆分，拆分出视频播放数据和业务数据，并分别关联到videoview(即第一界面控件)和业务view(即第二界面控件)，以及将业务view默认作为videoview的兄弟节点。对于video view和业务view二者共同的parent view的布局顺序来说，业务view的布局是盖在video view上层的，业务view便于展示具体的业务逻辑或者实现悬浮操作栏逻辑等。

一些实施方式中，在获取该界面控件框架后，将所述首帧画面生成目标视频画面之前，还可以设置父控件与view控件之间的调用关系、调用方式以及通信方式，以使第一界面控件更加专注于播放组件的逻辑控制、播放逻辑与业务逻辑的解耦、以及实现播放过程中与前端平台的交互。具体来说，所述方法还包括：

将所述第一界面控件与所述播放组件关联；

设置所述父界面控件与所述第一界面控件之间的调用方式和通信方式。

303、通过所述第一界面控件和所述第二界面控件，将所述首帧画面生成目标视频画面。

其中，目标视频画面是指面向用户提供播放入口的视频画面，用户通过点击该视频画面即可触发播放组件播放目标视频的播放逻辑。

与现有技术相比，本申请实施例中，由于从前端平台获取的首帧画面中的业务数据和视频播放数据已经在逻辑上分离且业务数据为渲染状态，所以转移了一部分本应在客户端上执行的渲染操作，因此能够提升客户端的性能。此外，由于客户端侧分别针对视频播放数据和业务数据使用单独的界面控件，所以客户端抽离业务相关的冗余代码，一方面，让第一界面控件只关注播放逻辑，避免关注其他无关的UI操作，即将UI相关的操作以及播放器的操作逻辑分离。另一方面，终端侧也无需执行UI相关的渲染指令。进一步减少性能损耗，加快视频卡片的生成速度和起播速度。

一些实施方式中，将所述首帧画面生成目标视频画面之后，还可以对该目标视频画面进行播放，以快速的展示给用户。该方法还包括：

通过所述第一界面控件展示所述目标视频画面中的视频播放数据，以及通过所述第二界面控件展示所述目标视频画面中的业务数据；

接收用户的第一消息，所述第一消息用于请求播放所述目标视频；

通过所述第一界面控件启动所述播放组件，以控制所述播放组件播放所述目标视频画面。

可见，由于通过第一界面控件和第二界面控件将播放逻辑与业务逻辑解耦，在播放首帧画面(即目标视频画面)时，只需要用第一界面控件控制目标视频画面的播放即可忽略那些由第二界面控件控制的业务逻辑的显示，因此能够提高播放首帧画面(即目标视频画面)的速度。

一些实施方式中，在设置父界面控件与各子控件(即第一界面控件和第二界面控件)之间的调用关系、调用方式以及通信方式后，可通过所述父界面控件调用所述第一界面控件，以启动所述播放组件显示所述目标视频画面；以及通过所述父界面控件接收所述第一消息。

例如，第一界面控件为video view，父界面控件为parent view。如图5b所示的页面控件框架的一种结构示意图中，页面控件框架提供的view能够实现UI逻辑删减，例如对播放界面上的UI元素的布局信息进行更新，以及对播放界面上的UI元素进行可见性变化切换(例如将UI元素在可见性与不可见性之间切换)。为使video view更加专注于播放器的逻辑控制，比如play、pause、replay、stop等函数，而在parent view里，会以接口的形式去调用video view的播放逻辑，由于parent view继承了页面控件框架(例如动态化框架Viola)提供的组件view，所以parent view具备动态化框架的双向通信的能力，因此能够实现播放过程中与前端平台的交互。并且，通过这种形式也实现了逻辑分离，方便后续业务的扩展和原有业务的维护。

可选的，在本申请实施例的一些实施例中，用户在观看目标视频的过程中，可能会对目标视频的播放界面进行放大(例如全屏显示、按照一定比例放大当前的播放界面)、缩小(例如退出全屏显示、按照一定比例缩小当前的播放界面)等操作。在现有的首帧画面中展示具体业务形态的业务view的宽、高和大小往往是提前指定和写死的，在视频全屏且页面旋转的情况下，之前指定的宽、高将不再适用，会导致目标视频放大后的播放页面中所有的UI元素错乱。如果在全屏过程中通过干预初始业务view的展示和布局以保证UI元素不错乱，则会带来较大的性能开销。因此，为保证执行这些操作(放大显示或缩小显示)时，播放界面与显示屏之间的适应性、UI元素的布局不错乱，无需针对每个UI元素实施重新布局，可以在页面控件框架中引入对象类和modal组件。其中，抽象类是指不断抽取共性需求而来的父类，抽象类是对功能和属性的声明，表示这类事物应该具备这些内容。抽象类包括window等。Modal组件则是根据最初始的帧布局(Frame layout)改造而来，主要是通过显示和隐藏业务逻辑。Modal组件与第二界面控件(即业务view)关联。

下面分别从对目标视频的播放界面进行放大显示、缩小显示来介绍：

一、对目标视频的播放界面进行放大显示

用户可在客户端点击图标、手势操作等方式触发对目标视频的播放界面的放大操作，具体来说，如图6a所示，本申请实施例包括：

401、接收第二消息。

其中，所述第二消息用于请求对所述目标视频的第一播放界面进行放大显示。

402、将所述第一界面控件从所述父界面控件移动至所述抽象类中。

一些实施方式中，所述将所述第一界面控件从所述父界面控件中移动至抽象类中，包括：

将所述第一界面控件从所述父界面控件中移除，记录所述第一界面控件在所述父界面控件中的初始索引和初始布局信息；

清空设置在所述第一界面控件上的所述初始布局信息；

将所述第一界面控件添加到所述抽象类中。

例如图7a所示，图7a为对第一播放界面进行放大显示之前的页面控件框架的视图层级结构图，7b为对第一播放界面进行放大显示之后的页面控件框架的结构层次图。将要全屏的video view(即第一界面控件)从图7a所示的视图层级结构中抽离出来，记录该video view在图7a的parent view(即父界面控件)中的Index，在图7a的parent view中的初始布局信息。将设置在该video view上的初始布局信息清空。然后将要全屏的videoview添加到window中，得到如图7b所示的页面控件框架的结构层次图。

403、将所述第一播放界面的尺寸更新为所述抽象类中的尺寸设置信息。

一些实施方式中，所述将所述第一播放界面的尺寸更新为所述抽象类中的尺寸设置信息，包括：

为所述第一界面控件设置新布局信息；

按照所述父界面控件中的尺寸设置信息，设置所述第一播放界面的目标尺寸；

根据所述新布局信息和所述目标尺寸生成所述第二播放界面。

例如，在将video view添加到window上的同时，需要给这个video view设置新的布局描述信息，将宽、高都设置成和parent view一致，其中它的parent view已经变成了window中设置的尺寸，而window与显示屏的屏幕等宽高，因此，此时已经实现UI元素自适应的目的。

404、通过调用所述抽象类显示所述第一播放界面。

一些实施方式中，在通过调用所述抽象类显示所述第一播放界面时，还可以隐藏所述第一播放界面中的业务数据，例如对当前第一播放界面进行全屏显示时，可隐藏。具体来说，在接收第二消息之后，所述旋转所述第一播放界面之前，将所述第二界面控件从所述父界面控件移动至所述抽象类中，将所述第二界面控件设置为不可见。第二界面控件与Modal组件关联时，可将Modal组件从window上移除，再将Modal组件添加回初始的业务view层级中，同时将业务view的可见性设置为不可见，如此则能实现恢复原先业务方设置的宽高大小，并隐藏。

可见，在全屏显示时，通过隐藏业务逻辑，能够使业务方在全屏场景下，更加便捷、高效的实现业务逻辑，以及减少性能开销。

405、旋转所述第一播放界面，以生成第二播放界面。

一些实施方式中，可通过旋转Activity实现旋转所述第一播放界面，来使视图布局的宽高对调，来达到横屏观看的更好体验，同时在旋转过程中Activity会自动保存数据来使视图在全屏前后表现正常，因此，在对第一播放界面进行放大显示的过程中调用Activity的自旋转方法即可。在视频全屏前，对业务方的业务表现往往是无感知的，例如，第一播放界面在全屏前是状态栏，导航栏都可见的情形，为了实现良好的全屏效果，此时需要将状态栏、导航栏等隐藏。

如图6b所示，当前正在播放目标视频的第一播放界面，该第一播放界面的边界与显示屏边界存在一定距离，当接收到用户针对该第一播放界面的放大指令后，采用本申请实施例的方案对第一播放界面进行放大，得到第二播放界面。

406、显示所述第二播放界面。

举例来说，针对任意放大的场景，可以将view从原先的view层级中抽离添加到window上，来达到不造成UI元素错乱的目的，为下一步拉伸宽高做准备。在本申请实施例中，添加到window上的video view使用的是自适应布局属性来实现和window同宽高乃至和手机屏幕同宽高的思路，这里也可以手动设置video view的宽高来达到任意放大video的目的。

比如，video view的初始尺寸：宽400dp、高500dp，在将video view添加到window之后，设置宽、高分别为800dp、1000dp，此时video view已经实现放大。

(1)如果第一播放画面当前处于已经放大过一定比例，在当前的放大比例的基础上还需再放大，那么，此时还是沿用本方案的思路能达到再次方案的目的。流程是首先将其从原先的view层级中抽离添加到window上，然后再设置一个更大的宽高即可(如果放大之前，video view已经被添加到了window上，则此时直接设置宽高即可，无须有动态调整view层级的过程)

(2)如果第一播放画面当前处于已经缩小到了一定比例，在当前缩小的基础下还需放大，首先调整view的层级关系，再设置一个更大的宽高即可(具体实现思路可以参照前述针对放大显示的实施例)。

可见，在进入全屏时采用了将video view从原先的层级结构中抽离，同时将videoview添加到window上，来实现UI自适应的一个过程。最后再旋转Activity使整个视图布局的宽高对调，使全屏之前的video view以90度角度旋转至屏幕全屏，来达到更好的横屏观看体验。由于前端侧发起全屏指令，客户端侧收到指令时采用本方案提供的解决思路自行消化处理，无须前端侧的过多干预，能够保证逻辑的干净整洁以及可维护性。

二、对目标视频的播放界面进行缩小显示

用户可在客户端点击图标、手势操作等方式触发对目标视频的播放界面的缩小操作，具体来说，如图8所示，本申请实施例包括：

501、接收第三消息。

其中，所述第三消息用于请求对所述目标视频的第一播放界面进行缩小显示。

一些实施方式中，如果在放大显示过程(例如全屏过程)中隐藏了状态栏和导航栏，那么，此时需要将业务方的业务展示逻辑恢复(如有的话)，具体来说，在接收第三消息之后，旋转所述第一播放界面之前，将所述第二界面控件从所述抽象类中移动至所述父界面控件的初始层级，将所述第二界面控件设置为可见。

502、将所述第一界面控件从所述抽象类移动至所述父界面控件中。

将所述第一界面控件从所述抽象类移动至所述父界面控件中，即可恢复videoview的初始层级。由于在放大目标视频的播放界面过程中将video view添加到了window上，那么，此时将video view从window上剥离出来，并清除该video view当前的布局信息，结合之前存储的初始位置信息，将video view重新添加回初始parent view里面。

503、通过调用所述第一界面控件显示所述第一播放界面。

504、旋转所述第一播放界面，以生成第二播放界面。

一些实施方式中，可采用activity调用旋转的逆方法旋转第一播放界面。

505、显示所述第二播放界面。

本申请实施例中，在对播放界面放大显示时，前端隐藏业务逻辑，让业务方在放大场景下，更加便捷，高效的实现业务逻辑，能够减少性能开销。

为便于理解，下面以连带模式业务介绍本申请实施例中的处理视频画面的方法，该连带模式业务为通信客户端的看点视频中的视频业务。看点视频的看点用户通过在该通信客户端的看点视频中点击视频频道，点击视频频道里的视频卡片即可跳转至对应的播放界面。其中，连带模式是看点用户消费视频的主页面。主界面包括竖向视频卡片流、横向视频卡片流或横竖混合流等至少一种组合。该主界面中的业务交互复杂，在看点视频的播放器端涉及视频暂停、续播、全屏、静音以及进度条拖动等功能，在页面端行为涉及滑动播放下一个、全屏之后播放下一个等，在业务端涉及双击点赞、分享好友、分享看点以及评论等。

本申请实施例中，基于页面控件框架Viola实现第一界面控件(即video view组件)。如图9所示，展示了连带模式native化、以及连带模式viola化的人力对比示意图，在连带模式native化下，开发客户端的工作量主要涉及服务端和客户端，分别在服务端和客户端所花的开发耗时大约为34日，每端均需要投入2名开发人员。而采用本申请实施例的方案后，在连带模式viola化下，由于业务逻辑迁移到了前端平台去开发，而客户端的开发人员只需要聚焦在实现video view组件，因此在采用该方案的版本中。客户端的开发人员只需要投入42天即可完成，viola页面耗时27日，工序投入5名开发人员，其中，连带模式viola化的开发(即改造native、开发业务逻辑)均在客户端完成。由此可见，采用本申请的方案，能够有效缩短开发周期。

此外，在视频播放的关键数据指标方面。采用本方案实现的video view组件与纯native实现的video view组件相比，也有更加优越的性能表现。以视频播放首帧的平均耗时这个关键指标为例，由于采用本方案实现的video view组件从生成到播放的过程中剥离了业务耦合的逻辑，例如将上报、渲染等业务逻辑均迁移至前端平台实现，因此，用户看到首帧画面的时间会更短。如图10所示的现有方案与本方案在首帧画面的平均播放耗时的一种对比示意图。图10中，虚线为采用本方案实现的video view组件播放首帧的平均耗时(大约为260ms)。实线是纯native实现的video view组件的平均耗时(大约为380ms)。

本申请实施例中，上述首帧数据、首帧画面和目标播放画面均可保存在区块链中。其中，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

本申请实施例中执行处理视频画面的方法的视频画面处理装置(也可称作服务器)可以是区块链系统中的节点。本申请实施例中的视频画面处理装置可以是如图11所示的一种区块链系统中的节点。

图1至图10中任一项所对应的实施例中所提及的任一技术特征也同样适用于本申请实施例中的图12至图16所对应的实施例，后续类似之处不再赘述。

以上对本申请实施例中一种处理视频画面的方法进行说明，以下对执行上述视频画面处理装置(包括终端、前端平台)进行介绍。

参阅图12，如图12所示的一种视频画面处理装置60的结构示意图，其可应用于处理在线播放视频的首帧画面。本申请实施例中的视频画面处理装置能够实现对应于上述图1至图10中任一项所对应的实施例中所执行的处理视频画面的方法的步骤。视频画面处理装置60实现的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。所述视频画面处理装置60可包括输入输出模块601、处理模块602和显示模块603，所述输入输出模块601的功能实现可参考图1至图10中任一项所对应的实施例中所执行的获取、输出等操作，所述处理模块602的功能实现可参考图1至图10中任一项所对应的实施例中所执行的关联、生成等操作，此处不作赘述。例如，所述处理模块可用于控制所述输入输出模块的输入输出操作，以及控制所述显示模块的显示操作。

一些实施方式中，所述输入输出模块601可用于获取目标视频的首帧画面，所述首帧画面包括视频播放数据和已渲染的业务数据；

所述处理模块602可用于将所述输入输出模块601获取的所述视频播放数据关联到第一界面控件以及将所述业务数据关联到第二界面控件；通过所述第一界面控件和所述第二界面控件，将所述首帧画面生成目标视频画面，其中，所述第一界面控件用于控制播放组件播放所述视频播放数据的播放逻辑；所述第二界面控件用于控制所述业务数据在用户界面上的显示以及控制业务逻辑。

一些实施方式中，所述处理模块602将所述首帧画面生成目标视频画面之后，还用于：

通过所述第一界面控件展示所述目标视频画面中的视频播放数据，以及通过所述第二界面控件展示所述目标视频画面中的业务数据；

通过搜索输入输出模块601接收用户的第一消息，所述第一消息用于请求播放所述目标视频；

通过所述第一界面控件启动所述播放组件，以控制所述播放组件播放所述目标视频画面。

一些实施方式中，所述装置60基于页面控件框架实现，所述第一界面控件和所述第二界面控件属于同一个父界面控件，所述处理模块602将所述首帧画面生成目标视频画面之前，还用于：

将所述第一界面控件与所述播放组件关联；

设置所述父界面控件与所述第一界面控件之间的调用方式和通信方式；

相应的，所述处理模块602具体用于：

通过所述父界面控件调用所述第一界面控件，以启动所述播放组件显示所述目标视频画面；

所述输入输出模块601通过所述父界面控件接收所述第一消息。

一些实施方式中，所述页面控件框架还包括抽象类，处理模块602还用于：

通过所述输入输出模块601接收第二消息，所述第二消息用于请求对所述目标视频的第一播放界面进行放大显示；

将所述第一界面控件从所述父界面控件移动至所述抽象类中；

将所述第一播放界面的尺寸更新为所述抽象类中的尺寸设置信息；

通过调用所述抽象类显示所述第一播放界面；

旋转所述第一播放界面，以生成第二播放界面；

通过所述显示模块603显示所述第二播放界面。

一些实施方式中，所述处理模块602具体用于：

将所述第一界面控件从所述父界面控件中移除，记录所述第一界面控件在所述父界面控件中的初始索引和初始布局信息；

清空设置在所述第一界面控件上的所述初始布局信息；

将所述第一界面控件添加到所述抽象类中。

一种可能的设计中，所述处理模块具体用于602：

为所述第一界面控件设置新布局信息；

按照所述父界面控件中的尺寸设置信息，设置所述第一播放界面的目标尺寸；

根据所述新布局信息和所述目标尺寸生成所述第二播放界面。

一些实施方式中，所述处理模块602在搜索输入输出模块601接收第二消息之后，旋转所述第一播放界面之前，还用于：

将所述第二界面控件从所述父界面控件移动至所述抽象类中；

将所述第二界面控件设置为不可见。

一些实施方式中，所述页面控件框架还包括抽象类，搜索处理模块602还用于：

通过所述输入输出模块601接收第三消息，所述第三消息用于请求对所述目标视频的第一播放界面进行缩小显示；

将所述第一界面控件从所述抽象类移动至所述父界面控件中；

通过调用所述第一界面控件显示所述第一播放界面；

旋转所述第一播放界面，以生成第二播放界面；

通过所述显示模块603显示所述第二播放界面。

一些实施方式中，所述处理模块602在所述输入输出模块601接收第三消息之后，旋转所述第一播放界面之前，还用于：

将所述第二界面控件从所述抽象类中移动至所述父界面控件的初始层级；

将所述第二界面控件设置为可见。

一些实施方式中，所述目标视频画面保存在区块链节点上。

本申请实施例中，由于从前端平台获取的首帧画面中的业务数据和视频播放数据已经在逻辑上分离且业务数据为渲染状态，所以转移了一部分本应在客户端上执行的渲染操作，因此能够提升客户端的性能。此外，由于客户端侧分别针对视频播放数据和业务数据使用单独的界面控件，所以客户端抽离业务相关的冗余代码，一方面，让第一界面控件只关注播放逻辑，避免关注其他无关的UI操作，即将UI相关的操作以及播放器的操作逻辑分离。另一方面，终端侧也无需执行UI相关的渲染指令。进一步减少性能损耗，加快视频卡片的生成速度和起播速度。

参阅图13，本申请实施例还提供一种视频画面处理装置70，该视频画面处理装置70可为前端平台，也可以为部署于前端平台的软件，本申请实施例不对此作限定。该视频画面处理装置70包括：

处理模块701，用于从待处理的目标视频中获取首帧数据；从所述首帧数据中获取视频播放数据和业务数据；

渲染模块702，用于对所述处理模块701获取的所述业务数据进行渲染；

所述处理模块701还用于根据所述视频播放数据和已渲染的业务数据，生成首帧画面；

输入输出模块703用于向终端发送包括所述首帧画面的目标视频。

一些实施方式中，所述处理模块701具体用于：

将所述业务数据拆分为至少一个类的数据；

按照数据所属的类，分别为各类的数据设置用户界面UI标签；

将所述至少一个类的数据生成至少一张视频简介；

对所述至少一张视频简介分别进行渲染，得到业务UI元素，所述业务UI元素用于展示业务的业务形态和业务逻辑。

一些实施方式中，所述首帧画面保存在区块链节点上。

本申请实施例中，处理模块701将业务数据和视频播放相关的数据相互拆解。将视频播放相关的数据设置给第一界面控件让其只专注于播放逻辑即可，加快复杂视频卡片的生成速度。此外，对业务数据再次拆解成单个类数据，分别设置给前端的UI标签。拆解加渲染的目的是让终端侧的第一界面控件更多的只关注于播放本身的播放逻辑，无须去处理冗余的业务代码，加快卡片的生成速度和起播速度

上面从模块化功能实体的角度对本申请实施例中的视频画面处理装置(包括图12、图13所示的装置)进行了描述，下面从硬件处理的角度分别对本申请实施例中的执行处理视频画面的方法的终端、服务器进行描述。需要说明的是，在本申请实施例图12所示的实施例中的输入输出模块603对应的实体设备可以为输入/输出单元、收发器、射频电路、通信模块和输出接口等，处理模块601对应的实体设备可以为处理器。例如，图12所示的装置60可以具有如图14所示的结构，当图12所示的装置60具有如图14所示的结构时，图14中的处理器和输入/输出单元能够实现前述对应该装置的装置实施例提供的处理模块601、输入输出模块602相同或相似的功能，图14中的存储器存储处理器执行上述处理视频画面的方法时需要调用的计算机程序。

又例如，图13所示的装置70可以具有如图14所示的结构，当图13所示的装置70具有如图14所示的结构时，图14中的处理器和输入/输出单元能够实现前述对应该装置的装置实施例提供的处理模块701、渲染模块702、输入输出模块703相同或相似的功能，图14中的存储器存储处理器执行上述处理视频画面的方法时需要调用的计算机程序。

图15是本申请实施例提供的手机本申请实施例还提供了另一种终端，如图15所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端设备可以为包括手机、平板电脑、个人数字助理(英文全称：Personal Digital Assistant，英文简称：PDA)、销售终端(英文全称：Point of Sales，英文简称：POS)、车载电脑等任意终端设备，以终端为手机为例：

图15示出的是与本申请实施例提供的终端设备相关的手机的部分结构的框图。参考图15，手机包括：射频(英文全称：Radio Frequency，英文简称：RF)电路1515、存储器1520、输入单元1530、显示单元1540、传感器1550、音频电路1560、无线保真(英文全称：wireless fidelity，英文简称：WiFi)模块1570、处理器1580、以及电源1590等部件。本领域技术人员可以理解，图15中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图15对手机的各个构成部件进行具体的介绍：

RF电路1515可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1580处理；另外，将设计上行的数据发送给基站。通常，RF电路1515包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(英文全称：LowNoise Amplifier，英文简称：LNA)、双工器等。此外，RF电路1515还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(英文全称：Global System of Mobile communication，英文简称：GSM)、通用分组无线服务(英文全称：General Packet Radio Service，英文简称：GPRS)、码分多址(英文全称：Code Division Multiple Access，英文简称：CDMA)、宽带码分多址(英文全称：Wideband Code Division Multiple Access,英文简称：WCDMA)、长期演进(英文全称：LongTerm Evolution，英文简称：LTE)、电子邮件、短消息服务(英文全称：Short MessagingService，英文简称：SMS)等。

存储器1520可用于存储软件程序以及模块，处理器1580通过运行存储在存储器1520的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1520可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1520可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1530可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1530可包括触控面板1531以及其他输入设备1532。触控面板1531，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1531上或在触控面板1531附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1531可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1580，并能接收处理器1580发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1531。除了触控面板1531，输入单元1530还可以包括其他输入设备1532。具体地，其他输入设备1532可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1540可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1540可包括显示面板1541，可选的，可以采用液晶显示器(英文全称：Liquid Crystal Display，英文简称：LCD)、有机发光二极管(英文全称：Organic Light-Emitting Diode,英文简称：OLED)等形式来配置显示面板1541。进一步的，触控面板1531可覆盖显示面板1541，当触控面板1531检测到在其上或附近的触摸操作后，传送给处理器1580以确定触摸事件的类型，随后处理器1580根据触摸事件的类型在显示面板1541上提供相应的视觉输出。虽然在图15中，触控面板1531与显示面板1541是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1531与显示面板1541集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器1550，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1541的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1541和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1560、扬声器1561，传声器1562可提供用户与手机之间的音频接口。音频电路1560可将接收到的音频数据转换后的电信号，传输到扬声器1561，由扬声器1561转换为声音信号输出；另一方面，传声器1562将收集的声音信号转换为电信号，由音频电路1560接收后转换为音频数据，再将音频数据输出处理器1580处理后，经RF电路1515以发送给比如另一手机，或者将音频数据输出至存储器1520以便进一步处理。

Wi-Fi属于短距离无线传输技术，手机通过Wi-Fi模块1570可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图15示出了W-iFi模块1570，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变申请的本质的范围内而省略。

处理器1580是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1520内的软件程序和/或模块，以及调用存储在存储器1520内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1580可包括一个或多个处理单元；优选的，处理器1580可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1580中。

手机还包括给各个部件供电的电源1590(比如电池)，优选的，电源可以通过电源管理系统与处理器1580逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本申请实施例中，该手机所包括的处理器1580还具有控制执行以上由图12所示的装置60执行的方法流程。

图16是本申请实施例提供的一种服务器结构示意图，该服务器820可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(英文全称：centralprocessing units，英文简称：CPU)822(例如，一个或一个以上处理器)和存储器832，一个或一个以上存储应用程序842或数据844的存储介质830(例如一个或一个以上海量存储设备)。其中，存储器832和存储介质830可以是短暂存储或持久存储。存储在存储介质830的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器822可以设置为与存储介质830通信，在服务器820上执行存储介质830中的一系列指令操作。

服务器820还可以包括一个或一个以上电源826，一个或一个以上有线或无线网络接口850，一个或一个以上输入输出接口858，和/或，一个或一个以上操作系统841，例如windows Server，Mac OS X，Unix,Linux，FreeBSD等等。

上述实施例中由服务器所执行的步骤可以基于该图16所示的服务器820的结构。例如上述实施例中由图16所示的装置60所执行的步骤可以基于该图16所示的服务器结构。例如，所述处理器822通过调用存储器832中的指令，执行以下操作：

获取目标视频的首帧画面，所述首帧画面包括视频播放数据和已渲染的业务数据；

将所述输入输出模块获取的所述视频播放数据关联到第一界面控件以及将所述业务数据关联到第二界面控件；通过所述第一界面控件和所述第二界面控件，将所述首帧画面生成目标视频画面，其中，所述第一界面控件用于控制播放组件播放所述视频播放数据的播放逻辑；所述第二界面控件用于控制所述业务数据在用户界面上的显示以及控制业务逻辑。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请实施例所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

另外，在本申请实施例各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

以上对本申请实施例所提供的技术方案进行了详细介绍，本申请实施例中应用了具体个例对本申请实施例的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请实施例的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请实施例的限制。