开源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插件的形式开发成功。