CN104333808A - 用于Android及Linux智能电视机上的通用播放器 - Google Patents

Abstract

本发明公开了一种用于Android及Linux智能电视机上的通用播放器。该通用播放器分为应用接口层、数据处理层和硬件抽象层三层。应用接口层为流媒体应用提供统一的媒体调用方法，包含播放控制、参数反馈和服务质量接口。数据处理层主要由媒体插件系统来完成，包括接收、包解析、解复用、解码和输出等子模块，硬件抽象层主要包括硬件解码、音频输出和视频输出三个环节，它向上以本地接口库的形式存在于流媒体中间件中的平台硬件适配层。本发明解决了播放器的兼容性问题，同时此播放器还能提供流媒体播放功能，更好的服务流媒体业务。

Description

用于Android及Linux智能电视机上的通用播放器

技术领域

 本发明涉及一种用于Android及Linux智能电视机上的通用播放器；其以中间件模块的形式为上层应用开发者提供接口，以屏蔽底层的实现细节，同时满足流媒体的服务质量及控制需求。

背景技术

在现代社会里，除了报刊、广播等传统媒体，以及网络等新兴媒体，电视是人们获取信息的最重要的途径之一。电视的发展也是日新月异，伴随着电视媒体从模拟电视发展到数字电视。再随着数字电视的发展，智能电视也逐渐进入企业和寻常家庭之中。但目前的智能电视出于不同厂家，基于不同的电视芯片方案，采用不同的嵌入式软件，在播放器上也存在着极大的差异，对于播放多媒体视频内容的电视应用，不同的电视有着不同的播放器播放机制和接口。另外，目前的播放器的功能参差不齐，在流媒体业务等方面的普遍支持不足。 

对于互联网电视和初级智能电视，一般来说，其硬件性能一般，主频在400MHz左右为主，能实现一般的电视互联网上网功能，播放功能等等，方案采用MStar，MTK，Trident等电视解决方案，有着不同的硬件平台，一般采用Linux的操作系统。而目前推出的智能电视，硬件性能得到一定程度上的提升，主频在1GHz左右，单核甚至双核多核，基于采用Linux或者Android系统的自由扩展电视机功能的软件平台，支持更多的电视开发应用。鉴于电视的本性，主要用于体验视频业务，所以在电视硬件方面，同样都支持硬件级的视频编解码。 

目前Linux智能电视的播放器针对厂家本身特定的智能电视硬件提供私有播放接口，不同的智能电视有着不同的播放器机制和接口。

而对于Android智能电视，Android播放器逐步成为Android系统中的一个重要部分，用于播放视频业务。 Android系统是Google开发的一款基于Android内核设计的开源移动OS。Android操作系统已经成为全球最大的智能手机操作系统，平板电脑系统，以及智能电视系统。Android支持应用程序开发安装和使用，形成了一个完整生态系统。但Android本身主要用于移动互联网领域，对于智能电视的支持还有待改善，特别是视频流媒体播放器的支持，直播电视组播支持，以及针对电视的应用开发，Android本身并不支持IGMP组播，同时在MPEG-2 TS over RTP也缺乏好的支持。因此，根据这些Android播放器的缺点，结合Linux下通用播放器，对基于Android智能电视的视频流媒体业务进行开发优化，提供统一的高性能播放器，使得Android智能电视能流畅的观看点播和组播视频业务是目前需要解决的一个主要问题。

发明内容

本发明的目的在于提供一种用于Android及Linux智能电视机上的通用高性能播放器；该通用播放器能跨硬件和底层软件平台，为上层应用提供统一的播放器播放机制和接口，解决播放器的兼容性问题，同时此播放器还能提供流媒体播放功能，更好的服务流媒体业务。 其支持多标准、多解码器、运行效率高、并且可移植性好、可扩展性强，支持多种硬件平台，能够运行在不同操作系统上，能支持 H.263、H.264、MPEG-4，MP3、AAC、AMR 等音视频编码规范，使上层应用不用关注媒体播放的实现细节。

本发明的具体技术方案介绍如下。

本发明中，通用播放器作为整个流媒体业务中间件系统中的一部分，负责为上层具体的流媒体应用提供媒体播放的功能，主要包括本地文件播放，组播流式播放以及单播顺序播放三种基本方式，其宏观结构如图1所示。

通用播放器的结构自上而下可以分为三层，分别是应用接口层，数据处理层和硬件抽象层。应用接口层为流媒体应用提供统一的媒体调用方法，包含播放控制接口，参数反馈接口和服务质量接口。数据处理层主要由媒体插件系统来完成，包括接收，包解析，解复用，解码和输出等子模块，这些模块的功能可以以动态库的形式被替换或者扩展，完整的播放器实例通过依次调用对应插件的开放接口来实现对媒体数据流的控制和实时反馈，此外，针对流媒体业务特有的质量监测与控制功能以及其他额外功能也是通过额外配置插件库的方式来实现。硬件抽象层（HAL）针对不同平台的硬件相关功能进行了封装以及统一接口，主要包括硬件解码，音频输出和视频输出三个抽象组件，它向上以本地接口库的形式存在于流媒体中间件中的平台硬件适配层。另外，通用播放器还可能用到一些通用功能，比如网络包格式解析，媒体格式解析，软件解码算法，内存资源分配，线程安全操作等，这些功能以公共库的方式被提供，隶属于流媒体业务中间件架构的基础服务层部分，比如本发明对于媒体信息封包的解析与解复用过程就采用了ffmpeg中的相应库，主要包含解析音视频文件库和公共工具函数库两块。

一、通用播放器的硬件抽象层

一般来说，PC平台由于其强大的计算和并行处理能力可以选择播放器自带的软件解码算法来进行压缩数据解码，而多媒体机顶盒出于性能因素考虑需要通过专用的DSP硬件处理芯片来完成相关工作。对于音视频的输出而言，PC可以通过声卡显卡驱动来完成裸数据的播放与显示，驱动上层接口一般会适配主流的多媒体系统框架，比如windows下的Directshow，linux下的GStreamer等，而这点对于大部分嵌入式平台来说是缺失的。其中，有些厂商提供了输出设备驱动，却没有统一的接口调用，有些厂商则直接提供自己独有的音视频处理SDK（标准开发工具包）。

综上所述，对于嵌入式平台的流媒体应用开发而言，音视频的硬件解码和输出往往会与具体的平台系统相关，且这些平台向上并未提供统一的调用方式，因此，这些部分需要硬件抽象。通用播放器的硬件抽象层分为三个部分，分别是音频输出抽象组件，视频输出抽象组件和解码抽象组件。这些组件都是以动态库的方式存在于流媒体业务中间件中，具体播放器实例调用的是最上层的本地媒体接口库和解码接口库。

1、音频抽象组件

音频抽象组件对应具体嵌入式平台上的音频设备及相关操作的封装，包括音频数据流的传输与控制，对上层提供的接口功能则体现在PCM格式的声音输出以及管理设置相关参数上。如图2所示，整个音频抽象组件系统由以下几个部分构成：

（1）音频驱动程序（Audio Driver）

在操作系统核心态的设备驱动程序，虽然在各个平台实现方式各异，然而在通常情况下大部分音频驱动程序都需要提供包括音量控制，静音，通道控制等功能的控制类接口以及用于支持PCM类型数据读写的传输接口。在某些特殊嵌入式系统中，音频系统是和硬件编解码结合在一起的，即可以直接进行诸如MP3，AAC等编码音频的输出，这同样也可以归并到数据读写传输功能中。

（2）音频抽象层(Audio HAL)

对音频设备进行抽象并封装其通用接口，具体在音频硬件接口的头文件中定义，包含了音频设备类、和音频硬件接口两个类，分别用于输出和控制。音频硬件接口类是音频抽象层的控制核心，它通过开启音频设备方法获取音频设备类，将其作为音频的输出设备来使用。对于具体的音频设备类来说，设置参数方法和获取参数方法负责设置和获取当前音频的标准参数，包含音频设备的路径、采样率、格式、通道、帧数等，如果具体平台不支持则返回无效值。设置音量方法控制双声道的音量，如果是单声道以左声道为准，写方法用于往音频设备中写入PCM裸数据，其参数是一个内存的指针和长度，这块内存不可被更改。实现一个具体平台的音频抽象层需要编写代码去继承相应的类来实现这些虚函数接口，并将其代码编译生成音频动态库，供音频服务层进行连接调用。

（3）音频服务层（Audio Service）

音频服务层是音频抽象组件的中间层，提供连接音频接口层和硬件抽象层的服务，它主要由音频服务类和音频客户端类构成，音频服务类调用音频抽象层的接口来获得不同类型的音频设备对象，并进行逻辑上的整合，比如可以在初始化输出设备之前做一些预处理，调用另一个混音器设备，用以对输出之前的声音进行优化，提供多通道，声音缩放，重取样等功能。音频客户端类作为向音频服务类注册的监听器，相当于使用回调函数来获取音频运行时的实时参数信息。除此之外，一些与硬件无关的音频处理方法我们也都可以放在服务层中去实现，以增强实际音频输出的效果。

（4）音频接口层（Audio API）

音频接口层的内容在媒体库中实现，它主要包含音频系统和音频输出个接口类，其中音频系统提供了获取和设置音频设备参数的接口，音频输出则包含了对设备的状态控制和数据写操作，具体的实现通过调用服务层代码来实现，然后提供本地接口给播放器实例进行调用。

整个音频抽象组件中各对象之间统一建模语言调用关系如图3。

2、视频抽象组件

对于多媒体嵌入式设备来说，视频的渲染显示一般是通过在主显示区上叠加额外层的方法来实现。通常情况下，主显示区用于图形系统的输出（RGB颜色空间），额外的显示区则用于视频输出（YUV颜色空间），两者使用互相独立的帧缓冲（Framebuffer），然后再通过硬件混叠的方式呈现在最终屏幕上。因此对于视频输出的抽象主要通过对叠加层设备及其操作进行封装来得到，这部分包含了视频数据流传输和控制接口，对外提供的功能包括最终解码后视频帧的渲染显示以及对视频设备的控制与管理（亮度，对比度，显示位置，叠加层次等）。整个系统如图4所示，由以下几个部分构成：

（1）视频驱动程序（Video Driver）

在内核中实现，在linux操作系统下通常是基于帧缓冲或者V4L2来完成视频输出相关操作。根据系统的不同，即使使用同一种驱动程序，实现方式也可能不同。

（2）视频抽象层（Video HAL）

对画面叠加层的显示缓冲输出设备进行抽象并封装其通用接口，具体在覆盖硬件接口头文件中定义，包含覆盖硬件接口和覆盖设备两个类，分别用于管理控制显示设备以及显示内存的输出和参数设置。视频硬件接口类通过开启覆盖设备方法获取覆盖设备类，将其作为视频的叠加输出设备来使用。覆盖设备包含了多种参数设置方法，比如设置/获取位置方法用于设置叠加显示层的位置，设置/获得叠加方法用于调整叠加层的叠加层次，设置/获得区域方法用于设置画面剪切的区域，重置大小方法用于改变输入视频数据的长宽比大小，此外设置/获得参数方法还可以对其他的一些参数进行配置。根据具体平台的驱动程序实现的差异，抽象层一般提供了两种方式进行视频输出，分别是：

a)        内存映射方式。通过使用获得缓冲地址方法获得显示内存的指针，再根据

宽、高和颜色格式等参数对这块内存进行写操作以完成输出效果。

b)        内存队列方式。通过使用队列缓冲方法将需要输出的内存以队列的方式送给

设备来进行显示，去队列缓冲是一个阻塞函数，用于确定上一次压入队列的内存是否被成功接收返回。

如果要实现一个具体平台的视频抽象库则需要编写代码去继承这些类并实现对应的虚函数，而具体采用哪种方式进行显示内存读写取决于不同类型的视频输出驱动程序。

（3）视频服务层（Video Service）

视频服务层是视频抽象输出系统的中间层，提供连接视频接口层和硬件抽象层之间的服务，它包括视频服务和视频客户端两个类。其中视频服务调用视频抽象层的接口来获得叠加显示设备对象，如果流媒体应用要求且具体平台支持画中画功能，即多重叠加层，则视频服务可以通过分别初始化两个叠加显示设备对象，并设置各个对象层次和位置来实现相关逻辑。视频客户端作为监听类获得视频输出时的实时参数。

（4）视频接口层（Video API）

视频接口层具体包括视频系统和视频输出两个接口类，视频系统提供了获取和设置指定视频显示设备参数的接口，视频输出则负责实际视频裸数据的输出与状态控制，其具体实现通过调用服务层代码，然后封装成本地媒体接口以媒体动态库形式被播放器实例调用。

整个视频抽象组件中各对象之间统一建模语言调用关系如图5。

3、解码抽象组件

多媒体嵌入式设备对于音视频压缩的编解码实现方式一般各不相同，一部分厂商会支持Openmax的编解码集成层标准，也有的厂商会采用自己独立的优化硬件解码系统。针对这些差异性，解码抽象主要对解码过程中的相关操作进行了封装，除了包含数据解码功能以外，它还需要提供对解码器的管理与控制，包括获得当前解码器的类型，状态与实时统计信息等。如图6所示，整个解码抽象组件系统分为三个层次：

（1）硬件解码驱动（Codec Driver）

对应具体硬件平台的解码DSP芯片驱动或者是更上层的解码编程库，其通用的操作包括指定格式数据解码，解码状态和统计信息获取。

（2）解码抽象层（Codec HAL）

解码抽象层的接口在解码硬件接口头文件中定义，包含了解码设备和解码硬件接口两个类，分别用于解码和设备控制。解码硬件接口调用开启解码器函数获取解码器类。该类用于抽象具体的解码设备，其中设置参数函数用以设置用于解码的编码类型，解码函数对应于具体数据的解码和输出，获得解码状态函数用于获得实时的解码统计信息，包括视频码流宽度和高度、解码帧率和码率、接收帧数、丢失帧数、平均码率等。此外设置/获得参数方法还可以对其他的一些参数进行配置。

（3）解码服务层（Decode Service）

解码服务层主要是对实际系统支持的硬件解码进行判别与分类，对于不支持硬件解码的类型，需要调用公共库中的软件解码算法来完成相应功能。

（4）解码接口层（Decode API）

向上提供本地接口供通用播放器实例进行调用。

二、通用播放器的数据处理层

任何的多媒体播放器对于数据的处理流程都要至少经过接收、解复用、解码和输出四个步骤，本发明将这些相对独立的过程封装成插件形式的模块，模块之间通过统一的数据注入接口来实现通信，模块与模块之间则通过事件消息来实现控制。如果要对播放器增加额外功能，比如对字幕的支持、对网络数据的预处理等，也只需要在某两个模块中加入一个自定义的插件即可。插件本身只是对数据进行修改和过滤，并不改变整个播放流程的处理逻辑，这样可以有效减小播放器功能扩展带来的工作量。针对以上目标，本发明在综合参考多种主流多媒体框架后，设计并实现了一套简单的媒体插件系统及对应的事件驱动模型方法。

1、插件系统

插件系统有两个部分构成，分别是插件管理器（PluginManager）和插件库（so），主程序使用插件管理器（PluginManager）加载这些插件库，插件管理器通过导出函数将各个类ID、对象创建函数地址统一管理起来，从而在插件管理器的中介作用下让各个插件能相互使用各种接口函数。

2、媒体插件设计

根据流媒体实际需求，我们将通用播放器需要用的功能插件分为6类，分别是接收插件、分离 插件、解码插件、输出插件、增强插件和控制插件，具体描述如下。

（1）接收插件

接收插件采用统一的接口来屏蔽不同的原始数据入口，它通过统一资源定位器来区分不同的输入源，提供了以下几类方法。开启方法负责根据不同的统一资源定位器类型初始化相应的数据读取功能，打开文件，设备或者网络套接字，此外，如果是RTSP点播请求，还需要处理与服务器之间的协议交互。读方法作为读操作接口，完成文件读取或者网络数据接收。搜索方法是搜索定位接口，文件接收类型就将读指针定位到指定位置，点播接收类型需要发送相应的控制命令，直播则不需要实现该接口。告知方法用于返回当前已经读取到的数据总量。

（2）分离插件

分离插件负责识别原始流的格式，解析原始流中的数据类型，分辨视频、音频编码类型，最后过滤出原始流包含的各路媒体数据，分别传输给解码插件进行处理。读取探测方法用于探测原始数据流的类型，读取头方法确定格式并选定解码器，读取帧方法读取一帧数据，在内部完成封装，最后以帧的形式输出。

（3）解码插件

解码插件也为系统提供了统一的接口，主要完成对各种不同媒体传输流的解码。由滤波器传过来的传输流可能有视频流、音频流和其他数据流。对于不同类型的传输流，根据它们各自的类型编号，送入不同的解码插件进行解码。

（4）输出插件

输出插件为通用播放器实例提供了统一的输出接口。该插件实际调用硬件抽象层的本地接口，将经过同步处理后的音视频帧输出到对应设备上去。其中，开启函数用于打开指定类型的输出设备，设置/获得函数用于设置和获得设备状态和参数，写函数用于向输出设备上写数据。需要注意的是，对于视频数据，输出插件有可能需要进行颜色空间转换之后再进行输出。而字幕之类的数据，输出可能是读取字库后与视频数据混合之后再一起输出，或是直接输出到覆盖设备。

（5）增强插件

增强插件为系统提供增强功能，它可以是对解码插件输入到该模块的信号进行数字处理，如 3D效果增强、均衡、消除噪声等，使输出更逼真、生动，更令人满意，也可以是对不同输出设备的颜色空间转换，延时时间转换等。需要注意的是，和其他类型的插件不同，系统中可能同时会有多个增强插件在工作。开发者通过选择使用的 增强插件及其顺序。增强插件有多种类型，系统将从解码 插件得到的数据顺序送入同一数据类型的各个增强插件处理。增强插件对数据的处理不改变其长度、类型、时间戳，仅对数据本身进行操作，增强其特性。

（6）控制插件

控制插件与其他插件进行交互已达到控制播放的功能。

3、事件消息驱动

播放器的数据处理任务需要播放器调用相关事件接口来触发，这就需要建立一个完整的事件驱动模型，如图7所示，图中反应器类是监听者，它利用操作系统提供的多路分离函数来实现循环等待，当事件接口被调用时，它会生成对应事件对象并将其加入到异步调度器类的阻塞队列中缓存。调度器在初始化时通过注册处理器函数将事件处理器对象注册到事件驱动列表中，另一方面，它通过派发方法来实行事件分配调度，以保证对于某一类型的事件，会调用适当事件处理器类的响应函数处理事件来进行处理。这个模型的优点是将事件本身与处理函数解耦，同时可以对实时事件进行存储转发，以消除事件处理过程对播放系统带来的性能影响。

三、通用播放器的应用接口层

应用接口层为流媒体应用提供统一的媒体调用方法，包含播放控制，参数反馈和服务质量接口。本产品将通用播放器为应用程序提供的接口进行整理和提取，分为播放器的获得和销毁、播放器的打开和关闭、播放控制、状态控制和参数获取这五大类API，如表1所示。播放器的获得和销毁这类接口用一个播放器池来实现对播放器的统一管理，提供了对某种类型播放器的获得与销毁。播放器的打开和关闭这类接口为应用开发者提供了对获得的播放器的打开和关闭操作，没有播放任务的播放器可以关闭但是不销毁，这样可以节省重新获得播放任务的开销，并节约系统资源。播放控制这类接口为应用开发者提供了视频播放基础的播放控制功能，并提供了扩展接口以应对额外的播放控制请求。状态控制这类接口为应用开发者提供了获取当前播放状态的接口。参数获取这类接口为应用开发者提供了获取当前播放视频各类参数的接口，并提供了扩展接口以应对额外的参数获取请求。

表1 通用播放器API列表

 

本发明的流媒体中间件中通用播放器具有以下性能

(1) 接口透明性：上层应用不需要关注播放功能接口具体的实现细节，系统为不同平台的音视频应用提供统一并可扩展的调用接口 

(2) 结构模块化：利用插件机制使系统模块化，跨平台移植时可以指出哪些模块需要被移植，哪些模块可以复用，模块各司其职，利用内部数据接口通信，保证模块之间的低耦合。 

(3) 可移植性：能够在目前常见的操作系统和硬件平台上运行，软件平台如 Windows，Linux，嵌入式Linux等，硬件包括X86 PC, MIPS/ARM指令集平台。 

(4) 可实现性：由于嵌入式的硬件限制，框架的复杂度必须受到控制。 

(5) 非对称性：针对多媒体播放系统特点，我们应该将重点放在音视频媒体接收播放方面，而不必要将过多的精力投入到过于复杂的某个插件系统上。 

(6) 可扩展性：能够很容易增加模块来实现新的功能和增值应用，如前向纠错编码差错控制、视频同步和无缝切换等。 

(7) 高效性：对一些计算量比较大的应用，能够保证流畅，需要同时支持本地播放和流式播放。 

本发明的有益效果在于：

（1）此通用播放器能跨硬件和底层软件平台，为上层应用提供统一的播放机制和接口，解决了兼容性问题，同时此播放器还能够提供流媒体播放质量控制和质量参数反馈功能，为上层应该提供更好的流媒体业务应用接口。

（2）本发明在功能上，结合先进电信网络的特点和业务特性，本播放器产品除了实现通用的播放器功能如播放不同格式的视频文件，支持视频流媒体点播和组播外，同时也增加了对服务质量和前向纠错的支持，更好的满足电视用户，增加了用户服务体验。在外部接口实现上，本通用播放器产品实现了统一的外部接口供上层应用调用，使得上层应用可以不关心底层的实现以及底层不容的硬件特性。

附图说明

图1 通用播放器宏观架构图。

图2 音频抽象组件结构图。

图3 音频抽象组件各对象依赖关系。

图4 视频输出系统结构图。

图5 视频抽象组件各对象依赖关系。

图6 解码系统结构图。

图7 事件驱动模型UML关系图。

图8 MStar平台底层硬件抽象实现。

图9 SMP8654平台底层硬件抽象实现。

图10通用播放器上层数据流程图。

图11通用播放器系统资源占用情况。

具体实施方式

本发明采用硬件抽象的方式进行了跨平台的移植，我们将播放器实例部署在两个不同的嵌入式设备上，分别是SMP8653和MStar988，其中SMP系列是媒体平台厂商Sigma Designs公司发布的高性能机顶盒，而MStar988平台则是专门面向智能电视的海尔模卡电视平台，这两种平台在不同硬件终端上比较具有代表性。表2给出了两个平台的硬件配置信息。

表2 SMP8653和MStar 988平台的硬件配置

一、MStar模卡电视平台抽象层实现

由于MStar模卡电视平台是基于Linux操作系统并直接提供了针对音频和视频的设备驱动，因此该平台上的抽象接口的实现可以通过在用户空间调用驱动操作来完成，如图8所示，音频PCM数据流的读操作通过对/dev/dsp设备的操作来完成，视频抽象层移植通过调用mmap来获得当前帧缓冲的指针，然后向其中写入解码后经过同步的视频帧缓存。此外，对设备的控制则通过设备控制接口标准函数来设置。需要注意的是，显示输出设备/dev/fbX必须不能与UI层使用的设备重复或者冲突，两者必须支持互相叠加的显示输出。对于解码抽象的实现，本发明则直接通过在抽象层实现调用MStar提供的符合Openmax IL编解码集成层的标准库来完成硬件DSP设备的解码工作，它支持包括MPEG，AC3，DTS，AAC等音频格式和MPEG1, MPEG2, MPEG4, H.264 和RM等视频格式。

二、Sigma机顶盒平台抽象层实现

Sigma机顶盒平台对其内部设备和操作进行了一定程度的封装和保护，用户空间的开发者难以直接通过驱动访问。与此同时，厂商提供了一套自己的开发框架，其平台抽象层实现如图9所示。其中，最下面的一层是相关硬件，如CPU、视频解码器、音频解码器、并行I／O接口。中间的硬件抽象层用户程序接口MRUA(Em86xx REALmagic User API)提供了访问这些硬件的抽象接口，另外解码链控制(DCC，Decoding Chain Control)是通过访问硬件抽象层的用户程序接口实现对视频播放控制、音频解码输出等功能的操作。

针对Sigma机顶盒平台的抽象层移植需要使用硬件抽象层用户程序接口的库函数，以对设备进行操作与控制，一个完整的通过硬件抽象层用户程序接口进行图像显示的流程包括如下：

1）创建硬件抽象层用户程序接口实例；

2）初始化显示设备的渲染参数选项

3）装载硬件单元微码

4）初始化图形效果(GFX)引擎

5）设置图形效果对象的通道属性

6）投递绘制画面请求

7）关闭图形效果引擎和硬件抽象层用户程序接口实例对象

实际移植过程中我们需要将这些调用过程进行解耦并分别封装在视频抽象组件的对应接口中。音频和解码抽象层的移植也与其类似。

三、通用播放器的上层实现

通用播放器的实例通过调用并组合各个媒体插件，并对其进行数据与状态同步来完成，上层的具体实施如图10所示。播放器首先根据初始启动参数在主线程中调用接收模块接口以获得视频源（确定媒体文件位置，加入组播地址，RTSP请求成功并获得返回），继而读取原始媒体数据（读文件或者接收网络流），在获得第一批原始流之后调用格式插件探测其格式，然后调用对应的混合器（demuxer）分离出每股媒体信息流（一般包括视频，音频，也可能包含多音轨或者多字幕）。对于每一股信息流，为了保证解码与播放的同步和实时性，需要分别开启两个线程，以保证播放的同时也进行解码工作。此外，还需要为两个线程开辟一块公有缓存，它可以是一个循环数组。解码线程和输出线程对于该缓存的使用相当于经典的生产者-消费者模型。在实际运行中，播放指针不能超过解码指针（即解码要先于播放，否则输出线程读取的数据会无效），同时解码指针也不能移动过快超过整个循环（否则解码后的新数据会覆盖尚未播放的缓存）。针对该问题，本文采用对每段缓存设置标志位的方式来完成控制。解码线程在调度周期内检测到其指针对应的缓存标志位处于空闲状态时则进行解码，将解码后数据写入缓存后将标志位置为已解码，如果是其他状态则不进行解码。播放线程如果检测到该段缓存处于已解码状态，则调用输出函数进行播放，播放结束返回后重置标志位为空闲，否则就不进行输出。因此，通过上述的缓存标志位控制可以有效的实现解码与播放的读写同步。除此之外，对于音视频的同步则是通过其帧内的显示时间戳(PTS)来完成，考虑到人体对于音频的敏感程度更高，输出的时间轴以音频显示时间戳作为基准，其PCM数据直接输入音频设备，与此同时，再根据视频的显示时间戳和当前运行时钟进行视频输出时间的调整，以保证最终的音视频同步效果。

四、测试结果

测试中分别采取了直播和点播两种播放方式来完成播放器功能、性能以及播放效果方面的实施和测试，其各自片源信息如表3。

表3 组播和点播测试片源信息

（1）功能测试

播放功能测试主要包括对播放器提供的快进快退，跳转，静音，画面调整，音量调节，暂停/恢复等功能进行测试。

测试过程：分别对卫星电视直播节目和录播点播视频进行播放，过程中随机执行上述各类操作，观察预期功能完成情况和对正常播放的影响

测试结果和分析：经过反复测试，除了操作过快会导致一些命令无法响应外，测试结果达到期望结果。此外，某些状态下无效的操作也会被播放器忽略（比如直播过程中的快进快退请求），不会影响到音视频的正常显示输出。

（2）系统资源消耗测试

系统资源消耗测试的目的是为了比较本文实现的嵌入式播放器与MStar平台自带的播放器在内存和CPU占用方面的表现，以评估两者的性能差距。我们在对同款设备同一视频进行点播请求的情况下，采样统计两个播放器进程各自的CPU和内存使用百分比，得到其平均系统资源占用情况如图11。我们可以看到，本文实现的嵌入式播放器相比MStar内部的Zmplayer而言资源占用更多，尤其是内存资源，CPU的提升是因为播放器在运行时需要加载插件框架，而内存是因为数据处理过程中用到的缓存没有经过硬件优化导致。

说明书附录：术语与缩略词列表

Claims (4)

1.一种用于Android及Linux智能电视机上的通用播放器，其特征在于：其结构自上而下分为三层，分别是应用接口层，数据处理层和硬件抽象层；其中：

应用接口层用于为流媒体应用提供统一的媒体调用方法，其包含播放控制接口，参数反馈接口和服务质量接口；

数据处理层主要由媒体插件系统来完成，包括接收，包解析，解复用，解码和输出子模块，这些子模块的功能以动态库的形式被替换或者扩展，完整的播放器通过依次调用对应插件的开放接口来实现对媒体数据流的控制和实时反馈；

硬件抽象层针对不同平台的硬件相关功能进行封装以及统一接口，主要包括硬件解码，音频输出和视频输出三个抽象组件，它向上以本地接口库的形式存在于流媒体中间件中的平台硬件适配层。

2.根据权利要求1所述的通用播放器，其特征在于：所述硬件抽象层分为音频输出抽象组件，视频输出抽象组件和解码抽象组件三部分；其中：所述音频输出抽象组件由音频驱动程序、音频抽象层、音频服务层和音频接口层构成；所述视频输出抽象组件由视频驱动程序、视频抽象层、视频服务层和视频接口层构成；所述的解码抽象组件由解码驱动程序、解码抽象层、解码服务层和解码接口层构成。

3.根据权利要求1所述的通用播放器，其特征在于：所述数据处理层中的媒体插件系统由插件管理器和插件库组成，插件管理器通过导出函数将各个类ID、对象创建函数地址统一管理起来，从而在插件管理器的中介作用下让各个插件能相互使用各种接口函数；其中，所述插件库中的插件分为六种插件：接收插件，分离插件，解码插件，输出插件，增强插件和控制插件。

4.根据权利要求1所述的通用播放器，其特征在于：增加播放器额外功能，通过采用插件封装模块的形式实现，模块之间通过统一的数据注入接口来实现通信，模块与模块之间则通过事件消息来实现控制。