The Universal Codec Interface (UCI)

Philosophy

The Universal Codec Interface Project's primary goal is to create a portable, consistent set of APIs and corresponding interface library to allow all manner of applications to use the widest possible variety of multimedia codecs on unix-like operating systems (and other platforms).

Additionally, the UCI project has come to have a secondary goal of providing a cross-platform API for interfacing with codecs on a wide variety of platforms (both unix-like and non), to facilitate highly portable multimedia applications and libraries.

The UCI system is intended to provide an interface which is both consistent enough to allow easy ("plug and play") use of any codec by any application, while being flexible enough to allow sophisticated use of specialized codec features by applications designed to take more thorough advantage of certain codec implementations, or even to allow the user to control codec features of which the application itself may not be directly aware.

The codec interface is designed to allow easy addition and removal of codecs without recompilation of the library or applications using it, and support third-party codec development and distribution, to allow applications to easily and automatically take advantage of the newest codec technology available, and allow any given codec to be immediately usable with a wide variety of applications and systems.

This system is not intended to address recording or playback of multimedia data on specific hardware (sending decoded audio/video to the screen or speakers, or capturing from a sound card or video capture device, for example), filtering, editing, or any other ways that the data might actually be used. This is outside the scope of the UCI project and its APIs (and thus up to the application or other libraries to implement as appropriate). Support for performance-enhancing codec-related features such as interfaces for allowing codecs to directly interact with certain types of hardware may be supported if doing so through this library provides benefits which cannot be otherwise achieved at the application layer.

Project Status

Following is a brief summary of the various aspects of project development, and where each one stands:

Stage

Status

Notes

Set up SourceForge Project

Completed

There are still a couple of odds and ends to deal with (like actually taking advantage of all the bells and whistles that SourceForge provides) but this is basically done. The main project page has also been moved to uci.sourceforge.net.

The basics of a CPI spec have been put together and are in the process of being documented. These are, of course, subject to change given input from the greater multimedia community.

Develop Basic Application Interface Specification

Nearly Done

The basics of an API spec have also been put together (although the state of documentation is not yet as good as the CPI spec, and they are somewhat more subject to change as development of the actual library progresses).

Solicit Feedback from the Multimedia Community

In Progress

(ongoing) We're starting to focus more on trying to get more outside developers involved with this project to give input on overall design and implementation. A Sourceforge project has been set up to help with this, a public maillist is now up, and an IRC channel has been created. If you wish to contribute or know of others who we should contact, please join the maillist or let us know directly.

Make interface library

In Progress

Work on the interface library is progressing, and some preliminary code is now in CVS. Nothing is really ready for use by anybody other than the project developers yet, but things are coming along nicely. Stay tuned for actual releases in the Downloads section when we have something useful for others.

Documentation for Specifications and Library Use

In Progress

Documentation for the CPI spec is progressing reasonably well. API spec docs are not quite as far along but are progressing. We will probably be holding off more general "usage" documentation until the library itself is in a more finished state.

Make "Codec Development Kit"

Nearly Done

This is an almost automatic side-effect of the documentation of the CPI. All that really needs to be done at this point is to clean up some of the header files and put together a couple of example codec modules and bundle them up into a "kit".

Verify/Improve Portability

Not Started

(this will begin after the basic codebase is established and working reasonably well on initial platform(s). Should not require much work if we do things right in the first place.)

Assist Codec Developers to make Compatible Codec Interfaces

Not Started

(need to wait until the library is more complete so people have something to test against)

Assist Application Developers to make Compatible Applications

Not Started

(need to wait until the library is more complete so people have something to test against)

Docs and Specifications

The current state of the specification documentation can be found here:

At this stage this information is being written primarily for the benefit of those not familiar with this project to get a quick jump-start on the direction we are going and basic concepts and planned implementations, so they can jump quickly into the development discussions. We're still working on parts of these documents, and there are some aspects to the specifications which have not yet been spelled out in the documentation, so please be patient, and feel free to ask questions on the maillist if there is anything for which you want more information than is currently supplied here.

If you are considering writing an application or codec to the UCI specifications, you are strongly encouraged to join the UCI-Devel maillist, to keep abreast of changes to the specifications, as well as participate in the evolution of the system to make sure it fully meets your own needs. We are interested in everyone's input, to make sure UCI is useful for everyone.

Downloads

(none yet, but we hope to have some preliminary stuff very soon now)

Mailing Lists and Other Contacts

The following public maillists are currently available. Please subscribe and join in if you'd like to give input or help with this project!

UCI-Devel - For discussiong the development of UCI specifications, documentation, and the support libraries, sample code, etc.

For those who wish to monitor/access the maillist via other means, web-accessible archives of the list can be found on SourceForge and on gmane.org. The GMANE site also offers an NNTP gateway to access the maillist via newsreaders, for those who prefer this method.

The UCI project now has an IRC channel set up on FreeNode (previously OpenProjects.net). Connect to one of the FreeNode servers with your favorite IRC client, /join #uci, and jump in!

You can also contact the UCI project maintainer (Alex Stewart) directly at uci@foogod.com.

SourceForge Project Page

FAQ

The following are a few valid questions which have been asked in relation to this project which bear addressing:

Why not just use Gstreamer?

Gstreamer (http://gstreamer.net/) is an extremely powerful application and framework, which appears to be very well designed for what it's intended to do, and supports much of the same interface flexibility that this project is aiming towards, however it does have some drawbacks when considered as a general purpose codec-interface library for some types of applications:

It is a much more wide-ranging and complex framework, supporting many more functions than simple codec interfacing (such as filtering, editing, and even display of multimedia content). While some might argue that this is a good thing (and it is for many applications), it also means that applications which do not need all these features are stuck with using a system which is quite a bit larger and more sophisticated than they really want. Part of the goal of this library is to be lightweight and simple enough to not encumber any application with any code it doesn't need to work with.

It does not appear to offer the same level of "plug and go" functionality for various codecs as UCI is designed to provide, as interface code for each codec must generally be written by Gstreamer programmers or third parties, rather than having new codecs immediately available. UCI is intended to provide a generic API which codec authors can write to to make adoption and use of new/changed codecs automatic and instantaneous.

The UCI project also has somewhat greater cross-platform focus, including possible use on non-unix-like operating systems such as Windows or OpenBeOS, to facilitate widely cross-platform multimedia applications. This is something that the Gstreamer project does not (yet) really support (although it may in future).

Ultimately, it is hoped that Gstreamer and UCI will be complementary, and would work together to provide improved functionality and flexibility all round. Whether this is feasable/appropriate is currently under discussion with various Gstreamer folks, so stay tuned..

How Does UCI Relate to Transors (and MCF)?

"Transors" is a preliminary codec-interface specification which has been put together by the folks working on the MCF specification. UCI was initially developed independently, before either team was aware of the other's existence. After some discussion with the MCF folks, we are currently planning to merge the work done to date on Transors into the UCI project, including looking more towards cross-platform compatibility with non-unix systems. The MCF folks are currently considering whether they want to drop Transors in support of UCI instead (another possibility would be to make Transors a thin wrapper on top of UCI on platforms which support UCI).

The MCF folks have been very supportive of this project, and however things work out we look forward to working with them to make UCI and MCF both work well with each other and become a formidable multimedia combination.