一种多媒体引擎的实现方法

文档序号:7924731阅读:198来源:国知局
专利名称:一种多媒体引擎的实现方法
技术领域
本发明涉及多媒体技术领域,尤其涉及一种多^^体引擎的实现方法。
技术背景近年来,多媒体技术发展迅速,并广泛地应用到生产生活的各个领域中, 如,通讯、电脑游戏、教育、档案管理、图书、娱乐、艺术、股票债券、金 融交易和建筑设计等。同时,随着移动终端日益成为人们日常生活中不可缺 少的一种工具,多媒体技术在移动终端上的应用也得到了进一步的发展。目前,移动终端上的多媒体解码器普遍采用硬件解码器,人们通常认为 硬解码方式的解码效果优于软解码方式,该结论主要是根据两种解码方案音 质的区别得出的,但音质的好坏并不仅仅取决于解码方式,影响音质的主要 因素是移动终端的硬件性能。目前如手机等移动终端正逐渐向智能型发展,智能手机最大的特点就是与PC (个人电脑)有着相似的架构和工作原理。显然,在PC上播》文MP3 文件时,100%是釆用软解码方式的,而且并不会感觉到音质差,那么如同 PC —样,在手机等移动终端上采用软解码方式也可以达到4艮好的音质效果, 也就是说,采用软解码的音质并不一定就比采用硬解码的音质差,即使采用 硬解码方式,如果移动终端的硬件性能比较低,解码后的音质也是比较差的。并且,硬件解码器会增加移动终端的体积和重量,而采用软解码方式的 移动终端的体积和重量均会有所减小,价格也会下降一个档次。对于移动终 端越来越追求小巧、超薄,轻盈的趋势,采用软解码方式的移动终端将会具 有更大的市场竟争力。中国实用新型公开说明书CN200420112398公开了一种便携式媒体播放 器,此便携式媒体播放器虽然是采用软解码方式进行解码,但其只设置有音频处理模块和播放模块,仅能处理音频数据,而无法播放视频数据、音视频 混合数据、录音、录像、可视电话和流媒体等。
因此,如杲能找到一个通用的方法,能够实现对音频文件、视频文件、 音视频混合文件、数据文件、流媒体和可视电话等进行播放,对多^某体开发 人员来说,无疑将减少很多工作量,同时效率也会大幅度提高
发明内容
本发明要解决的技术问题是提供一种多媒体引擎的实现方法,能够实现 对包括音、视频文件、音视频混合文件、流媒体和可视电话等的播放以及对 语言、图像进行编码。为解决上述技术问题,本发明的一种多々某体引擎的实现方法,用户在人机交互接口 MM上选择开始,总控模块接收到MM发送的开始通知后,向 源元件、编解码通用元件和接受元件发送开始命令,启动源元件、编解码通 用元件和接受元件;源元件接收到开始命令后,读取数据,将所读取的数据发送给编解码通 用元件;编解码通用元件接收到源元件发送的数椐后,对数据进行编码或解码, 并发送给接受元件;接受元件将接收到的完成解码的数据发送给相应播放设备进行播放;将 完成编码的数据发送给存储设备进行保存。进一步地,源元件、编解码通用元件和接受元件通过衬垫进行链接,实 现数据的传输。进一步地,总控才莫块通过将相互链接的源元件、编解码通用元件和接受 元件加入到一管道中对源元件、编解码通用元件和接受元件进行控制,总控 模块将开始命令发送给管道,通过管道向源元件、编解码通用元件和接受元 件下发开始命令。进一步地,总控模块中开辟有多媒体管理数据区MMC,总控模块通过 在MMC中创建任务,将任务对应的管道的标识加入到MMC的管道链表中,
对管道进行控制。
进一步地,用户在选择开始之前,还在MMI上选择编解码类型,MMI
将用卢选择的编解码类型通知总控模块,总控模块根据编解码类型从一编解 码库中查找对应的编解码插件,将所查找到的编解码插件加栽到编解码通用 元件中,使编解码通用元件能够对数据进行编码或解码。
进一步地,用户在选择开始之前,还在MMI上选择数据,MMI将用户 选择的数据的读取路径通知总控模块,总控模块将数据的读取路径通知源元 件,源元件根据数据的读取路径读取数据。
进一步地,总控才莫块还根据数据的数据类型,从一编解码库中查找该数 据类型对应的编解码插件,并将查找到的编解码插件加栽到编解码通用元件 中,使编解码通用元件能够对数据进行编码或解码。
进一步地,当播放数据时,用户在选择数据的同时还设置播放参数,MMI 将播放参数通知总控模块,总控模块根据播放参数设置接收元件的参数,接 受元件将接收到的完成解码的数据发送给相应播放设备的同时,发送其播放 参数,控制播放设备对完成解码的数据的播放。
进一步地,总控才莫块向源元件、编解码通用元件和^l奏受元件发送开始命 令后,为源元件、编解码通用元件和接受元件创建线程,在该线程中实现源 元件读取数据,编解码通用元件对数据进行编码或解码,接受元件将完成解 码的数据发送给相应播放设备进行播放;将完成编码的数据发送给存储设备 进行保存。
进一步地,当数据为音频文件时,源元件为文件源元件,编解码通用元 件为音频解码元件,接受元件为音频"l妻受元件。
综上所述,本发明通过文件源元件读取数据,编解码通用元件进行编解 码,接受元件输出编解码后的数据流,实现了对音频文件、视频文件、音视 频混合文件、流媒体和可视电话等的播放以及对语言、图像进行编码,本发 明可以达到和硬解码一样的解码效杲,大大提高了开发效率,且成本更低, 并减小了硬件设备的体积和重量。
附围说明


图1为多媒体管理系统的框架图2为本发明所采用的源元件的示意图3为本发明所采用的编解码通用元件的示意图4为本发明所采用的"^妻受元件的示意图5为源元件、编解码通用元件和接受元件的链接示意图6为将链接后的源元件、编解码通用元件和接受元件加入到管道中的 示意图7为本发明播放音频文件的信号流程图。
具体实施例方式
本发明的播放多媒体文件的方法通过上层应用调用多媒体管理系统的初 始化函数,总控模块接收到初始化函数发送的初始化消息后,创建管道、源 元件、接受元件和编解码通用元件,将源元件、接受元件和编解码通用元件 加入到管道中。总控模块根椐用户设置或文件类型,在编解码库管理模块中 查找相应插件,并加栽到编解码通用元件中。上层应用调用多々某体管理系统 提供的播放函数,总控模块接收到播放函数发送的播放消息后,向管道下发 播放命令,管道接收到播放命令后,向其所包含的元件发送播放命令,接收 到播放命令后,源元件从外部读入数据,发送给编解码通用元件,编解码通 用元件对数据进行编码或解码,把编码或解码后的数据发送给接受元件,接 受元件将编码或解码后的数据输出给相应设备,进行播放或保存。
下面结合附图对本发明的具体实施方式
进行说明,
如图1所示,多々某体管理系统包括源元件、接受元件、编解码通用元 件、编解码库管理模块和总控模块,源元件读取外部数据,发送给编解码通 用元件;编解码通用元件将源元件输入的数据进行编码或者解码;接受元件 将编码或解码后的数据输出到相应设备;总控才莫块负责响应上层应用的各种 命令,按照不同的命令执行不同的操作,并向源元件、接受元件和编解码通
用元件下发控制命令,同时响应源元件、接受元件、编解码通用元件上净艮的
各种消息,针对不同的消息执行不同的操作;编解码库管理模块用于存储编 解码插件。
源元件可以通过文件形式(File)、流媒体形式(Stream)读入数据,也 可以从麦克风(MIC)和摄像头(Sensor)等读入数据。
接受元件可以通过文件形式(File )输出数据,也可以从扬声器(Speaker )、 液晶显示屏(Liquid Crystal Display , LCD)输出数据。
在系统中还设置有解码芯片,通过该解码芯片实现硬解码。
总控模块向MMI (Man-Machine Interface,人才几交互4委口,统称为上层 应用)提供各种应用接口 API (应用接口 )函数,用户可以非常方便的以这 套API函数构建自己的媒体播放器。用户只需要实现界面,并按照要求调用 总控模块提供的API函数就可以实现多媒体引擎的全部功能。
下面对上述系统的各组成部分进行详细说明
元件依椐面向对象的思想,元件是一个具有特殊功能的对象,可以通 过构建对象,来创建元件,元件是组成多々某体管道的基本单元。元件的功能 为(1)元件可以作为一个独立的功能个体存在,例如,实现读取数据,对 数据进行处理,再输出处理后的数据等;(2)元件还可以作为一个基类,派 生出其他具有特定功能的元件,如源元件、类过滤元件和接受元件等。
每个元件都具有一些函数接口 ,用户通过调用函数接口实现元件的功能。 例如创建了一个读取文件的元件,那么该元件就具有一个读取文件的函数接 口,用户通过调用该函数接口,就可以实现读取文件的操作。元件的数据结 构中包含元件名、衬垫数目、衬垫链表以及该元件的处理函数等。
源元件是由元件派生出的功能元件。源元件负责为多4某体管道读取数 据,作为多媒体管道的数据产生源,为多媒体管道产生数据。源元件具有其
自身的函数接口,包括读文件函数等,用户可通过调用其函数接口来使用源 元件。源元件的数据结构中包含源元件名、衬垫数目(源元件仅有一个输
出衬垫,用于向管道中传送数据)和源元件的函数接口等。
类过滤元件也是由元件派生出的功能元件,类过滤元件的功能类似于过滤器,类过滤元件具有输入和输出衬垫,对从输入衬垫获取的数据进行处 理,然后将处理后的数据发送给输出衬垫。类过滤元件也具有自身的函数接 口 ,包括类过滤元件的初始化函数、类过滤元件的处理函数和类过滤元件的 卸栽函数等,用户通过调用其函数接口来使用该元件。类过滤元件的数据结
构中包含类过滤元件名、衬垫数目(类过滤元件可以具有任意多个的输入 衬垫和输出衬垫)、衬垫链表和类过滤元件的处理函数等。
编解码通用元件属于类过滤元件,是类过滤元件中的一个具有编解码 功能的元件。编解码通用元件具有输入和输出衬垫,其对从输入衬垫获取的 数据进行编码或解码,然后将编码或解码后的数据通过输出衬垫输出。编解 码通用元件也有自己的函数接口,包括编解码通用元件的初始化函数、编解 码通用元件的指针获取函数、编解码通用元件的总控消息处理函数和编解码 通用元件的卸载函数等,用户通过调用它的函数接口来使用该元件。编解码 通用元件的数据结构中包含编解码通用元件名、衬垫数目、衬垫链表和编 解码通用元件的总控消息处理函数。
接受元件是由元件派生出的功能元件,接受元件在々某体管道末端,负 责接收数据,并将接收到的数据输出给播放设备的驱动程序。接受元件的数 据结构中包含接受元件名、衬垫数目(接受元件仅有一个输入衬垫)、衬 垫链表和接受元件的总控消息处理函数等。
管道也是由元件派生出来的一个功能元件,管道可以包含多个元件, 类似于一个装载元件的容器。管道中有一个作为元件链表的成员变量,将管 道包含的元件用链表的形式链接起来,通过链表头就可以方便地找到每一个 元件,以便管理。管道可以统一操作其所包含的所有元件,因此可以通过操 作管道达到对多个元件的操作,从而降低应用程序的复杂度,可以通过改变 一个管道的状态来改变管道内部所有元件的状态,例如,在将管道设置为播 放状态时,数据流开始流动,启动对多i某体数据的处理。一旦被启动,管道 将在一个单独的线程中运行,直到被停止或者数据流播放完毕。管道具有其 自身的函数接口,包括创建管道函数、销毁管道函数、向管道中元件下发消 息函数、管道线程入口函数等,用户可通过调用其函数接口来使用管道。管 道的数据结构中包含管道名、管道中元件数目、管道中元件链表、管道线
程状态和管道线程入口函数等。
衬垫衬垫亦为一对象,可通过构建对象来创建衬垫。衬垫用于链接元 件,使数据流能在元件之间流动,衬垫能够限制所通过的数据流的类型,链 接成功的条件是两个衬垫允许通过的数据类型一致。所有的数据流都是在链 接好的元件之间流动。元件通过一个或者多个衬垫接受数据流,数据流通过 一个或者多个衬垫流出元件。衬垫包含输入村垫和输出衬垫,输入村垫用于 接收数据,输出衬垫用于输出数据,衬垫包含衬垫名、衬垫类型和衬垫接 口函数等。
如图7所示,为本发明的方法播放音频文件的流程图,包括如下步骤
系统启动时,多4某体模块初始化函数对多々某体管理系统进行初始化。
初始化时,首先调用总控模块的初始化函数初始化总控模块,再调用编 解码插件管理才莫块的初始化函数,初始化编解码插件管理才莫块中的配置文件信息。
701:用户在MMI上选择启动多媒体管理系统并选择媒体源后,MMI 向总控模块发送EV—ZMMF—TASK—OPEN—REQ消息(初始化消息),将媒 体源作为该消息的参数通知总控模块;
702:总控模块接收到EV—ZMMF—TASK—OPEN—REQ消息后,根据媒体 源调用其自身的相应初始化函数;
本实施例中,々某体源为音频文件,总控模块判定要播放音频文件时,调 用音频初始化函数。
703:音频初始化函数创建文件源元件、音频解码元件和音频接受元件;
文件源元件用于读取以文件形式存储的数据;音频解码元件用于对音频 文件进行解码;音频接受元件用于将音频解码完成的数据发送给音频播放设 备的驱动程序,以对音频文件进行播放。
704:音频初始化函数创建音频管道,在创建音频管道的同时创建对音频 管道进行控制的音频线程;
705:音频初始化函数对文件源元件、音频解码元件和音频接受元件进行 链接,并将该三个元件加入到音频管道中;
在对上述三个元件进行链接时,需要分别查找到文件源元件的输出衬垫, 音频解码元件的输入衬垫和输出衬垫以及音频接受元件的输入衬垫,并建立 文件源元件的输出衬垫与音频解码元件的输入村垫之间的链接,建立音频解 码元件的输出衬垫与音频接受元件的输入衬垫之间的连接。
706:音频初始化函数对音频线程的入口函数进行初始化;
初始化音频线程的入口函数时,将音频线程的入口函数赋值为文件源元 件的读文件函数(即音频线程启动后需要首先执行的函数),并把音频线程 的入口函数的参数赋值为文件源元件的读文件函数的参数。
707:音频初始化函数在总控模块的某一MMC (MultiMedia Management circumscription,多媒体管理数据区)中添加音频播放任务,并获取添加该音 频播放任务的MMC数据区的ID号,初始化MMC中成员变量信息,将音频 管道的管道标识加入到上述MMC数据区的管道链表中;
MMC数据区为一数据结构,包含ID号、是否被占用、当前任务ID号、 当前业务类型、MMC的当前管道链表和媒体来源等成员变量。 一个MMC 数据区对应一个任务,每个任务可能对应一个管道,也可能对应多个管道, 使用MMC数据区能够更好地管理任务和管道。可能存在多个任务同时来调 用多4某体,每新建一个任务,就将该任务加入到一个MMC数据区中,一个 MMC数据区对应一个唯一的ID号,通过该ID号就可以找到相应的任务。 不管同时存在多少任务,利用MMC数据区的ID号就可以找到相应的任务和 管道,不会造成混乱。
初始化MMC中成员变量信息是指,在MMC数据区中新增一个任务后, 按照新增任务的参数为MMC数据区的成员变量赋初始值,如设置MMC当 前的业务类型、当前任务的媒体来源、当前任务是否循环播放、当前任务的 音量大小和MMC数据区已经被占用等信息。
管道链表是指,将一个任务用到的 一个或多个管道用链表的形式链接起 来,通过链表头就可以方便地找到每一个管道,使用管道链表更易于对管道 进行管理, 一个任务对应一个管道链表。
708:用户在MM上选择解码类型,MMI通过向总控模块发送
EV一ZMMF—TASK—SET—CODEC一REQ消息(设置编解码消息),将用户逸 择的解码类型作为该消息的参数通知总控模块;
709:总控模块接收到EV一ZMMF—TASK一SET—CODEC—REQ消息后,根 据解码类型从编解码库的配置文件中查询对应的编解码插件,并从编解码库 中查找到对应的编解码插件;
710:总控模块根据MMC数据区的ID号,查找到音频播放任务所在的 MMC数据区,根据音频管道的管道标识从MMC数据区的管道链表中查找的 音频管道,将编解码插件加载到该音频管道的音频解码元件中,同时,从配 置文件中加栽该编解码插件对应的初始化函数,Element (元素)对象和析构 函数,并将其操作指针连接到本地指针,以对其进行操作;
711:用户在MMI中选择要播放的音频文件并设置播放参数,MMI通过 向总控模块发送EV—ZMMF—TASK—SET—OPT一REQ消息(设置参数消息), 将该音频文件的存储路径、文件名和播放参数作为该消息的参数通知总控模
块;
播放参数包括播放音量、播放通道、釆样率和播放设备(如扬声器或 耳机)等
712:总控模块接收到EV—ZMMF—TASK—SET—OPT—REQ消息后,将接 收到该要播放的音频文件的存储路径、文件名和播放参数进行保存,并根据 播放参数设置音频接受元件的参数;
对于文件源元件需设置其每次读取数据的数据量,可设置为每次读取32 个字节,同时,总控才莫块将音频文件的存储路径和文件名发送给文件源元件。
对于音频接受元件,需要根据播放参数设置音频接受元件的播放音量、 播放通道和采样率等。
如杲用户并未在MMI上选择编解码类型,即未执行步骤708和709,则 总控模块在接收到EV—ZMMF_TASK—SET—OPT—REQ消息后,还需要根据音 频文件的扩展名判断音频文件的文件类型,根据文件类型从编解码库的配置 文件中查询该文件类型对应的编解码插件,并从编解码库中查找到该对应的 编解码插件,并将其加载到音频解码元件中,同时,从配置文件中加载该编
解码插件对应的初始化函数,Element对象和析构函数,并将其操作指针连接 到本地指针,以对其进行操作;
713:用户在MMI中选择开始播放音频文件,MMI向总控模块发送 EV—ZMMF一TASK—PLAY—REQ消息(开始播放消息),总控模块接收到该消 息后,向音频管道发送开始播放命令,音频管道接收到开始播放命令后,向 其下的文件源元件、音频解码元件和音频接受元件下发开始播放命令;
总控模块在向音频管道发送开始播放命令时,同样根据MMC数据区的 ID号,查找到音频播放任务所在的MMC数据区,根据音频管道的管道标识 从MMC数据区的管道链表中查找到音频管道。
714:总控才莫块为文件源元件、音频解码元件和音频4妻受元件创建解码线 程,音频线程启动该解码线程;
715:总控模块等待结束消息;
716:在解码线程中,文件源元件根据音频文件的存储路径读取出音频文 件,并将其从输出衬垫发送到音频解码元件的输入衬垫;
77:音频解码元件的输入衬垫接收到音频文件后,音频解码元件通过编 解码插件对音频文件进行解码,并将解码完成的数据流从其输出衬垫发送到 音频接受元件的输入衬垫;
718:音频接受元件的输入衬垫接收到数据流后,音频接受元件将数据流 发送给音频播放器的驱动程序,同时,将其上设置的播放音量、播;故通道和 采样率等播放参数通知驱动程序,驱动程序控制音频播放器对音频文件进行 播放;
文件源元件在读取音频文件时,也可以申请分配一块緩冲区,将读取出 的音频文件从输出衬垫緩存到緩冲区中,音频解码元件从緩冲区中读取音频 文件进行解码,将解码后的数据流输出到緩冲区中,音频接受元件从緩冲区 中读取数据流,发送给音频播放器的驱动程序。
719:如果用户选择暂停播放时,MMI向总控模块发送 EV—ZMMF—TASK—PAUSE—REQ (暂停消息),总控模块接收到该消息后, 向MMC数据区中的音频管道发送暂停命令,并通知音频线程暂停播放;
720:音频管道接收到暂停命令后,向文件源元件、音频解码元件和音频 接受元件发送暂停命令;
721:音频线程挂起,暂停播放;
722:在对音频文件进行解码播放的过程中,如果发生错误或异常,则解 码线程桂起,暂停播放,并向总控模块发送通知消息,进行上报;
723:总控模块接收到通知消息后,对错误或异常进行处理或上报给用户;
724:当音频文件解码结束时,解码线程向总控模块发送结束消息;
725:总控模块接收到结束消息后,向MMI发送结束消息,MMI接收到 结束消息后,提示用户播放结束;
726 : 如果用户选择结束播放,则MMI向总控模块发送 EV—ZMMF—TASK—CLOSE—REQ消息(关闭消息),总控模块接收到该消息 后,调用停止线程函数停止解码线程,并唤醒处于桂起状态的优先级低于解 码线程的其它线程进行任务;
如果用户未选择结束播放,而是选择重复播放则执行步骤713;如果用 户选择其它音频文件进行播放则执行步骤711或713。
727:总控模块向音频管道中的文件源元件、音频解码元件和音频接受元 件下发停止命令,删除音频管道中的上述三个元件及音频管道,清空MMC 数据区;
728:解码线程切换到停止状态,结束线程、释放资源;
729 :总控模块获知解码线程结束后,向MMI发送 EV—ZMMF—INFO—CLOSE—RSP消息(已关闭消息),通知用户已结束。
播放视频文件与播放音频文件的区别在于接受元件的类型不同,播放 音频文件时,接受元件是音频接受元件,音频接受元件将接受到音频解码元 件传送的数据输出到音频设备上,如扬声器等。播放视频文件时,接受元件 是视频接受元件,视频接受元件将接受到視频解码元件传送的数据输出到视 频设备上,如液晶显示屏上。
录音与播放音频文件的区别在于播放音频文件时,源元件是文件源元 件,编解码通用元件是音频解码元件,接受元件是音频接受元件,而录音时, 管道中的源元件是音频源元件,用于从MC接收语音;编解码通用元件是音 频编码元件,用于对语言进行编码;接受元件是文件接受元件,用于将编码 后的文件输出到存储设备。
录像与播放音频文件的区别在于录像时,源元件是视频源元件,用于 从摄像头读取图像;编解码通用元件是视频编码元件,用于对图像进行编码; 接受元件是文件接受元件,用于将编码后的文件输出到存储设备。
播;故音视频混合文件时需创建三个管道,分别为解复用管道、音频解 码管道和视频解码管道,解复用管道中包含一个解复用元件,解复用元件也 是由元件派生出来的功能元件,用于将音视频文件解复用成音频和视频两路; 音频解码管道包含音频解码元件和音频接受元件;视频解码管道包含视频解 码元件和视频接受元件。
音枧频混合文件经过解复用管道完成解复用后分为同步的音频数据和视 频数据,将要解码的一段音频数据和一段视频数据在解码前记录上时间,使 用音频解码元件和^l频解码元件分别进行解码,解码完成后,将音频数据和 视频数据的时间进行比较,通常音频数据解码较快,解码完成后需要緩存, 在与音频数据时间相同的视频数据解码完成后,同时输出给播放设备的驱动 程序进行播放。
权利要求
1、一种多媒体引擎的实现方法,其特征在于,用户在人机交互接口MMI上选择开始,总控模块接收到MMI发送的开始通知后,向源元件、编解码通用元件和接受元件发送开始命令,启动所述源元件、编解码通用元件和接受元件;源元件接收到开始命令后,读取数据,将所读取的数据发送给编解码通用元件;编解码通用元件接收到源元件发送的数据后,对所述数据进行编码或解码,并发送给接受元件;接受元件将接收到的完成解码的数据发送给相应播放设备进行播放;将完成编码的数据发送给存储设备进行保存。
2、 如权利要求l所述的方法,其特征在于,所述源元件、编解码通用元 件和"^妄受元件通过衬垫进行链接,实现数据的传输。
3、 如权利要求2所述的方法,其特征在于,所述总控模块通过将相互链 接的所述源元件、编解码通用元件和接受元件加入到一管道中对所述源元件、 编解码通用元件和"^受元件进行控制,所述总控;f莫块将所述开始命令发送给 管道,通过管道向所述源元件、编解码通用元件和接受元件下发开始命令。
4、 如权利要求3所述的方法,其特征在于,所述总控模块中开辟有多媒 体管理数据区MMC,所述总控才莫块通过在所述MMC中创建任务,将所述任 务对应的管道的标识加入到所述MMC的管道链表中,对管道进行控制。
5、 如权利要求l所述的方法,其特征在于,所述用户在选择开始之前, 还在MMI上选择编解码类型,MMI将用户选择的所述编解码类型通知总控 模块,所述总控模块根据编解码类型从一编解码库中查找对应的编解码插件, 将所查找到的编解码插件加栽到所述编解码通用元件中,使编解码通用元件 能够对数据进行编码或解码。
6、 如权利要求l所述的方法,其特征在于,所述用户在选择开始之前, 还在MM1上选择所述数据,MMI将用户选择的所述数据的读取路径通知总 控模块,所述总控模块将所述数据的读取路径通知所述源元件,所述源元件 根据所述数据的读取路径读取数据。
7、 如权利要求6所述的方法,其特征在于,所述总控模块还根据所述数 据的数据类型,从一编解码库中查找该数据类型对应的编解码插件,并将查 找到的编解码插件加栽到所述编解码通用元件中,使编解码通用元件能够对 数据进行编码或解码。
8、 如权利要求6所述的方法,其特征在于,当播放数据时,所述用户在 选择所述数据的同时还设置播放参数,MMI将所述播放参数通知总控模块, 所述总控模块根据所述播放参数设置所述接收元件的参数,所述接受元件将 接收到的完成解码的数据发送给相应播放设备的同时,发送其播放参数,控 制播放设备对完成解码的数据的播放。
9、 如权利要求l所述的方法,其特征在于,所述总控模块向源元件、编 解码通用元件和接受元件发送开始命令后,为所述源元件、编解码通用元件 和接受元件创建线程,在该线程中实现所述源元件读取数据,所述编解码通 用元件对所述数据进行编码或解码,所述接受元件将完成解码的数据发送给 相应播放设备进行播放;将完成编码的数据发送给存储设备进行保存。
10、 如权利要求1所述的方法,其特征在于,当所述数据为音频文件时, 所述源元件为文件源元件,所述编解码通用元件为音频解码元件,所述4娄受 元件为音频接受元件。
全文摘要
本发明公开了一种多媒体引擎的实现方法,用户在人机交互接口MMI上选择开始,总控模块接收到MMI发送的开始通知后,向源元件、编解码通用元件和接受元件发送开始命令,启动源元件、编解码通用元件和接受元件;源元件接收到开始命令后,读取数据,将所读取的数据发送给编解码通用元件;编解码通用元件接收到源元件发送的数据后,对数据进行编码或解码,并发送给接受元件;接受元件将接收到的完成解码的数据发送给相应播放设备进行播放;将完成编码的数据发送给存储设备进行保存。本发明可以达到和硬解码一样的解码效果,大大提高了开发效率,且成本更低,并减小了硬件设备的体积和重量。
文档编号H04N7/14GK101339789SQ20081021050
公开日2009年1月7日 申请日期2008年8月13日 优先权日2008年8月13日
发明者彭海勇, 李兴华, 浩 杨, 臧成松, 芳 赵, 明 陈 申请人:中兴通讯股份有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1