CN104915200B - 移动操作系统中的视频帧处理的渲染方法 - Google Patents

Abstract

一种渲染视频帧的方法，通过一具有软件堆栈的计算装置进行，软件堆栈具有一应用层和一内核层，包括若干步骤。首先，初始化一个系统参考时间。等待一个内核层的中断信号的触发。其次，根据来自应用层的渲染函数确定是否更新系统参考时间。根据已确定的系统参考时间和下一个视频帧，通过计算装置渲染内核层中的下一个视频帧。初始化步骤之后的步骤和开始等待步骤是递归执行的。

Description

移动操作系统中的视频帧处理的渲染方法

技术领域

本发明涉及视频帧处理，尤其涉及在运行移动操作系统的计算装置上对视频帧渲染进行定时控制。

背景技术

一种计算装置，包括一移动操作系统，例如，Android，黑莓，iOS，Windows Phone，火狐OS，旗鱼OS，Symbian和Ubuntu Touch OS等，可运行多种软件应用程序(apps)，例如，视频游戏应用程序，视频流应用程序，新闻阅读器应用程序，等等。该移动操作系可以安装到计算装置上，例如，智能手机，平板电脑，笔记本电脑，掌上电脑，机顶盒，便携式电脑，等等。软件应用程序可以在比移动操作系统更高的软件层上运行。

由于应用程序的复杂性和应用程序的视频处理的数量之多，计算装置及时产生视频图像是有问题的，尤其在从媒体框架向应用程序层提供的更大的灵活性，以允许使用视频解码器并从一个用户空间级别控制视频帧渲染定时时，更是有问题的。特别的，计算装置可能无法满足应用程序对视频解码和视频渲染的及时请求，引起跳帧。

例如，一个运行在计算装置上的游戏应用程序可以由诸如C++、Java等编程语言编写。游戏应用程序运行于一应用层，但最终还是使用内核层的函数调用执行游戏应用程序的视频图像的解码和渲染。计算装置通过该它的视频解码器处理视频解码函数调用。解码的视频帧存储在计算装置的存储器内，并在选定的时间通过该计算装置的渲染模块渲染。

计算装置的处理器(例如，图形处理单元(GPU)或其它处理器)可用于作为解码器和渲染模块使用。然而，由于处理器一直在处理各种计算线程，处理器可能无法以适当的速率解码和渲染视频帧，以在计算装置的显示器上正确显示。当这些视频数据在显示器上显示时可能会导致跳帧。

跳帧进一步加剧了从应用层最终抵达内核层进行渲染的函数调用的时间延迟。典型的，游戏应用程序通过一个从媒体框架提供的应用程序接口(API)发送最新的将要渲染的帧至软件堆栈的下层(例如，发送至内核层)，以实现在内核层的实际渲染。然而，如果视频渲染落后于视频帧要被呈现的时间戳，则视频帧可能不在正确的时间呈现，并导致视频帧跳帧，视频帧的跳帧会导致不顺畅的视频播放，而这不是用户观看时所期望的。

因此，需要提供一种期望的方法、装置和系统，用于通过一个具有移动操作系统的计算设备进行视频渲染的定时控制，以减少或消除跳帧。

发明内容

本公开涉及一种用于呈现视频帧的方法，通过一具有一软件堆桟的计算装置提供，软件堆栈具有一应用层和一核心层，该方法包括以下步骤：初始化一个系统参考时间；等待直到在内核层触发一中断信号；根据应用层的渲染函数确定是否更新系统参考时间；根据决定的系统参考时间，通过计算装置在内核层呈现下一个视频帧，其中初始化之后的步骤和开始等待的步骤被递归执行。

附图说明

本公开公开的上述事项和其他方面可以更好地结合以下实施例的详细描述和附图理解。

图1示出了一个在计算装置上解码和渲染视频数据的框图。

图2示出了一个计算装置内的用于解码和渲染视频数据的内核空间的隧道模式。

图3示出了一个具有移动操作系统，如安卓系统的计算装置的软件堆桟的框图。

图4示出了一个通过移动操作系统的应用程序解码和渲染视频数据的流程图。

图5示出了一个在用户空间和内核空间内用于解码和渲染视频数据的混合系统的框图。

图6示出了一个在用户空间和内核空间内用于解码和渲染视频数据的混合系统的流程图。

图7示出了一个用于确定何时停止渲染视频帧的时序图。

具体实施方式

在以下具体实施例的详细描述中，参照附图，这些附图形成其一部分，并且通过附图示出具体实施方式以使发明更实际。

本公开提供一种方法、系统和装置，用于通过在运行移动操作系统的计算装置上的一应用程序进行渲染视频帧的定时控制。在应用程序能够从用户空间控制视频帧渲染的情况下，应用程序被赋予了更大的时间窗口(或更多的时间余量)，以满足对视频呈现的临界定时的需求。隧道模式用于视频渲染，这是一个内核层的进程，有助于用户空间水平内的应用程序按照隧道模式不断渲染帧。然而，当来自应用程序的渲染函数调用的时间戳大于在内核级内的系统参考时间一预设的门限值时，在隧道模式下的视频帧的渲染可以停止或暂停。以这种方式，视频帧渲染的定时控制可以使用一种混合方法来实现，其中在隧道模式和用户空间的应用程序编程接口(“API”)的渲染功能可以被同时在计算装置中使用。下面的附图和详细说明将有助于解释本发明及其核心思想。

图1示出了在一计算装置上解码和渲染视频数据的框图。计算装置可包括一个解码器10，一个渲染器12，一个视频帧缓冲器14(或其它存储器装置)，以及用于解码和渲染视频数据8到显示器(未示出)的显示接口16。显示器可以是连接到该计算装置的外部显示器或该计算装置的一内部显示器。

视频数据8可以输入到解码器10。解码器10的将视频数据解码成视频帧。所述视频帧可存储在计算装置的一个视频帧缓冲器14(或其它存储器)内，以用于后续渲染或者直接传递到渲染器12渲染。渲染器12通过显示接口16，渲染视频帧在显示器上。视频帧必须在适当的时间正确的显示，用于流畅的视频回放。显示接口16可在一个高清晰度多媒体接口(HDMI)上，一个模拟分量视频输出接口，和/或渲染视频帧的其它视频显示格式上提供使视频帧，以使其正确显示。

图2示出了计算装置的内核空间的隧道模式中的用于解码和显示视频数据的数据工作流程图。解码器20将视频数据生成解码的视频帧。解码的视频帧被放置在计算装置的存储器中。一个图形处理单元(“GPU”)，未示出，可以请求变换和组合解码的视频帧进入视频帧缓冲器22。视频帧可以随后在适当的时间通过视频显示输出驱动器24显示。视频显示驱动器24可以读取视频帧22，以输出到合适输出显示端口。

图3示出了具有移动操作系统的计算装置的软件堆栈的示意图。计算装置可具有安装和运行在计算装置上的移动操作系统。计算装置的软件堆栈30包括软件应用程序32，一个Android的媒体编码器API 34，一个媒体框架36(例如，一个Android媒体框架)，Linux内核38，和编解码器组件40。

Linux内核38是该计算装置的大多数软件的底层以提供大多数基础系统功能，例如进程管理，存储器管理，设备管理(例如，照相机，键盘，显示器等)，设备驱动器，网络，和/或其它系统功能。媒体框架36可以是倒数第二层，为专门设计和优化的安卓系统提供一虚拟机。框架传媒36还具有核心库，可以使Android应用程序程序开发人员使用标准的Java语言编写应用软件。该Android媒体编码器API34层允许在软件应用程序32层内的应用程序访问已安装在系统中的编解码器组件40并控制输出的渲染。软件应用程序32层包括在计算装置上运行的应用程序。

编解码器组件40作为具有两个部分的接口使用。第一部分位于用户空间内，用户空间连接到媒体框架36，第二部分是在内核空间内。当应用程序通过媒体编解码器API34发送数据(例如，排队输入数据等)给编解码器组件40时，编解码器组件40与媒体框架36的原生层和任何第三方库连接。来自编解码器组件40的数据被发送到内核层中的解码器部件和其它部件。

从软件的角度来看，一个应用程序使用应用程序编程接口，进行与软件堆栈的低层通信。例如，Android系统使用媒体编解码器API。应用层主要是用Java编程语言编写。本地层(或媒体框架层36)通常用C语言编写。Android的媒体框架层是比内核层高的一层，并作为中间层来管理各自系统的多媒体功能。该媒体解码器API是媒体框架的一部分，并且可以用于在软件堆栈的应用层和低层间的通信，低层可以为内核层。

图4示出一个流程图，用于通过用户空间的一移动操作系统的应用程序解码和渲染视频数据。在应用层的应用程序可以使用媒体编解码器API访问编解码器组件。在android系统中，应用程序控制视频渲染和图形应用程序的视频解码。该应用程序从一个媒体源获取视频数据，媒体源可能是一个本地媒体文件，也可以是在线流等。应用程序确定视频的格式，音频格式，视频的分辨率，和/或关于视频数据的其它信息，并经由媒体编解码器API配置编解码器组件。视频数据和音频数据可被解复用和单独处理。

该应用程序可以调用一个媒体编解码器函数，以将所述视频数据入列到一个解码器组件的输入端口42。从存储器中获得的视频数据被输入到解码器。解码器可以解码该获得的视频数据和并将解码的视频数据存储在存储器中。

接着，应用程序调用一个出列函数44，以获得解码的视频帧。该解码的视频帧可以从解码器的输出端口或从存储器出列。然后解码的视频帧准备好以在适当的时机输入渲染器渲染。视频帧的像素数据留在解码的视频帧缓冲器中，但附加到每个帧的时间戳信息的相关内容被传递回给应用程序侧，从而使应用程序具有一个解码视频帧的相关队列进行渲染。该媒体编码器API旨在让应用程序更加灵活，以便使应用程序可以决定一个视频帧何时可以基于音频视频同步管理，网络流媒体缓冲水平等呈现。

一旦解码视频帧准备好，当呈现给解码视频帧46时该应用程序执行检查。典型地，当检查功能执行时，各个计算装置根据基准时钟为每个视频帧检查时间戳。如果当前视频帧的时间戳是在下一个视频帧呈现前的一个时间范围内，则媒体编码器的渲染函数被调用，以渲染该帧。每个视频帧具有时间戳，它确定何时应显示该帧。举例来说，如果电影是每秒24帧，视频帧之间的时间长度是一秒的1/24。帧何时和如何被渲染可以由应用程序完全控制，以提供一种灵活性。

当一个解码的视频帧要被呈现时，应用程序调用一个渲染函数48来调用渲染器以渲染经解码的视频帧。渲染的帧可以被放置在一个视频帧缓冲器(或其它存储器)内。显示接口可以从那里输出渲染的帧到所述计算装置的显示器。一个媒体编解码器API的假设是，当渲染功能被调用时，媒体编解码器的渲染的实现足够的快，以便在下一个V-同步信号触发之前完成，并准备更改为新帧。

渲染函数是从应用程序中调用并使用Java语言编写。因此，渲染函数输入到一个java虚拟机，并传递给媒体框架的本地层。当渲染函数被调用时，由于函数从用户空间达到内核层之前的时间延迟，不能保证或确保定时。此外，计算装置的处理器可能过载，使得渲染功能的立即处理可能被延迟。当应用程序调用渲染函数时，计算装置可具有多个正在运行的CPU线程以从媒体源读取数据，馈送数据到解码器，并同时从该解码器获取已解码的输出，以及并行的音频处理。

图5示出用于在一个用户空间和内核空间内解码和渲染视频数据的混合系统的框图。在混合系统中，视频解码器58，视频帧缓冲器60，和一个视频显示输出驱动器62以类似的隧道模式渲染和解码。软件堆栈中的用户空间中的应用程序呼叫Android系统的媒体解码器API函数以控制隧道模式的内核层解码和渲染。例如，媒体解码器API 56函数要求队列50，出列52，及渲染54可以被调用以控制来自用户空间的内核空间的解码和渲染。

在混合系统中，隧道模式在适当的时机渲染视频帧缓冲器60中的视频帧，而不顾应用程序中的渲染函数。然而，渲染函数的时间戳被用来与一个系统参考时间的时间戳相比较。当所述系统参考时间超过所述渲染函数的时间戳一个预设的门限值时，隧道模式下的渲染暂停，直到系统参考时间不再超过渲染函数的时间戳一个预设的门限值为止。

图6示出了在一个用户空间和内核空间内用于解码和渲染视频数据的混合系统的流程图。视频同步信号(“垂直同步”)随着视频输出的刷新速率周期性地触发。例如，1080P60Hz的输出模式将产生的每秒60次的垂直同步。垂直同步可用于递增一个系统参考时间，其中该系统的参考时间用于混合系统中的渲染函数进行解码和渲染的定时控制。以下流程图将以此扩展作为本公开内容的一个例子。

首先，系统参考时间被初始化(标识为70)。系统参考时间可以被初始化为对第一渲染视频帧或者对视频帧开始的另一指示的响应。接着，系统等待直到一个的垂直同步被触发(标识为72)。

一旦垂直同步被触发，系统根据应用层的渲染函数确定是否要更新系统参考时间。例如，更新的系统参考时间是否超过最近的渲染函数的时间戳一个预设的门限值(标识为74)？更新后的系统参考时间可以是当前系统参考时间加上两个连续的垂直同步的参考时间之间的时间值。更新后的系统参考时间也可以称为下一个系统参考时间。预设的门限值可以是一个用于渲染一些视频帧(例如，2-3帧)的时间量。如果更新的系统参考时间不超过最近渲染函数的时间戳，该系统的参考时间可以被设置为更新后的系统参考时间(标识为76)。如果系统参考时间超过的最近渲染函数的时间戳一个预设的门限值，则系统参考时间不被更新。

接着，判断是否有视频帧需要被渲染。为了做出此决定，下一个视频帧是否在系统参考时间后过期(标识为78)？如果下一视频帧过期，那么下一个视频帧被渲染(标识为80)。如果不过期，则该方法重新开始等待步骤72并递归处理其它视频帧及其它渲染功能。在此递归过程中，系统参考时间是一个全局值，该全局变量随着每次递归而增长，这取决于设置系统参考时间的步骤76是否达到相应的递归。

图7示出用于确定何时停止渲染视频帧的时序图。对于视频帧的定时，视频帧可以视频的帧速率来被渲染。例如，假设视频的速率为每秒24帧，在每个1/24秒，一个帧应该呈现到显示器。因此，每1/24秒下一帧应被渲染。在时刻1/24秒，第一帧根据视频帧定时被渲染；在时刻2/24秒，第二帧根据视频帧定时被渲染；在时刻3/24秒，第三帧根据视频帧定时被渲染，等等。

在内核层的垂直同步可在更高的频率上运行，并为每一个被触发的垂直同步更新系统的参考时间，只要系统参考时间不超过最近渲染函数的当前时间戳一个预设的门限值。例如，所述的垂直同步可以在1/24秒的帧速率的1/5的速率(或者其它速率)上运行。对于每个1/24秒，垂直同步可被触发5次，如图中的较低的线所示。

当渲染函数接收到调用的解码的帧时，渲染函数调用具有一个时间戳。如果当前系统参考时间超过渲染函数调用的时间戳一个预设的门限值，系统参考时间不再增加，这有效地暂停或停止了视频帧的渲染。例如，假设渲染函数调用在3/24s具有时间戳100，当前系统参考时间在时间戳102附近，且用于停止渲染的预设的门限值为3帧或3/24s，接着如果及当当前系统参考时间达到大于来自最近渲染函数调用的时间戳的预设的门限值，然后在内核层渲染视频帧被暂停或停止。

虽然本公开已经参照某些实施方案进行描述，但是应当理解，本公开不限于这些实施例。相反，本公开的内容在其最广泛的意义应被理解和解释，反映在下面的权利要求。因此，下述权利要求不仅应当被理解为对本文中所描述的装置、方法以及系统的组合，而且还包括所有对本领域普通技术人员来说是显而易见的改变和修改。

Claims (15)

1.一种用于渲染视频帧的方法，通过一具有软件堆栈的计算装置进行，软件堆栈具有一应用层和一内核层，包括以下步骤：

初始化系统参考时间；

等待直到内核层触发一个中断信号；

根据来自应用层的渲染函数确定是否更新所述系统参考时间，如果下一个系统参考时间没有超过渲染函数时间戳的预设门限值，则所述系统参考时间被设定为等于下一个系统参考时间；以及

根据已确定的系统参考时间和下一视频帧，通过计算装置在内核层渲染下一视频帧；

其中初始化步骤之后的步骤被递归执行。

2.如权利要求1所述的方法，其特征在于，所述中断信号是周期性的，且其中所述下一个系统参考时间等于系统参考时间加上两个连续的中断信号之间的一段时间。

3.如权利要求1所述的方法，其特征在于，在所述确定步骤中，如果下一个系统参考时间超过渲染函数时间戳的预设门限值，则所述系统参考时间不被更新。

4.如权利要求1所述的方法，其特征在于，其中在所述渲染步骤中，如果下一个视频帧在系统参考时间之后过期，则下一视频帧被渲染。

5.如权利要求1所述的方法，其特征在于，在所述渲染步骤中，如果下一视频帧未在系统参考时间之后过期，则下一视频帧不被渲染，且递归执行等待、确定和渲染步骤。

6.如权利要求1所述的方法，其特征在于，所述计算装置包括一个运行在应用层的软件应用程序，并且其中所述软件应用程序形成渲染函数。

7.如权利要求1所述的方法，其特征在于，所述系统参考时间为一个累积值，且其中所述系统参考时间是一个全局值，被携带着进行下一个等待、确定和渲染步骤的递归。

8.一种视频帧渲染方法，通过一具有软件堆栈的计算装置进行，软件堆栈具有一应用层和一内核层，包括以下步骤：

初始化系统参考时间；

等待直到内核层中一中断信号触发；

根据来自应用层的渲染函数确定是否更新系统参考时间，其中如果下一个系统参考时间不超过渲染函数时间戳的预设门限值，则系统参考时间被设置为等于下一个系统参考时间，否则，系统参考时间不被更新；以及

根据已确定的系统参考时间和下一个视频帧，通过计算装置在内核层渲染下一个视频帧，

其中，如果下一个视频帧在系统参考时间之后过期，下一个视频帧被渲染，以及

其中，初始化之后的步骤被递归执行。

9.如权利要求8所述的方法，其特征在于，所述中断信号是周期性的，其中所述下一个系统参考时间等于系统参考时间加上两个连续的中断信号之间的一段时间。

10.如权利要求8所述的方法，其特征在于，所述渲染步骤中，如果下一视频帧未在系统参考时间之后过期，下一视频帧不被渲染，并且递归执行所述等待，确定和渲染的步骤。

11.如权利要求8所述的方法，其特征在于，所述计算装置包括一个运行在应用层的软件应用程序，其中所述软件应用程序形成渲染功能。

12.如权利要求8所述的方法，其特征在于，所述系统参考时间是一个累积值，其中系统参考时间是一个全局值，被携带着进行下一个等待、确定和渲染步骤的递归。

13.一种渲染视频帧的方法，通过一具有软件堆栈的计算装置进行，软件堆栈具有一应用层和一内核层，包括以下步骤：

初始化系统参考时间；

等待内核层的一个中断信号触发；

根据来自应用层的渲染函数确定是否更新系统参考时间，其中，如果下一个系统参考时间未超过渲染函数时间戳的预设门限值，则设置系统参考时间设置成等于下一个系统参考时间，否则，系统参考时间不被更新；以及

根据已确定的系统参考时间和下一视频帧的函数，通过计算装置在内核层中渲染下一视频帧，

其中，如果下一个视频帧在系统参考时间之后过期，则渲染下一个视频帧，否则，下一个视频帧不被渲染，

其中，计算装置包括一个运行在应用层的软件应用程序，

其中，所述软件应用程序形成渲染功能，以及

其中，初始化后的步骤递归执行。

14.如权利要求13所述的方法，其特征在于，所述中断信号是周期性的，且其中下一个系统参考时间等于系统参考时间加上两个连续的中断信号之间的一段时间。

15.如权利要求13所述的方法，其特征在于，所述系统参考时间是一个累积值，并且所述系统参考时间是一个全局值，被携带着进行下一个等待、确定和渲染步骤的递归。