Khronos releases OpenMAX IL 1.2 as a provisional spec

The Khronos Group yesterday announced the public release of the new version of the OpenMAX IL specification (version 1.2.0), the open standard, cross-platform, C-language based API for multimedia hardware acceleration.

The OpenMAX Working Group was created by Khronos in 2004, with three sub-groups, OpenMAX AL (Application Layer), OpenMAX IL (Integration Layer), and OpenMAX DL (Development Layer). OpenMAX IL sits architecturally in the middle of the OpenMAX stack. Although complementary, these three APIs have been arquitected to be independent of each other, so that they can live in a system without any of its siblings.

Until yesterday, the latest and greatest version of the OpenMAX IL specification was 1.1.2, which was released in September 2008.

The OpenMAX IL standard is well known amongst the Multimedia software community as a lengthy, cumbersome API. This new specification is an attempt by the Khronos OpenMAX IL Working Group to address some of the shortcomings and issues reported by implementers during the past few years.

From an architectural point of view, the new release does an attempt to break as little as possible with the past, to avoid giving OpenMAX IL developers additional headaches. However, this won’t necessarily be the case for every IL implementation out there, as there are still enough relevant changes in this new version of the spec to keep entertained those developers with responsibilities in existing implementations. However, in my opinion, it is all for good.

Without going into the detail, I would highlight the following changes as the most relevant in my view:

  • Those changes related to the “buffer pre-announcement feature” in IL.
    • This is something that has traditionally caused troubles to IL Client developers and integrators of OpenMAX IL components in multimedia frameworks. The issue here has typically been the difficulties of reusing framework-allocated buffers inside IL. The new version of the spec relaxes some of the limitations in this area while still maintaining the “old ways”, in case someone is concerned about backwards compatibility.
  • The various updates to the IL state machine.
    • The IL state machine has been criticized in many occasions due its size and complexity. The IL state machine hosts a large number of states (6 in total) and the reality is that it is difficult to find many implementations that support all of them. But more importantly, problems in the state machine (or alternatively, in the language that described it) have been identified in the past, especially in scenarios with tunneled components. These problems have the potential to cause a number of issues that are collectively known as the “IL race conditions”.
    • In general, the IL state machine has been improved in this new spec by rewriting the sections that dealt with the state transitions and the conditions that triggered them, the removal of the “OMX_StateInvalid”  state, and the addition of a number of conditions to achieve “command cancellation“, which is something that wasn’t possible in previous versions of the IL spec.

But what it is really important here in my opinion, is that Khronos has published this new spec as provisional, and has setup a public forum for developers to discuss and/or provide feedback. To my knowledge, this is the first time that Khronos has done something similar with a specification. This is in my opinion a great initiative which has the potential to make the final spec a better one by opening the discussion to a wider community of developers.

From a personal point of view, I’m very happy to see that this new spec is finally out, as I had the great honor of collaborating with the Khronos IL WG between 2008 and 2011, during the time I worked for Symbian and Nokia. All in all, I can only say big kudos to the IL WG!

You can read more about the new specification and its improved capabilities in the Khronos  press release.