通过开源API进行DSP视频处理

数字信号处理器(DSP)具有出色的多媒体性能。一般而言，它们运行编解码器所需的周期只有通用处理器(GPP)内核的40%到50%。DSP还能提供比ASIC大得多的灵活性和可重配置性。但迄今为止，要在数字视频应用中运用DSP，编程人员还不得不花费较多时间精力去学习相关专用语言。不过，随着应用编程接口(API)的出现，已不再需要学习这些专用DSP语言了。在运行于GPP上的应用中，API可以轻轻松松地充分发挥DSP的优势。

　　开源多媒体构架在GPP上一般运行在Linux操作系统下，是这些API的理想对象。利用API可以卸载视频编解码器的计算负荷，大大减小DSP编程的复杂性。这种方案只要求编程人员具备基本的DSP知识即可，无需编写代码来整合DSP功能与那些运行在GPP上的功能。这种优势，加上利用免费开源插件和构架提供的许多功能的能力，可以大幅度缩短新视频产品的上市时间。

　　硬件平台的选择

　　在选择运行编解码器(压缩传输或存储的数字流，再解压以供查看或编辑)的硬件平台时，开发人员有几种可选方案。ASIC是专门为数字视频应用而设计的，能在这类应用中提供高性能和低功耗。它的缺点流片(NRE)费用很高。此外，ASIC若有变化，比如改动以适应编解码标准，相关实现费用非常高昂。

　　另一方面，GPP内核的流片费用相对较低，针对变动进行重编程相当容易。但由于它们在执行计算密集的信号处理应用时效率低下，故在应用于数字视频处理时性能较低。例如，GPP通过一系列移位和加法运算来实现乘法运算，而每一个移位和加法运算需要一个以上的时钟周期。

　　DSP具有集上述二者之优势的潜力。不同于GPP，DSP是为数字视频应用中计算密集的信号处理应用而优化的。它具有单周期乘法器或乘法累加单元，能够加快编解码算法的执行速度。更高性能的DSP还包含有几个可以并行操作的独立执行单元，这使得它们能够每条指令执行好几个操作。此外，DSP还提供完全的软件编程能力，包括现场重编程能力。这就让用户可以先推出MPEG-2产品，以后再升级为H.264视频编解码器。DSP在数字视频应用中的主要局限是它们通常需要采用专用语言来编程，而熟悉DSP的编程人员远没有熟悉流行的GPP架构的来得多。

　　图1：只含解码器的范例中的多媒体框架职责和数据流程

　　组件集成的挑战

　　数字视频系统的开发人员还面临着集成的挑战。数字视频系统包含了多个编码器、解码器、编解码器、多种算法及其它软件，这些组件都必须集成到一个可执行映象(image)中，然后才能在系统上运行内容。集成所有这些组件并确保其运行协调是一件很困难的任务。不同的系统可能需要截然不同的视频、图像、语音、音频和其他多媒体模块。手工集成每一个软件模块或算法的开发人员就被增值功能性(比如增加创新性功能)搞得头痛不已。

　　许多数字视频开发人员都开始采取开源途径来构建软件。一种常用的方案是从开源获得软件的重要部分，而在可用性和硬件集成方面充分发挥内部专业能力。开发人员常常参与开源技术开发项目，以满足特定要求并把内部开发的代码和开源代码集成在一起来创建新产品。

　　新的API

　　为了解决上述问题，德州仪器(TI)开发出了一款API，该产品能够充分发挥开源多媒体框架中的GStreamer等DSP的优势。这款API使多媒体编程人员可以利用熟悉环境中的DSP编解码引擎，把数字视频编程人员从复杂的DSP编程中解放出来，让ARM/Linux开发人员得以轻松利用DSP编解码器的加速功能，无需具备相关硬件知识。该接口还能自动高效地在ARM和DSP间进行工作划分，从而不再需要为运行在DSP上和运行在GPP内核上的功能间的协调而编写代码。该接口已由TI按照开源社群标准以GStreamer插件的形式开发成功。

　　图2：GStreamer内数据通过GstBuffer结构进行表征的方法与其它几种操作系统及其相应多媒体框架所采取的方法相一致。

　　GStreamer是一种媒体处理库，提供了某种转换过程的抽象模型，其通过管道的概念进行工作，媒体在其中按照已定义的方向从输入流到输出。GStreamer能够以一种简化编程过程的方式来提取不同媒体的操作行为，在数字视频编程社群中广受欢迎。通过GStreamer，能够编写出一种能够支持多种不同格式和网络的通用视频或音乐播放器。而且大部分操作由插件执行，并非GStreamer内核。GStreamer的基本功能性主要与注册和加载插件有关，并可提供基类，这些基类定义了GStreamer类的基本功能。

　　GStreamer过滤器

　　源过滤器负责从从数据源获取原始的多媒体数据以供处理，这里的数据源可以是硬盘文件(比如文件源过滤器)，或CD或DVD光盘，也可以是电视接收卡或网络这种“实时”源。某些源过滤器只是简单地把原始数据传递到剖析器(parser)或分离过滤器(splitter filter)，同时其它源过滤器也执行自己的剖析步骤。变换过滤器 (Transform filter)接收原始数据或部分经过处理的数据，进一步处理后再传递到下一级过滤器。

　　变换过滤器有多种类型，剖析器即是一例。这种过滤器把原始字节流分离为多个样本或帧、压缩器或解压缩器，以及格式转换器。呈现过滤器(Renderer filter)一般接收完全处理过的数据，并在系统显示器上或通过扬声器或某些外部设备进行播放。这一类过滤器还包括“file writer (文件创建器)”过滤器和网络传输过滤器，前者可以把数据保存到硬盘或其它持久稳固的存储设备上。

　　数据处理在plug-in_chain() 或 plug-in_loop()函数中进行。该函数可能像元件缩放那么简单，也可能像真实的MP3解码器那么复杂。数据被处理后，利用一个gst_pad_push()函数从GStreamer元件(element)的源衬垫(pad)发送出去，由此把数据传递到管道链的下一个元件。

　　GStreamer缓冲器

　　在GStreamer中，缓冲器是数据传输的基本单元。GstBuffer(实例)类提供了把一个存储区定义为流媒体的一部分所必需的全部状态。经由GstBuffer结构，Gstreame内部的数据表示遵循几种其它操作系统及其各自的多媒体构架所采用的方法(比如，Microsoft DirectShow中的媒体采样概念)。此外，还支持次级缓冲器，允许缓冲器的一小部分成为它自己的缓冲器，利用这种处理机制确保了存储空间不会过早释放。

　　图3：复用已分配在驱动器上且在物理上是连续的缓冲的一种有效途径。

　　缓冲器通常利用gst_buffer_new()来创建。创建好一个缓冲器之后，一般是为它分配存储器，设置缓冲器数据的大小。下面给出了一个缓冲器创建的例子，该缓冲器能够保存具有给定宽度、高度和每像素位的视频帧。 [p] 缓冲器创建

　　基于DaVinci技术的DM644x器件上ARM926的MMU(存储器管理单元)具有虚拟/物理寻址能力。然而，C64x+DSP内核只能够处理物理地址。因此，用于DSP处理的输入和输出缓冲器必须驻存在物理上连续的存储器中。

　　虚拟到物理地址的转换由编解码引擎处理。通过复用(指针指向)某些由驱动器分配的缓冲器，可获得物理上连续的存储器，这里使用了Linux中的一些技术，比如dma_alloc_coherent()，来在内核空间中分配这类存储器。由TI开发的库/内核模块CMEM，允许从用户空间应用来分配物理上连续的存储器。

　　例如，我们利用前面提到的CMEM驱动器来分配物理上连续的“输出”缓冲器。编解码引擎对帧进行解码，并把解码后的帧放在输出缓冲器中。

　　接下来，指向输出缓冲器的指针被传递给fbvideosink(通过 GstBuffer)。这个videosink必须把解码后的数据memcpy(复制)到帧缓存中，然后才能显示。由于memcpy操作是一种成本很高的GPP使用，这种方法使得ARM 和DDR接口的负载很重，因而增加了功耗，且效率极低。

　　这种技术对非常小的缓冲器是可行的，但在开发人员使用D1(和更高)大小的缓冲器时，将开始降低系统性能。一种更有效的方案是复用已经驱动器分配了的物理连续缓冲器，并在编解码器引擎和videosink插件之间把指向这些缓冲器的指针来回传递。