NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on The site is now set to read only.

When to use and when not to use Codec Engine

From Texas Instruments Wiki
Jump to: navigation, search


Codec Engine is the mainstay of the DVSDK program for the various DM and OMAP devices. It is a very powerful framework that enables applications to easily instantiate and to work with XDAIS algorithms using a common API. The API is the same for all of the following situations:

  • Algorithms may run locally (on the GPP) or remotely (on the DSP or Coprocessor).
  • The system may be a GPP+DSP, DSP-only, GPP+Coprocessor, or GPP-only system.

Application code (or middleware it uses) calls the Codec Engine APIs. Within the Codec Engine, the VISA APIs can be used to access the core engine and the actual codecs, which may be local (run on the same processor as the application) or remote (run on a different processor from the application processor).

However not every situation calls for Codec Engine. In this article we present a series of use-cases and recommend whether Codec Engine is a good fit or not. Where it is not we highlight the alternative options.

Note that below, references to the "Link" product mean either the older "DSP Link" or newer "SysLink" - both have similar features. In some cases, the availability of those Link releases depends on the device you're considering.


When to use and When not to use Codec Engine?
Use CodecEng?
A/V System w/XDAIS algs?
DSP drivers, closed system?
No. Consider Link + custom processing
DSP drivers, open system w/XDAIS algs?
No. Consider Link + Framework Components
XDAIS algs, adding custom alg(s)?
Yes, use IUNIVERSAL for custom algorithms
Migrating between SoC and single-core platforms?
Yes, CodecEng uses same APIs regardless of DSP, GPP+DSP, GPP-only.

As the use-cases below indicate some clear themes emerge: -

  • N XDAIS Algorithms - any system dominated by XDAIS algorithms should leverage Codec Engine since it will handle the resource & memory management nicely.
  • DSP-side I/O - if you want to do I/O on the DSP e.g. OMAPL13x platforms then Codec Engine is likely not the best path. This topic demonstrates the Codec Engine overhead of performing the round-trip Arm<->DSP path - although it is minimal (just message passing) GPP OS context switch time issues arise. Hence e.g. OMAPL13x based audio systems often want to leverage the DSP-side drivers thus eliminating remote Codec Engine.
  • Migration - if you know you'll move from e.g. DM6446 to OMAP353x and want to preserve the same application code then Codec Engine is useful since it uses the same APIs regardless of DSP, GPP+DSP, GPP-only systems. And it also preserved API compatibility on both DSPLink and SysLink-based environments.

Use-case 1 : I'm using DVSDK 2.0 on DM6446 - I want to add another audio algorithm

Perfect fit for Codec Engine. DVSDK 2.0 already ships with a bunch of Video, Audio, Speech algorithms which implement the TI standard VISA interfaces.

Let's say you want to add MP3 decode to your system. This article provides step by step instructions on how to do so. It is fairly straightforward.

In summary the system you are using is Codec Engine based, has a bunch of existing XDAIS/XDM/VISA algorithms already. It makes perfect sense to leverage that infrastructure to correctly share resources and build up the system.

Use-case 2 : I'm using OMAP35x - I'm not using DVSDK - I want to add a bar-code scanner algorithm on the DSP

Ask yourself the following questions...

  1. Q. Is the bar-code scanner from a 3rd Party and already packaged as a XDAIS algorithm?
  2. Q. If #1 = TRUE, then is it wrapped into an existing interface e.g. IIMGDEC1 for imaging?
  3. Q. Do you plan on adding any other 3P algorithms at a later date?

If #2 and #3 are TRUE then you should use Codec Engine. The system will scale better with the addition of new algorithms. Memory management, resource allocation will be handled seamlessly via configuration settings. In this case Porting_GPP_code_to_DSP_and_Codec_Engine should help a great deal.

If #1 - #3 are FALSE and you're in a situation where you simply want to offload some processing to the DSP to be accelerated then it may be simpler to just use Link, and then add some basic MSGQ messages to signal processing and control events to your custom algorithm on the DSP-side. With 1 algorithm you don't care about resource sharing, memory management - you have the whole DSP to yourself. Basically if you (the customer) control all the content on the DSP-side and are not receiving TI/3rd-party XDAIS/XDM codecs then it makes sense to look at a simpler architecture. Examples / starterware for this are presented at the bottom.

Use-case 3 : I'm on OMAP-L138 - I want to build my own DSP-side application(s)

You're building an industrial application - you need low latency I/O drivers and processing. You have custom DSP processing. All you need is some "control commands" from the Arm-side to influence the DSP processing.

Here it makes sense to stick with basic Link Messaging (MSGQ/MessageQ) and then have your own DSP-application. Link will load the code and the DSP-application will run. There is little value in Codec Engine in this scenario.

Use-case 4 : I'm on DM6446 but I plan to migrate to DM365 later - I want to keep the same APIs

You're creating an audio/video application with AAC, H.264, and MPEG4 support - you're currently using DM6446 but later plan to migrate to DM365. In this case Codec Engine is a perfect fit due to: -

  • The Arm-side application won't change. Arm-side API calls will be exactly the same on the Arm+DSP (dm6446) system .v. the Arm+coprocessors (dm365) solution. You on
  • you are using several XDAIS/XDM algorithms.

Codec Engine is exactly the right fit here because CE has: -

  • the same APIs regardless of whether you are on a DSP-only, Arm+Dsp, or Arm-only system.
  • resource management services (via Framework Components) to share memory, DMA, coprocessors effectively.

Use-case 5 : I have an audio/video system - I want to add another non-VISA codec

BitBlit for c64+ accelerated 2D blitting graphics is a good example of this. i.e. you have an audio/video system but want to e.g. blit subtitle / rolling-text banners over the video window or you want to blit different icons over the top-right corner of the video.

In this case you should use Codec-Engine and make the new algorithm "fit with the Codec Engine infrastructure". This involves taking the algorithm thru several steps such as XDAIS (compliance) -> XDM -> IUNIVERSAL -> add the codec to existing Codec-Combo. There are several step by step docs available to guide you thru this: -

Examples / Starterware for Link-based use-cases

More of these will follow. Here is the current known list of examples / starterware: -