Is OpenMAX DL dead ?

Hello everyone,

I am looking for audio/video codecs or any other piece of software (open source or commercial) implemented on top of OpenMAX DL… and I cannot find any !
Apart from specs and implementations from ARM (a C version and an ARM assembly optimized version with
NEON support), it looks like nobody cares about DL.

A few OpenMAX IL implementations are available, but they do not seem to rely on the DL layer.
Bellagio, for instance, uses ffmpeg.

So… is OpenMAX DL a failure ? Where are codecs using DL ?
Please, feel free to prove me wrong !


Hi Ivan,

No, OpenMAX DL isn’t dead, and the three versions (C, ARM11, Neon) of the library that ARM have produced are downloaded frequently (>2000 times in total).

It is a bit sad that AFAIK no other company generated an OpenMAX DL implementation for another architecture apart from ARM’s (the whole point was that it should make porting from one architecture to another easier - whereas at the moment it only helps from one ARM architecture to another - unless you’re willing to use the C sample/reference version which isn’t designed to be fast), however given that most of the major contributors to the standard were ARM licensees then it’s fairly obvious that they’d all be happy with ARM’s implementation (and happy they didn’t have to code it - it was a big job!).

The only competing architecture left is x86, and I believe the Intel Performance Primitives are very similar, so the porting should be quite easy from OpenMAX DL -> IPP in many cases.

However, the OpenMAX DL working group is on hold as there have been no proposals for extra functionality to be added.

As far as which codecs use DL, I only know of a few, but the problem with DL is that there is no reason for a codec vendor to advertise that their implementation is DL compliant (and plenty why they wouldn’t - competitive advantage, not advertising it wasn’t invented here, etc). Yes, they need to say if their codec is IL compliant - as this is the interface the customer uses to access the codec. But DL is just a linked in part of their binary. Some people use the DL code as is, some people just copy bits from it. Obviously we’d prefer them to use the DL API as when we produce future architectures we can just offer a new drop-in library, but if the DL code base shows people how to use features like Neon more efficiently then we’re happy for people to use bits of the code.

Also most of the DL functions are not designed to be part of a codec - there are a lot of signal and image processing functions that can be used in a lot of ways - I think the FFT implementations are particularly popular.