A common misunderstanding is that 'Codec Engine' is only applicable for codecs - it's not. Given the product name, it's not an unreasonable assumption, but it's still technically incorrect. Codec Engine is a misnomer - a better name might be "XDAIS Algorithm Engine", but it doesn't quite roll of the tongue so nicely.
Codec Engine can run arbitrary XDAIS algorithms. Again, Codec Engine can run arbitrary XDAIS algorithms. So why did we call it "Codec Engine"? I'll blame marketing - though I was in the meetings wearing a marketing hat when we decided, so I'm to blame, too. Other names considered were "CAPI (Codec API)", "Algorithm Engine", and later I've considered "Algorithm & Codec Engine (ACE)". Nothing worth the headache of updating the docs/code/etc. and re-educating everyone, so "Codec Engine" it stays. But at the cost of having to clarify the name with posts like this. :/
There are a few techniques for running non-codecs in "Codec Engine" that I'd like to highlight.
Extended Interfaces
Ever since the initial Codec Engine 1.02 release way back in 2006, we have provided a 'scale' example which demonstrated how to run a non-XDM yet XDAIS-compliant algorithm. You can still find it in the examples/ti/sdo/ce/examples/codecs/scale and .../examples/extensions/scale directories. The Codec Engine Algorithm Creator Developers Guide also documents how any XDAIS-compliant algorithm - like this scale example - can be integrated into Codec Engine. It involves writing an extension package (see examples/ti/sdo/ce/examples/extensions/scale) and - if remote support is required - appropriate stubs and skeletons to pack and unpack the arguments as they cross processor boundaries. Also, address translation and cache management must be handled.
It's not as easy as integrating an XDM compliant algorithm, since CE's VISA classes already handle these details for XDM algorithms, so very few users have taken this route. But it's nevertheless a fundamental feature of the CE architecture. And it's how we continue to add support for new XDM interfaces, like IVIDANALYTICS and IVIDTRANSCODE... they're "just a new extension" that we happen to distribute with the Codec Engine product.
Write a Codec Adaptor
Another technique that works for some algorithms that are "close" to a codec is to just wrap the alg in one of the XDM interfaces. There's an app note on this technique here.
IUNIVERSAL
In XDAIS 6.20 (mid 2008) we added the IUNIVERSAL interface (ti/xdais/dm/iuniversal.h). This interface is [intentionally] incomplete, yet flexible enough that most non-XDM XDAIS-compliant algorithms could be adapted to it. The real value of implementing the IUNIVERSAL interface is that it's natively supported by Codec Engine's UNIVERSAL API, and implicitly supports executing the algorithms remotely. Many users have found the IUNIVERSAL interface attractive for integrating their non-codec algorithms into CE.
The Getting Started with IUNIVERSAL article is a good place to learn more. Also, when you're ready to create your algorithm, consider using the GenCodecPkg wizard (yes, given the context of this article, we probably should have called it the GenAlgorithmPkg wizard). :P
I hope this helps clarify this fundamental feature of Codec Engine, as well as show some options available for integrating any XDAIS algorithm into CE.
Chris
