利用Trimedia的TSSA组件技术进行多媒体开发(转)

利用Trimedia的TSSA组件技术进行多媒体开发

现在网上好像这方面的资料不多，而且关于philips多媒体多核处理器pnx8550的资料就更是少之又少了，今天在google当中搜索了一下，发现有一篇文章是介绍pnx8550的，打开一看，哈哈，原来是我们老大的文章。
首先说说PNX8550这个处理器吧。
1、PNX8550是一个典型的不对称多处理系统，其中的MIPS处理器支持现代意义上的多种操作系统诸如Linux, VxWorks等等，而TM3260则是经过优化的媒体处理器，包括现代的视频解码等。一般有两种观点来应对这种多核架构：
     第一种，鼓励系统设计者用运行在MIPS处理器上的OS所提供的本地化服务；
     第二种，提供已经开发成熟的IPC接口程序。
2、pnx8550中系统的架构以及处理器之间的关系
     首先，在MIPS一侧，按照个人喜好采用不同的操作系统，系统正常启动后，和媒体处理器最基本的通讯就会被执行，这个执行是与主操作系统兼容的（这些放到后面再说），另外还有一个大型的库用来控制TriMedias（许多流媒体处理的开发成果都是存在于这个库当中的，现在我们基于TriMedia的编解码控制库开发工作已经取得成功）。
     其次，在TriMedia一侧使用pSOS操作系统，并且其通常都通过OSAL即操作系统抽象层来访问；TSSA组件通常被用来构建图像滤波等；不同的也许是这种从TM到MIPS出来的API功能需要更进一步开发(这个其实也就是用来构建流媒体系统图时所应该封装的接口，因为mips并不能直接运行基于Trimedia的库)。
     最后，三个处理器协同工作的构架，对于第二个TM来说，用户一般至少有两种选择，分别是：同等处理，并且都由MIPS来驱动；另外一种是把其中一个作为master，而让MIPS只同该唯一的master对话，剩下的这个可以直接由master来控制，它们之间建立一个IPC通道，专门用来做数据的互访，具体的信号处理还是由运行在slave上面的组件库来完成。
   主题
1、什么是TSSA，为什么要有TSSA?
    TSSA组件技术无疑是philips软件架构当中最为优秀的设计之一。它的层次分明，结构清晰，便于移植和开发基于自身项目的多媒体处理。它的全称是TriMedia Streaming Software Architecture 也即：Trimedia流式软件体系结构。它使得程序员之间可以共享媒体处理组件，这种体系结构的设想在许多的工程当中已经成为了一种规范，它能够使你轻松的在一个工程里建立你自己的工作。
2、流体系结构的介绍
TSSA为组件提供了一个框架
10399
包括：普通的执行体系、标准的API、普通的数据格式。
根据TSSA规范来写组件的时候，一个应用程序可以很容易的利用来自不同设计者的一些组件。程序员不用发明一种新的内存管理方法或者执行体系，这些都有TSSA来定义。
在多媒体系统当中，大量的数据从源经过一个或者多个处理器后到达接收器，这些数据就叫做“流（streams）”，大概类似于一般意义上的码流，只不过这个“流”是经过处理后的一系列数据包以及它的属性等等。
TSSA的用户有两类：写TSSA应用程序的和写TSSA组件的。下图是一个TSSA兼容的组件应用流程：
 
尽管有许多shapes和sizes,但是它的入口点以及数据流格式的走向还是一致的并且是可预测的。
要描述一个系统的普通执行体系结构，必须要描述当系统运行时控制流的传送方式。TSSA是数据驱动的，这对于一个从输入设备而来经过某些处理器然后到某个输出设备的数据流系统来说是一个合适的解决办法。TSSA是为基于软件的信号处理这个需求而设计的。TSSA系统是多线程的，运行在他自己线程上的TSSA组件被称为激活的组件。控制权在基于优先级的激活组件中间传递。当激活组件请求数据的时候它会放弃控制权，直到数据可用时被唤醒（这个过程是基于pSOS多任务调度的，每个任务可以设定优先级，系统根据优先级仲裁来决定当前的时间片该执行什么样的任务）
用于激活组件的线程可以是本地操作系统的任务或中断服务程序。应用程序的设计者选择基于任务的组件的优先级，在这个问题上有两个指导方针：第一就是单一等级规则，是说优先级是和组件在任务当中使用的频率成比例的，使用频率越高，等级越高；第二是V规则，这是说越靠近硬件的组件优先级越高。一般会设定一些优先级的边界，比如说基于软件信号处理组件的优先级在0—63之间，如果超过这个区间，就表示越界，是不允许的，因为对于这一区间的任务，是有对应的调度策略的。
数据以包的形式在活动组件之间传送，就会用到连接组件。这个实现是要依赖于操作系统的，这样的话基于任务的活动组件就会在没有数据需要处理的时候阻止或者放弃控制权。一个例子就是in-out组件，这个组件在接收到操作系统任务调度后发来的semaphore时，自动激活，进行数据包的copy或者delete操作等等。
应用程序希望在活动组件运行的时候控制它。为此TSSA有一个规定：通过线程边界来同步配置命令和他们的相应传递，这叫做控制描述符（control descriptor）。控制描述符的设计为上一层次的应用提供了非常方便的接口，从而使运行组件的灵活性得到了大大的提升。
（1）       对于写TSSA组件应用程序的这一类程序员来说，需要把握的是对数据流走向的控制，以及所使用到的各个TSSA组件之间的连接(io connection)。他们不需要对组件内部的信号处理过程有清晰的概念，但必须要知道你所使用的组件是干什么的：）否则，也许你的输入是一个压缩后的视频码流，但输出却是一块块面包屑。
（2）       对于写TSSA 组件的程序员来讲，他们需要在更高层次上明白这个组件的作用，以及将来可能需要使用到的功能接口，当然具体的信号处理是这里面的关键，比如你要对一个YUV格式的原始视频图像做一个MPEG4的编码等等。
3、TSSA 1.5：
TSSA的内部结构被分成许多小的单元也就是子组件，这给软件工程提供了一个更好的可维护性和可延展性。每个子组件都有一个定义好的接口，这个接口有完全指定的运行前后条件和一组清晰定义的与其他子组件之间的依赖关系。最为重要的levelize子组件是：tmFormat、tmPacket、tmControlDescriptor还有in-out描述符，他们每一个都有自己不透明的结构体类型和一个其上定义合法操作的API。
TSSA用统一的方法定义了一些虚拟接口，允许各种可重用的组件被写入。
一个in-out描述符的概念是由连接组件衍生而来的，该连接组件是用来实现tmviConnection虚拟接口的。缺省的数据输入输出函数 tsaDefaultDatainFunction()和tsaDefaultDataoutFunction()已经用这个新的接口完成了重写，使得创建一个新的连接组件成为可能。老术语“TSSA component”因此而变得模棱两可，过去我们说调用一个TSSA组件，现在却说调用一个“活动组件”。
作为信号处理组件，ProcessData function的概念由此产生。一个信号处理组件是用来实现tmviProcessData接口的。
新的接口tmviMem被定义为malloc()和free()函数的抽象。没有部分TSSA直接调用任何内存分配函数，通常的做法是用一个内存调用实例并且每一个实例都要被客户端支持。这就意味着客户端要完成TSSA和所有TSSA组件的整个控制。系统提供了三个这样的实例：tmCHeap（调用malloc()和free()）、tmCacheAligedHeap和tmMmlMmsp（从任何的MML内存空间获取内存）。
Common data structure：
TSSA的数据结构定义为非透明的结构体是为了从它的实现过程中减少客户端的数据结构。有一些数据结构是透明的并且由于继承的原因不能更改。
Data packets 数据包。标准的DVP数据结构在头文件tmAvFormats.h当中有声明。数据以包的形式在组件之间传递。包结构tmPacket_t像大多数其他的TSSA结构一样，是一个非透明的数据类型，这就意味着它必须被他的API寻址。尽管如此，出于兼容性的考虑，已经存在的包结构tmAvPacket_t仍然有效。
每个包都有包含一个格式指针，格式结构描述了该包当中的数据格式。同样，每个活动组件都有一个包含格式指针的功能结构，该指针枚举所有被组件支持的格式。连接组件为了兼容性检测两个组件，这个兼容性检测是通过功能结构当中的格式来实现的，从而确保流过他们的数据包有着相同的格式。这表明活动组件不用对每一个接收到的包作这样的检查---他们仅仅需要在格式改变的时候做以下检查。
格式结构体有许多成员：class（类别）、类型和子类型，但一个格式也可能包含用户定义的数据。这些都可以在tmFormat.h中找到详细的例子。
Time stamps时间标签，媒体数据流当中通常需要一个时间标签的域，这个域是数据包当中的一部分，一般都是一个64位的数。这个可以用来多向流的同步控制。
Control Descriptors控制描述符是一个双向的通道，可以被用来控制一个活动组件。
Default Setup Structures：每一个活动组件共享一组用来控制它的参数，任何参数对它来讲都是唯一的。
Active componet:
OL(Streaming) Layer：Operating system Layer.所有的活动组件都要实现下列的功能：调用OL层或者OL接口。当一个组件通过用它的OL接口时，操作系统服务通常用来启动一个该组件专用的执行线程。一个正在OL层上进行操作的组件依赖许多通用的功能需求的实现。这个可以在库tmDefaults当中发现，而且经常作为却省的设置或者称为却省库。它提供了对所有活动组件通用的工具，包括同步启动和停止线程，不同线程间的通信以及对数据包的有效处理。
OL capabilities，一个功能结构描述了一个活动组件的静态特性。却省的结构成员包括class,版本号、功能标志、资源需求以及支持和当前的实例数量。
OL Instance setup，一个实例建立结构体描述了一个单独活动组件实例的特性。它的职责是创建这样一个结构体并且赋予合理的初始化的值。通过调用tmol_GetInstanceSetup()可以得到一个指向这种结构体的指针。当这个调用发生的时候，当前的 AL instance setup设置就会被复制到OL Instance setup 结构体。
AL（signal processing）Layer：AL层的设计可以跟RTOS甚至OSAL无关。所有的调度考虑完全在AL层的外部实现。AL层最好的名字应该叫做信号处理层。他的工作完全包含了由组件完成的信号处理。但是现在还仍然沿用AL层的叫法。
这个接口有两个目的：依赖已经存在的AL接口来创建一个完整的TSSA组件；当OL接口占用太多的资源或者引进太多的潜在周期时，AL接口就会被用来在一个任务当中结合两个或多个组件。
需要注意的是将AL和OL层清楚的分开后，porting, profiling, optimizing信号处理代码的任务将非常简单。当然你也可以不用分开，不过这样的话可能会使你在调试的时候无所适从，因为你的控制和处理代码完全呆在一个函数里面，甚至有时候你都不知道是你的信号处理过程出问题了，还是控制结构出了问题。
ASP(audio signal processing) Interface: 这个组件和AL层TSSA组件非常相似。他们共享应用在所有TSSA模块当中的标准的tmal<Cpt>Open()、tmal<Cpt>Close()、tmal<Cpt>InstanceSetup()以及tmal<Cpt>InstanceConfig()等函数。但是ASP组件不是为OL层接口设计的，所以他不支持Start和Stop功能。ASP导出ProcessData函数，该函数是一个AL层组件的普通可选的，所用的数据格式也是标准的，它由声音混合器的请求来驱动产生。tsaAdpChannelBuffer_t描述了即将被处理的数据，这个缓冲结构支持循环缓冲，并且它使数据自身标准化为32位的整形数据。将一个ASP组件转换为一个AL组件是很容易的，并且通过扩展可以转换为一个OL层的组件。
Connection components:
典型的连接组件是in-out descriptor。连接组件可以分成两半，一半是source一半是sink。Source这一半被向连接起发送激活数据包的活动组件使用，sink这一半被从连接器接受数据包的活动组件使用以更进一步对数据进行处理。这两半都包含发送和接收数据包，启动和停止以及将连接器连到一个特别的活动组件的函数。
In-out descriptors: 当一个活动组件被创建时，TSSA提供了用继承的in-out描述符代码的连接接口的初始化实现。一个in-out descriptor拥有许多大小确定的缓冲区数据包，这些都是在创建的时候被定义的。这些包的数量和大小可以哟该控制在in-out descriptor当中组件的实时特性。让我们来看一下具体的实现过程。
当两个TSSA组件用一个in-out descriptor连接在一起的时候，连接器就会产生两个队列。一组数据包通过这些队列来流通。首先数据源从空队列当中创建一个包，然后将填入数据，并且放到满队列当中。然后数据接收器从满队列当中提取一个数据包，提取包中的数据之后将包返回空队列。空包返回一个信号那就是数据已经被正确地接收了并且这段内存和数据包还会被再次利用。
Cache coherency: 这些函数诸如tsaDefaultInOutDescriptorCreate(), tsaDefaultDatain()以及tsaDefaultDataout()互相协作来帮助组件维护缓存的一致性。如果发送数据的时候在内存当中产生数据，那么它将设置“无效”的状态。这个 in-out descriptor然后知道它必须使这个内存数据缓冲区无效，这些都将在数据发送到任何的接收器前进行。简单来讲，接受器可以设置一个容量如果他请求内存数据的话。
Tee connections: T型连接允许源组件有效的补充接收器组件。一个T分支可以被一个tsaDefaultInOutDescriptorCreateTee()的调用来添加