硬件解码实现方法、装置及播放器的制造方法
【专利摘要】本发明涉及一种硬件解码实现方法、装置及播放器，该方法包括：对识别出的预定格式的视频文件进行解析，从中获取音频和/或视频数据流；将音频和/或视频数据流打包成OpenMAX应用层支持的视频容器格式；调用OpenMAX?应用层接口播放打包后的音频和/或视频数据流。本发明基于Adnroid系统OpenMAX?AL协议接口实现了FLV等系统不支持的容器格式也能实现硬件解码，从而降低了系统视频播放功耗和CPU占用率，提高了视频播放的清晰度和流畅性，满足了用户视频播放需要。
【专利说明】硬件解码实现方法、装置及播放器
【技术领域】
[0001]本发明涉及播放器【技术领域】，尤其涉及一种基于OpenMAX应用层接口的硬件解码实现方法、装置及播放器。
【背景技术】
[0002]OpenMAX是一个多媒体应用程序的标准，其可以加速跨OS和silicon平台的多媒体组建的开发、整合和编程，使library和codec实现者能够快速有效的利用新silicon潜在的加速功能，而不关心下层的硬件结构。
[0003]OpenMAX 自上而下分为 OpenMAX AL (Application Layer,应用层)、OpenMAX IL(Integrateion Layer,集成层)和 OpenMAX DL (Development Layer,开发层)三个层次，其中:
[0004]OpenMAX AL提供应用和多媒体中间层的标准接口，使得应用在多媒体接口上具有了可移植性；
[0005]OpenMAX IL作为在嵌入式和移动设备中使用的audio、video、images codecs的底层接口，使得AP和多媒体框架可以以统一的方式访问多媒体codec和支持组件。其中，Codec可以是硬件和软件的任意组合,对用户透明。
[0006]OpenMAX DL定义了一套API,包含了 audio、video和imaging使用的函数集合,这些函数可以由芯片厂商针对新的处理器进行实现和优化，然后被codec厂商在各种codec上使用。
[0007]OpenMAX AL API提供了应用层的跨平台可移植的多媒体解决方案，将系统的媒体播放和记录功能进行抽象，通过API将这个抽象组织成一系列的object。
[0008]然而，目前网络视频大多采用FLV (flash video,快速视频)视频(大部分视频采用FLV容器格式，H.264视频编码格式)，虽然多数Android系统终端都能支持H.264视频编码格式的硬解播放，但由于google开源出来的默认android系统不支持FLV等视频容器格式，从而造成android系统终端播放器无法支持FLV格式硬解播放，而只能采用软解播放，由此导致系统视频播放功耗过大，CPU占用率过高，特别是高清或超清视频流的播放流畅性较差，而且不同终端厂家的软件性能表现也不一样，无法达到统一的视频播放效果。
【发明内容】
[0009]本发明的主要目的在于提供一种硬件解码实现方法、装置及播放器，旨在降低系统视频播放功耗和CPU占用率，提高视频播放的清晰度和流畅性。
[0010]为了达到上述目的，本发明提出一种硬件解码实现方法，包括:
[0011]对识别出的预定格式的视频文件进行解析，从中获取音频和/或视频数据流；
[0012]将所述音频和/或视频数据流打包成OpenMAX应用层支持的视频容器格式；
[0013]播放所述打包后的音频和/或视频数据流。
[0014]本发明还提出一种硬件解码实现装置，包括:[0015]解析模块，用于对识别出的预定格式的视频文件进行解析，从中获取音频和/或视频数据流；
[0016]打包模块，用于将所述音频和/或视频数据流打包成OpenMAX应用层支持的视频容器格式；
[0017]播放模块，用于播放所述打包后的音频和/或视频数据流。
[0018]本发明还提出一种播放器，包括如上所述的硬件解码实现装置以及OpenMAX应用
层接口。
[0019]本发明提出的一种硬件解码实现方法、装置及播放器，通过对识别出系统无法直接播放的FLV容器格式等预定格式的视频文件进行解析，从中获取音频和/或视频数据流，打包成TS容器格式等OpenMAX AL支持的视频容器格式；并通过调用OpenMAX AL接口播放打包后的音频和/或视频数据流，由此，基于Adnroid系统OpenMAX AL协议接口实现了FLV等系统不支持的容器格式也能实现硬件解码，从而降低了系统视频播放功耗和CPU占用率，提高了视频播放的清晰度和流畅性，满足了用户视频播放需要。
【专利附图】
【附图说明】
[0020]图1是本发明硬件解码实现方法第一实施例的流程示意图；
[0021]图2是本发明实施例OpenMAX AL适配层的基本原理框架示意图；
[0022]图3是本发明硬件 解码实现方法第二实施例的流程示意图；
[0023]图4是本发明硬件解码实现装置第一实施例的结构示意图；
[0024]图5是本发明硬件解码实现装置第二实施例的结构示意图。
[0025]为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。
【具体实施方式】
[0026]本发明实施例的解决方案主要是:对识别出的系统无法直接播放的FLV容器格式等预定格式的视频文件进行解析，获取音频和/或视频数据流，打包成TS容器格式等OpenMAX AL支持的视频容器格式；并通过调用OpenMAX AL接口播放打包后的音频和/或视频数据流，以使FLV等系统不支持的容器格式也能实现硬件解码，降低系统视频播放功耗和CPU占用率，提高视频播放的清晰度和流畅性。
[0027]本发明实施例所涉及的专业术语包括:
[0028]HW Decoder:Hardware Decoder,硬件解码器；
[0029]OMX =OpenMAX的缩写，是NVIDIA和Khronos在2006年制定的多媒体处理框架规范；
[0030]OMX AL:OpenMAX Application Layer 的缩写，OpenMAX 应用层；
[0031]FLV:flash video的缩写,是一种视频格式的定义；
[0032]视频容器格式:定义了存储数据的格式，而不涉及存储数据的类型。比较流行的有:
[0033]mpeg4:文件扩展名为.mp4或者.m4v ；
[0034]flash video: 一般使用.fIv 扩展名，用于 adobe flash ；
[0035]Avi:audio video interleave,一般使用.avi 扩展名。[0036]视频编码格式:视频数据的压缩方式，主流的格式有:
[0037]MPEG:即运动图像专家格式，有三种压缩标准:MPEG-l、MPEG-2、MPEG-4 ；
[0038]H.264:由国际电信联盟ITU-T所制定的新一代视频压缩格式，具有更高的数据压缩比，在同等的图像质量，H.264压缩比能比MPEG-2高2~3倍，因此网络在线视频大多采用H.264视频编码格式。
[0039]如图1所示，本发明第一实施例提出的一种硬件解码实现方法，包括:
[0040]步骤S102，对识别出的预定格式的视频文件进行解析，从中获取音频和/或视频数据流；
[0041]本实施例方案适用于Android系统终端的视频播放器，同时也适用于其他需要支持视频播放的操作系统终端的视频播放器，在此以Android系统终端的视频播放器举例说明。
[0042]为了解决android系统本身不支持FLV等容器格式的视频而造成只能使用软件解码的问题，本实施例提出一种基于android OpenMAX AL接口实现因系统本身不支持的视频容器而实现硬件解码。例如网络在线视频大多采用的FLV视频，通过本实施例方案则可以解决播放视频功耗过大、大分辨率视频不流畅等问题，大大提高用户播放的体验。
[0043]具体地，在本实施例中，首先针对播放器待播放的视频文件，对预先识别出的android系统无法支持的FLV等容器格式的视频文件进行解析，解析出音、视频数据流。
[0044]步骤S103，将所述音频和/或视频数据流打包成OpenMAX应用层支持的视频容器格式；
[0045]步骤S104，播放所述打包后的音频和/或视频数据流。
[0046]将解析出的音、视频数据流打包成OpenMAX AL (OpenMAX应用层)支持的TS容器格式等数据流，其中，TS (Transport Stream,流媒体)全称为MPEG2-TS,即分包发送,每一个包长为188字节。包的结构为，包头为4个字节，负载为184个字节。在TS流里可以填入很多类型的数据，如视频、音频、自定义信息等。MPEG2-TS主要应用于实时传送的节目，t匕如实时广播的电视节目。MPEG2-TS格式的特点就是要求从视频流的任一片段开始都是可以独立解码的。
[0047]之后将打包后的音频、视频数据流通过OpenMAX AL适配层发送给OpenMAX AL接口，之后调用所述OpenMAX AL接口即可播放打包后的音频、视频数据流。
[0048]其中:0penMAX AL适配层是播放器调用OpenMAX AL接口实现音视频播放用例的实现体。
[0049]本实施例OpenMAX AL适配层的基本原理框架如图2所示,其中:
[0050]TS打包(TS Packet)表示将从播放器待播放的视频文件中解析出来的音频流和视频流打包成TS流格式的数据，并发送给OpenMAX AL适配层的数据缓存(Buffer Cache),来自数据缓存的数据流发送至播放对象(MediaPlayer)。
[0051]播放对象(MediaPlayer)提供了一系列接口(XAPlayltf、XAAndroidBufferQueueItf、XASeekItf 以及 XAVolumeItf 等等)，实现对音视频播放的数据源、声音、seek、暂停、播放等控制。
[0052]其中,XAPlayItf用于对mediaplayer的状态进行控制,例如对暂停、播放、当前播放状态、当前已播放的时间等进行控制；[0053]XAAndroidBufferQueueItf用于对MediaPlayer和外部进行数据流控制，例如对播放所需要的数据源进行控制；
[0054]XASeekItf为一接口，通过该接口可以实现视频播放拖动；
[0055]XAVolumeItf为另一接口，通过该接口可以实现静音、音量调整。
[0056]除了以上接口外,还有很多接口来控制mediaplayer,在此不--说明。
[0057]播放器通过对OpenMAX AL适配层中mediaplayer object提供的这些接口，结合引擎对象(Engine)，可以实现对播放器的控制以及获取当前播放的信息，实现视频文件的播放。
[0058]以FLV视频(容器格式FLV，，video为H.264格式，audio为AAC格式)为例，通过上述实施方式，识别出该FLV格式视频后，从FLV视频文件中解析出H.264格式的视频流和AAC格式的音频流，再通过“TS Packet”把音频流和视频流打包成TS流，通过OpenMAX AL适配层和OpenMAX AL接口，实现硬解码的播放。
[0059]除了 FLV视频外，其他视频容器格式(特别是系统不支持的容器格式)通过本实施例方法实现的播放器也可以播放，且只要是硬解支持的视频编码格式都可以实现硬解，由此大大扩展了硬件解码的视频格式，并降低了系统视频播放功耗和CPU占用率，提高了视频播放的清晰度和流畅性，满足了用 户视频播放需要。
[0060]如图3所示，本发明第二实施例提出的一种硬件解码实现方法，在上述第一实施例的基础上，在上述步骤S102之前还包括:
[0061 ] 步骤SlOl，识别待播放视频文件的格式。
[0062]本实施例与上述第一实施例的区别在于，本实施例还包括识别待播放视频文件的格式的方案。
[0063]具体地，在本实施例中，首先对播放器待播放的视频文件进行格式识别，识别出android系统无法支持的FLV等容器格式的视频文件，以便对该容器格式的视频文件进行解析，打包成TS容器格式等OpenMAX AL支持的视频容器格式。其他与第一实施例相同。
[0064]如图4所示，本发明第一实施例提出一种硬件解码实现装置，包括:解析模块202、打包模块203以及播放模块204，其中:
[0065]解析模块202，用于对识别出的预定格式的视频文件进行解析，从中获取音频和/或视频数据流；
[0066]打包模块203，用于将所述音频和/或视频数据流打包成OpenMAX AL支持的视频容器格式；
[0067]播放模块204，用于播放所述打包后的音频和/或视频数据流。
[0068]本实施例方案适用于Android系统终端的视频播放器，同时也适用于其他需要支持视频播放的操作系统终端的视频播放器，在此以Android系统终端的视频播放器举例说明。
[0069]为了解决android系统本身不支持FLV等容器格式的视频而造成只能使用软件解码的问题，本实施例提出一种基于android OpenMAX AL接口实现因系统本身不支持的视频容器而实现硬件解码。例如网络在线视频大多采用的FLV视频，通过本实施例方案则可以解决播放视频功耗过大、大分辨率视频不流畅等问题，大大提高用户播放的体验。
[0070]具体地，在本实施例中，首先通过识别模块201对播放器待播放的视频文件进行格式识别，识别出android系统无法支持的FLV等容器格式的视频文件，然后，通过解析模块202对该容器格式的视频文件进行解析，解析出音、视频数据流。
[0071]之后由打包模块203将解析出的音、视频数据流打包成OpenMAX AL支持的TS容器格式等数据流，比如MPEG2 TS容器格式，并将打包后的音频、视频数据流通过OpenMAX AL适配层发送给OpenMAX AL接口，之后播放模块204调用所述OpenMAX AL接口即可播放打包后的音频、视频数据流。
[0072]其中:0penMAX AL适配层是播放器调用OpenMAX AL接口实现音视频播放用例的实现体。
[0073]本实施例OpenMAX AL适配层的基本原理框架如图2所示,其中:
[0074]打包TS (TS Packet)表示将从播放器待播放的视频文件中解析出来的音频流和视频流打包成TS流格式的数据，并发送给OpenMAX AL适配层的数据缓存(Buffer Cache),来自数据缓存的数据流发送至播放对象(MediaPlayer )。
[0075]播放对象(MediaPlayer)提供了一系列接口(XAPlayltf、XAAndroidBufferQueueItf、XASeekItf 以及 XAVolumeItf 等等)，实现对音视频播放的数据源、声音、seek、暂停、播放等控制。
[0076]其中,XAPlayltf用于对mediaplayer的状态进行控制,例如对暂停、播放、当前播放状态、当前已播放的时间等进行控制；
[0077]XAAndroidBufferQueueItf用于对MediaPlayer和外部进行数据流控制，例如对播放所需要的数据源进行 控制；
[0078]XASeekItf为一接口，通过该接口可以实现视频播放拖动；
[0079]XAVolumeItf为另一接口，通过该接口可以实现静音、音量调整。
[0080]除了以上接口外,还有很多接口来控制mediaplayer,在此不--说明。
[0081]播放器通过对OpenMAX AL适配层中mediaplayer object提供的这些接口，结合引擎对象(Engine)，可以实现对播放器的控制以及获取当前播放的信息，实现视频文件的播放。
[0082]以FLV视频(容器格式FLV，，video为H.264格式，audio为AAC格式)为例，通过上述实施方式，识别出该FLV格式视频后，从FLV视频文件中解析出H.264格式的视频流和AAC格式的音频流，再通过“TS Packet”把音频流和视频流打包成TS流，通过OpenMAX AL适配层和OpenMAX AL接口，实现硬解码的播放。
[0083]除了 FLV视频外，其他视频容器格式(特别是系统不支持的容器格式)通过本实施例方法实现的播放器也可以播放，且只要是硬解支持的视频编码格式都可以实现硬解，由此大大扩展了硬件解码的视频格式，并降低了系统视频播放功耗和CPU占用率，提高了视频播放的清晰度和流畅性，满足了用户视频播放需要。
[0084]如图5所示，本发明第二实施例提出一种硬件解码实现装置，在上述第一实施例的基础上还包括:
[0085]识别模块201，用于识别待播放视频文件的格式。
[0086]本实施例与上述第一实施例的区别在于，本实施例还包括识别待播放视频文件的格式的方案。
[0087]具体地，在本实施例中，首先对播放器待播放的视频文件进行格式识别，识别出android系统无法支持的FLV等容器格式的视频文件，以便对该容器格式的视频文件进行解析，打包成TS容器格式等OpenMAX AL支持的视频容器格式。其他与第一实施例相同。
[0088]此外，本发明实施例还提出一种播放器，该播放器包括上述实施例所述的硬件解码实现装置以及OpenMAX AL接口，其中硬件解码实现装置的功能特点请参照上述实施例，在此不再赘述。 [0089]本发明实施例硬件解码实现方法、装置及播放器，通过识别待播放视频文件的格式；对识别出系统无法直接播放的FLV容器格式等预定格式的视频文件进行解析，从中获取音频和/或视频数据流，打包成TS容器格式等OpenMAX AL支持的视频容器格式；并通过调用OpenMAX AL接口播放打包后的音频和/或视频数据流，由此，基于Adnroid系统OpenMAX AL协议接口实现了 FLV等系统不支持的容器格式也能实现硬件解码，从而降低了系统视频播放功耗和CPU占用率，提高了视频播放的清晰度和流畅性，满足了用户视频播放需要。
[0090]以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的【技术领域】，均同理包括在本发明的专利保护范围内。
【权利要求】
1.一种硬件解码实现方法，其特征在于，包括: 对识别出的预定格式的视频文件进行解析，从中获取音频和/或视频数据流； 将所述音频和/或视频数据流打包成OpenMAX应用层支持的视频容器格式； 播放所述打包后的音频和/或视频数据流。
2.根据权利要求1所述的方法，其特征在于，所述将音频和/或视频数据流打包成OpenMAX应用层支持的视频容器格式的步骤包括: 将所述音频和/或视频数据流打包成流媒体容器格式。
3.根据权利要求2所述的方法，其特征在于，所述播放打包后的音频和/或视频数据流的步骤包括: 将所述打包后的音频和/或视频数据流通过OpenMAX应用层的适配层发送给OpenMAX应用层接口； 调用所述OpenMAX应用层接口播放所述打包后的音频和/或视频数据流。
4.根据权利要求1、2或3所述的方法，其特征在于，所述对识别出的预定格式的视频文件进行解析的步骤之前还包括: 识别待播放视频文件的格式。
5.根据权利要求1、2或3所述的方法，其特征在于，所述预定格式的视频文件至少包括快速视频容器格式的视频文件。
6.一种硬件解码实现装置，其特征在于，包括: 解析模块，用于对识别出的预定格式的视频文件进行解析，从中获取音频和/或视频数据流； 打包模块，用于将所述音频和/或视频数据流打包成OpenMAX应用层支持的视频容器格式； 播放模块，用于播放所述打包后的音频和/或视频数据流。
7.根据权利要求6所述的装置，其特征在于，所述打包模块还用于将所述音频和/或视频数据流打包成流媒体容器格式。
8.根据权利要求6所述的装置，其特征在于，所述播放模块还用于将所述打包后的音频和/或视频数据流通过OpenMAX应用层的适配层发送给OpenMAX应用层接口 ；调用所述OpenMAX应用层接口播放所述打包后的音频和/或视频数据流。
9.根据权利要求6、7或8所述的装置，其特征在于，还包括: 识别模块，用于识别待播放视频文件的格式。
10.一种播放器，其特征在于，包括权利要求6-9中任一项所述的硬件解码实现装置以及OpenMAX应用层接口。
【文档编号】H04N21/63GK104023260SQ201310066574
【公开日】2014年9月3日 申请日期:2013年2月28日 优先权日:2013年2月28日
【发明者】周贵彪 申请人:腾讯科技（深圳）有限公司