CN101339789A - 一种多媒体引擎的实现方法 - Google Patents

Abstract

本发明公开了一种多媒体引擎的实现方法，用户在人机交互接口MMI上选择开始，总控模块接收到MMI发送的开始通知后，向源元件、编解码通用元件和接受元件发送开始命令，启动源元件、编解码通用元件和接受元件；源元件接收到开始命令后，读取数据，将所读取的数据发送给编解码通用元件；编解码通用元件接收到源元件发送的数据后，对数据进行编码或解码，并发送给接受元件；接受元件将接收到的完成解码的数据发送给相应播放设备进行播放；将完成编码的数据发送给存储设备进行保存。本发明可以达到和硬解码一样的解码效果，大大提高了开发效率，且成本更低，并减小了硬件设备的体积和重量。

Description

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

技术领域

本发明涉及多媒体技术领域，尤其涉及一种多媒体引擎的实现方法。

背景技术

近年来，多媒体技术发展迅速，并广泛地应用到生产生活的各个领域中，如，通讯、电脑游戏、教育、档案管理、图书、娱乐、艺术、股票债券、金融交易和建筑设计等。同时，随着移动终端日益成为人们日常生活中不可缺少的一种工具，多媒体技术在移动终端上的应用也得到了进一步的发展。

目前，移动终端上的多媒体解码器普遍采用硬件解码器，人们通常认为硬解码方式的解码效果优于软解码方式，该结论主要是根据两种解码方案音质的区别得出的，但音质的好坏并不仅仅取决于解码方式，影响音质的主要因素是移动终端的硬件性能。

目前如手机等移动终端正逐渐向智能型发展，智能手机最大的特点就是与PC(个人电脑)有着相似的架构和工作原理。显然，在PC上播放MP3文件时，100％是采用软解码方式的，而且并不会感觉到音质差，那么如同PC一样，在手机等移动终端上采用软解码方式也可以达到很好的音质效果，也就是说，采用软解码的音质并不一定就比采用硬解码的音质差，即使采用硬解码方式，如果移动终端的硬件性能比较低，解码后的音质也是比较差的。

并且，硬件解码器会增加移动终端的体积和重量，而采用软解码方式的移动终端的体积和重量均会有所减小，价格也会下降一个档次。对于移动终端越来越追求小巧、超薄，轻盈的趋势，采用软解码方式的移动终端将会具有更大的市场竞争力。

中国实用新型公开说明书CN200420112398公开了一种便携式媒体播放器，此便携式媒体播放器虽然是采用软解码方式进行解码，但其只设置有音频处理模块和播放模块，仅能处理音频数据，而无法播放视频数据、音视频混合数据、录音、录像、可视电话和流媒体等。

因此，如果能找到一个通用的方法，能够实现对音频文件、视频文件、音视频混合文件、数据文件、流媒体和可视电话等进行播放，对多媒体开发人员来说，无疑将减少很多工作量，同时效率也会大幅度提高。

发明内容

本发明要解决的技术问题是提供一种多媒体引擎的实现方法，能够实现对包括音、视频文件、音视频混合文件、流媒体和可视电话等的播放以及对语言、图像进行编码。

为解决上述技术问题，本发明的一种多媒体引擎的实现方法，用户在人机交互接口MMI上选择开始，总控模块接收到MMI发送的开始通知后，向源元件、编解码通用元件和接受元件发送开始命令，启动源元件、编解码通用元件和接受元件；

源元件接收到开始命令后，读取数据，将所读取的数据发送给编解码通用元件；

编解码通用元件接收到源元件发送的数据后，对数据进行编码或解码，并发送给接受元件；

接受元件将接收到的完成解码的数据发送给相应播放设备进行播放；将完成编码的数据发送给存储设备进行保存。

进一步地，源元件、编解码通用元件和接受元件通过衬垫进行链接，实现数据的传输。

进一步地，总控模块通过将相互链接的源元件、编解码通用元件和接受元件加入到一管道中对源元件、编解码通用元件和接受元件进行控制，总控模块将开始命令发送给管道，通过管道向源元件、编解码通用元件和接受元件下发开始命令。

进一步地，总控模块中开辟有多媒体管理数据区MMC，总控模块通过在MMC中创建任务，将任务对应的管道的标识加入到MMC的管道链表中，对管道进行控制。

进一步地，用户在选择开始之前，还在MMI上选择编解码类型，MMI将用户选择的编解码类型通知总控模块，总控模块根据编解码类型从一编解码库中查找对应的编解码插件，将所查找到的编解码插件加载到编解码通用元件中，使编解码通用元件能够对数据进行编码或解码。

进一步地，用户在选择开始之前，还在MMI上选择数据，MMI将用户选择的数据的读取路径通知总控模块，总控模块将数据的读取路径通知源元件，源元件根据数据的读取路径读取数据。

进一步地，总控模块还根据数据的数据类型，从一编解码库中查找该数据类型对应的编解码插件，并将查找到的编解码插件加载到编解码通用元件中，使编解码通用元件能够对数据进行编码或解码。

进一步地，当播放数据时，用户在选择数据的同时还设置播放参数，MMI将播放参数通知总控模块，总控模块根据播放参数设置接收元件的参数，接受元件将接收到的完成解码的数据发送给相应播放设备的同时，发送其播放参数，控制播放设备对完成解码的数据的播放。

进一步地，总控模块向源元件、编解码通用元件和接受元件发送开始命令后，为源元件、编解码通用元件和接受元件创建线程，在该线程中实现源元件读取数据，编解码通用元件对数据进行编码或解码，接受元件将完成解码的数据发送给相应播放设备进行播放；将完成编码的数据发送给存储设备进行保存。

进一步地，当数据为音频文件时，源元件为文件源元件，编解码通用元件为音频解码元件，接受元件为音频接受元件。

综上所述，本发明通过文件源元件读取数据，编解码通用元件进行编解码，接受元件输出编解码后的数据流，实现了对音频文件、视频文件、音视频混合文件、流媒体和可视电话等的播放以及对语言、图像进行编码，本发明可以达到和硬解码一样的解码效果，大大提高了开发效率，且成本更低，并减小了硬件设备的体积和重量。

附图说明

图1为多媒体管理系统的框架图；

图2为本发明所采用的源元件的示意图；

图3为本发明所采用的编解码通用元件的示意图；

图4为本发明所采用的接受元件的示意图；

图5为源元件、编解码通用元件和接受元件的链接示意图；

图6为将链接后的源元件、编解码通用元件和接受元件加入到管道中的示意图；

图7为本发明播放音频文件的信号流程图。

具体实施方式

本发明的播放多媒体文件的方法通过上层应用调用多媒体管理系统的初始化函数，总控模块接收到初始化函数发送的初始化消息后，创建管道、源元件、接受元件和编解码通用元件，将源元件、接受元件和编解码通用元件加入到管道中。总控模块根据用户设置或文件类型，在编解码库管理模块中查找相应插件，并加载到编解码通用元件中。上层应用调用多媒体管理系统提供的播放函数，总控模块接收到播放函数发送的播放消息后，向管道下发播放命令，管道接收到播放命令后，向其所包含的元件发送播放命令，接收到播放命令后，源元件从外部读入数据，发送给编解码通用元件，编解码通用元件对数据进行编码或解码，把编码或解码后的数据发送给接受元件，接受元件将编码或解码后的数据输出给相应设备，进行播放或保存。

下面结合附图对本发明的具体实施方式进行说明，

如图1所示，多媒体管理系统包括：源元件、接受元件、编解码通用元件、编解码库管理模块和总控模块，源元件读取外部数据，发送给编解码通用元件；编解码通用元件将源元件输入的数据进行编码或者解码；接受元件将编码或解码后的数据输出到相应设备；总控模块负责响应上层应用的各种命令，按照不同的命令执行不同的操作，并向源元件、接受元件和编解码通用元件下发控制命令，同时响应源元件、接受元件、编解码通用元件上报的各种消息，针对不同的消息执行不同的操作；编解码库管理模块用于存储编解码插件。

源元件可以通过文件形式(File)、流媒体形式(Stream)读入数据，也可以从麦克风(MIC)和摄像头(Sensor)等读入数据。

接受元件可以通过文件形式(File)输出数据，也可以从扬声器(Speaker)、液晶显示屏(Liquid Crystal Display，LCD)输出数据。

在系统中还设置有解码芯片，通过该解码芯片实现硬解码。

总控模块向MMI(Man-Machine Interface，人机交互接口，统称为上层应用)提供各种应用接口API(应用接口)函数，用户可以非常方便的以这套API函数构建自己的媒体播放器。用户只需要实现界面，并按照要求调用总控模块提供的API函数就可以实现多媒体引擎的全部功能。

下面对上述系统的各组成部分进行详细说明：

元件：依据面向对象的思想，元件是一个具有特殊功能的对象，可以通过构建对象，来创建元件，元件是组成多媒体管道的基本单元。元件的功能为：(1)元件可以作为一个独立的功能个体存在，例如，实现读取数据，对数据进行处理，再输出处理后的数据等；(2)元件还可以作为一个基类，派生出其他具有特定功能的元件，如源元件、类过滤元件和接受元件等。

每个元件都具有一些函数接口，用户通过调用函数接口实现元件的功能。例如创建了一个读取文件的元件，那么该元件就具有一个读取文件的函数接口，用户通过调用该函数接口，就可以实现读取文件的操作。元件的数据结构中包含：元件名、衬垫数目、衬垫链表以及该元件的处理函数等。

源元件：是由元件派生出的功能元件。源元件负责为多媒体管道读取数据，作为多媒体管道的数据产生源，为多媒体管道产生数据。源元件具有其自身的函数接口，包括读文件函数等，用户可通过调用其函数接口来使用源元件。源元件的数据结构中包含：源元件名、衬垫数目(源元件仅有一个输出衬垫，用于向管道中传送数据)和源元件的函数接口等。

类过滤元件：也是由元件派生出的功能元件，类过滤元件的功能类似于过滤器，类过滤元件具有输入和输出衬垫，对从输入衬垫获取的数据进行处理，然后将处理后的数据发送给输出衬垫。类过滤元件也具有自身的函数接口，包括类过滤元件的初始化函数、类过滤元件的处理函数和类过滤元件的卸载函数等，用户通过调用其函数接口来使用该元件。类过滤元件的数据结构中包含：类过滤元件名、衬垫数目(类过滤元件可以具有任意多个的输入衬垫和输出衬垫)、衬垫链表和类过滤元件的处理函数等。

编解码通用元件：属于类过滤元件，是类过滤元件中的一个具有编解码功能的元件。编解码通用元件具有输入和输出衬垫，其对从输入衬垫获取的数据进行编码或解码，然后将编码或解码后的数据通过输出衬垫输出。编解码通用元件也有自己的函数接口，包括编解码通用元件的初始化函数、编解码通用元件的指针获取函数、编解码通用元件的总控消息处理函数和编解码通用元件的卸载函数等，用户通过调用它的函数接口来使用该元件。编解码通用元件的数据结构中包含：编解码通用元件名、衬垫数目、衬垫链表和编解码通用元件的总控消息处理函数。

接受元件；是由元件派生出的功能元件，接受元件在媒体管道末端，负责接收数据，并将接收到的数据输出给播放设备的驱动程序。接受元件的数据结构中包含：接受元件名、衬垫数目(接受元件仅有一个输入衬垫)、衬垫链表和接受元件的总控消息处理函数等。

管道：也是由元件派生出来的一个功能元件，管道可以包含多个元件，类似于一个装载元件的容器。管道中有一个作为元件链表的成员变量，将管道包含的元件用链表的形式链接起来，通过链表头就可以方便地找到每一个元件，以便管理。管道可以统一操作其所包含的所有元件，因此可以通过操作管道达到对多个元件的操作，从而降低应用程序的复杂度，可以通过改变一个管道的状态来改变管道内部所有元件的状态，例如，在将管道设置为播放状态时，数据流开始流动，启动对多媒体数据的处理。一旦被启动，管道将在一个单独的线程中运行，直到被停止或者数据流播放完毕。管道具有其自身的函数接口，包括创建管道函数、销毁管道函数、向管道中元件下发消息函数、管道线程入口函数等，用户可通过调用其函数接口来使用管道。管道的数据结构中包含：管道名、管道中元件数目、管道中元件链表、管道线程状态和管道线程入口函数等。

衬垫：衬垫亦为一对象，可通过构建对象来创建衬垫。衬垫用于链接元件，使数据流能在元件之间流动，衬垫能够限制所通过的数据流的类型，链接成功的条件是两个衬垫允许通过的数据类型一致。所有的数据流都是在链接好的元件之间流动。元件通过一个或者多个衬垫接受数据流，数据流通过一个或者多个衬垫流出元件。衬垫包含输入衬垫和输出衬垫，输入衬垫用于接收数据，输出衬垫用于输出数据，衬垫包含：衬垫名、衬垫类型和衬垫接口函数等。

如图7所示，为本发明的方法播放音频文件的流程图，包括如下步骤：

系统启动时，多媒体模块初始化函数对多媒体管理系统进行初始化。

初始化时，首先调用总控模块的初始化函数初始化总控模块，再调用编解码插件管理模块的初始化函数，初始化编解码插件管理模块中的配置文件信息。

701：用户在MMI上选择启动多媒体管理系统并选择媒体源后，MMI向总控模块发送EV_ZMMF_TASK_OPEN_REQ消息(初始化消息)，将媒体源作为该消息的参数通知总控模块；

702：总控模块接收到EV_ZMMF_TASK_OPEN_REQ消息后，根据媒体源调用其自身的相应初始化函数；

本实施例中，媒体源为音频文件，总控模块判定要播放音频文件时，调用音频初始化函数。

703：音频初始化函数创建文件源元件、音频解码元件和音频接受元件；

文件源元件用于读取以文件形式存储的数据；音频解码元件用于对音频文件进行解码；音频接受元件用于将音频解码完成的数据发送给音频播放设备的驱动程序，以对音频文件进行播放。

704：音频初始化函数创建音频管道，在创建音频管道的同时创建对音频管道进行控制的音频线程；

705：音频初始化函数对文件源元件、音频解码元件和音频接受元件进行链接，并将该三个元件加入到音频管道中；

在对上述三个元件进行链接时，需要分别查找到文件源元件的输出衬垫，音频解码元件的输入衬垫和输出衬垫以及音频接受元件的输入衬垫，并建立文件源元件的输出衬垫与音频解码元件的输入衬垫之间的链接，建立音频解码元件的输出衬垫与音频接受元件的输入衬垫之间的连接。

706：音频初始化函数对音频线程的入口函数进行初始化；

初始化音频线程的入口函数时，将音频线程的入口函数赋值为文件源元件的读文件函数(即音频线程启动后需要首先执行的函数)，并把音频线程的入口函数的参数赋值为文件源元件的读文件函数的参数。

707：音频初始化函数在总控模块的某一MMC(MultiMedia Managementcircumscription，多媒体管理数据区)中添加音频播放任务，并获取添加该音频播放任务的MMC数据区的ID号，初始化MMC中成员变量信息，将音频管道的管道标识加入到上述MMC数据区的管道链表中；

MMC数据区为一数据结构，包含：ID号、是否被占用、当前任务ID号、当前业务类型、MMC的当前管道链表和媒体来源等成员变量。一个MMC数据区对应一个任务，每个任务可能对应一个管道，也可能对应多个管道，使用MMC数据区能够更好地管理任务和管道。可能存在多个任务同时来调用多媒体，每新建一个任务，就将该任务加入到一个MMC数据区中，一个MMC数据区对应一个唯一的ID号，通过该ID号就可以找到相应的任务。不管同时存在多少任务，利用MMC数据区的ID号就可以找到相应的任务和管道，不会造成混乱。

初始化MMC中成员变量信息是指，在MMC数据区中新增一个任务后，按照新增任务的参数为MMC数据区的成员变量赋初始值，如设置MMC当前的业务类型、当前任务的媒体来源、当前任务是否循环播放、当前任务的音量大小和MMC数据区已经被占用等信息。

管道链表是指，将一个任务用到的一个或多个管道用链表的形式链接起来，通过链表头就可以方便地找到每一个管道，使用管道链表更易于对管道进行管理，一个任务对应一个管道链表。

708：用户在MMI上选择解码类型，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：总控模块为文件源元件、音频解码元件和音频接受元件创建解码线程，音频线程启动该解码线程；

715：总控模块等待结束消息；

716：在解码线程中，文件源元件根据音频文件的存储路径读取出音频文件，并将其从输出衬垫发送到音频解码元件的输入衬垫；

717：音频解码元件的输入衬垫接收到音频文件后，音频解码元件通过编解码插件对音频文件进行解码，并将解码完成的数据流从其输出衬垫发送到音频接受元件的输入衬垫；

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消息(已关闭消息)，通知用户已结束。

播放视频文件与播放音频文件的区别在于：接受元件的类型不同，播放音频文件时，接受元件是音频接受元件，音频接受元件将接受到音频解码元件传送的数据输出到音频设备上，如扬声器等。播放视频文件时，接受元件是视频接受元件，视频接受元件将接受到视频解码元件传送的数据输出到视频设备上，如液晶显示屏上。

录音与播放音频文件的区别在于：播放音频文件时，源元件是文件源元件，编解码通用元件是音频解码元件，接受元件是音频接受元件，而录音时，管道中的源元件是音频源元件，用于从MIC接收语音；编解码通用元件是音频编码元件，用于对语言进行编码；接受元件是文件接受元件，用于将编码后的文件输出到存储设备。

录像与播放音频文件的区别在于：录像时，源元件是视频源元件，用于从摄像头读取图像；编解码通用元件是视频编码元件，用于对图像进行编码；接受元件是文件接受元件，用于将编码后的文件输出到存储设备。

播放音视频混合文件时：需创建三个管道，分别为解复用管道、音频解码管道和视频解码管道，解复用管道中包含一个解复用元件，解复用元件也是由元件派生出来的功能元件，用于将音视频文件解复用成音频和视频两路；音频解码管道包含音频解码元件和音频接受元件；视频解码管道包含视频解码元件和视频接受元件。

音视频混合文件经过解复用管道完成解复用后分为同步的音频数据和视频数据，将要解码的一段音频数据和一段视频数据在解码前记录上时间，使用音频解码元件和视频解码元件分别进行解码，解码完成后，将音频数据和视频数据的时间进行比较，通常音频数据解码较快，解码完成后需要缓存，在与音频数据时间相同的视频数据解码完成后，同时输出给播放设备的驱动程序进行播放。

Claims (10)

1、一种多媒体引擎的实现方法，其特征在于，

用户在人机交互接口MMI上选择开始，总控模块接收到MMI发送的开始通知后，向源元件、编解码通用元件和接受元件发送开始命令，启动所述源元件、编解码通用元件和接受元件；

源元件接收到开始命令后，读取数据，将所读取的数据发送给编解码通用元件；

编解码通用元件接收到源元件发送的数据后，对所述数据进行编码或解码，并发送给接受元件；

接受元件将接收到的完成解码的数据发送给相应播放设备进行播放；将完成编码的数据发送给存储设备进行保存。

2、如权利要求1所述的方法，其特征在于，所述源元件、编解码通用元件和接受元件通过衬垫进行链接，实现数据的传输。

3、如权利要求2所述的方法，其特征在于，所述总控模块通过将相互链接的所述源元件、编解码通用元件和接受元件加入到一管道中对所述源元件、编解码通用元件和接受元件进行控制，所述总控模块将所述开始命令发送给管道，通过管道向所述源元件、编解码通用元件和接受元件下发开始命令。

4、如权利要求3所述的方法，其特征在于，所述总控模块中开辟有多媒体管理数据区MMC，所述总控模块通过在所述MMC中创建任务，将所述任务对应的管道的标识加入到所述MMC的管道链表中，对管道进行控制。

5、如权利要求1所述的方法，其特征在于，所述用户在选择开始之前，还在MMI上选择编解码类型，MMI将用户选择的所述编解码类型通知总控模块，所述总控模块根据编解码类型从一编解码库中查找对应的编解码插件，将所查找到的编解码插件加载到所述编解码通用元件中，使编解码通用元件能够对数据进行编码或解码。

6、如权利要求1所述的方法，其特征在于，所述用户在选择开始之前，还在MMI上选择所述数据，MMI将用户选择的所述数据的读取路径通知总控模块，所述总控模块将所述数据的读取路径通知所述源元件，所述源元件根据所述数据的读取路径读取数据。

7、如权利要求6所述的方法，其特征在于，所述总控模块还根据所述数据的数据类型，从一编解码库中查找该数据类型对应的编解码插件，并将查找到的编解码插件加载到所述编解码通用元件中，使编解码通用元件能够对数据进行编码或解码。

8、如权利要求6所述的方法，其特征在于，当播放数据时，所述用户在选择所述数据的同时还设置播放参数，MMI将所述播放参数通知总控模块，所述总控模块根据所述播放参数设置所述接收元件的参数，所述接受元件将接收到的完成解码的数据发送给相应播放设备的同时，发送其播放参数，控制播放设备对完成解码的数据的播放。

9、如权利要求1所述的方法，其特征在于，所述总控模块向源元件、编解码通用元件和接受元件发送开始命令后，为所述源元件、编解码通用元件和接受元件创建线程，在该线程中实现所述源元件读取数据，所述编解码通用元件对所述数据进行编码或解码，所述接受元件将完成解码的数据发送给相应播放设备进行播放；将完成编码的数据发送给存储设备进行保存。

10、如权利要求1所述的方法，其特征在于，当所述数据为音频文件时，所述源元件为文件源元件，所述编解码通用元件为音频解码元件，所述接受元件为音频接受元件。

Images