XDM isn't the easiest interface to work with. There are complex buffer descriptors (with arrays of single buffer descriptors!), resizable structures, structs that are read-only/write-only, depending on whether you're an application or an algorithm/codec, and lots of ways to make mistakes, both on the app side and on the codec side. We try to catch usage errors and return meaningful errors when we can find them, but the cost of checking all possible error scenarios is too high, especially within a time-critical API, like decoding a video frame, so we can't do these checks all the time.
However, to help catch some of the common mistakes - from both applications and algorithms, we introduced a feature in late 2008 (with the CE 2.20 release) called "CE_CHECK". You can read many of the details about it at the CE_CHECK article on the TI wiki. In short, at the cost of some performance, it does some of these usage and semantics sanity checks within the Codec Engine VISA APIs.
Read-only structure Example
As an example, during a VISA process() API call, the application must provide an input struct - InArgs. This InArgs struct is read-only to the algorithm, and as a result, the algorithm must not modify it. When Codec Engine runs with the CE_CHECK environment variable set, it will internally make a backup copy of the InArgs struct before it calls the algorithm's process() call. When the alg returns from process(), CE will compare the backup copy of InArgs against the post-process() InArgs and check whether the alg modified that struct. If the contents are different, the alg violated the XDM spec(!), and CE will report that through it's trace output. If it's your alg, you should fix it, if it's a purchased alg/codec, you should file a bug (please!!!).
Performance
You don't want to enable this all the time, as it may impact performance, but it's easy enough to turn on during development, and can help catch some of the more subtle XDM spec violations, making your apps and/or algorithms more robust.
What subtle XDM issues have bitten you? Leave 'em in the comment section below, and maybe you'll find we can detect and flag them in future CE_CHECK-enabled builds!
