Transor introduction

What is a Transor ? A Transor is a plugin that can encode or decode (or both) one or more format to be placed in a container.

The primary goal is to use Transors as plugins for the MCF framework. The framework works like this :

In this example the Transors are the elipse at the bottom of the graph. Each of them represent a supported format.

A Transor is characterised by a few things:

• The format strings it supports. Each format string represent a format either proprietary or open (like XviD, MP3, WMA, etc). For each format string you have :
  • Wether it can encode the format
  • Wether it can decode the format
  • The structure of the extra data needed by the format (used to initialise decoding)

Work in progess

You can check the progress of the Transor API (also named CodecFactory) here in the form of a C++ header file.

How does Transors work ?

The Transor API uses the C calling convention on each supported OS. This API is the same for all container implementation (being in C, C++, Java, etc) and all OS. So that working with Transors is made very easy for all developpers.

The first basic service that a Transor provides is giving the number of format strings it support, a user friendly string for each format and if it can encode or decode to that format.

Transors to encode

to do

Transors to decode

to do

Using Transors

Transors are platform dependant. That means the linking will be platform dependant. Transors should also be used not only by libmcf but also by other applications that want to deal with codec and/or MCF.

We can try to have the platform distinctive part as small as possible. On Windows the transors should be in the form of a DLL and on UNIX as a shared object (dunno how these things work on Mac).

We also have to make sure that many applications can use the same transors and also different versions of the same transor. On UNIX we can have these transors installed in a /usr/lib type directory and have different names for each version (mpa.so.0.1.0 and mpa.so.0.2.1 for ex). On Windows a similar system could be used for naming transors. So we need a way to distinguish 2 transors dealing with the same format string(s) with a version number and "copyright" information. Actually as many transors can be installed for the same Format String, we need a way to automatically choose the most appropriate one. We need a priority system (like the one on Windows) between all the transors, and the transors for the same Format String (a transor dealing with 2 Format String would have a priority for each one). This priority system can be global to all libmcf using apps, but also local to a libmcf using app, and global/local to other Transor-compliant apps. The most simple way is a text file (XML format of course, ie can be parsed easily on all platforms) in the same dir where the transors are saved, or in a usual path to save configuration data (/etc/ on UNIX, Profiles on Windows ?). Each time a transor is added to this directory, it must be processed to be added to that file and prioritised. The global configuration could be transors.global.xml. And each application that wants it own parameters could use transors.[app name].[app version].xml. In the case of a libmcf host, it should be transors.libmcf.v010.[app name].[app version].xml

Format of the XML transors list file

The informations we need about a transor:

• The file path
• The name
• The version
• The list of input format strings it support, the kind of format each string is (audio, video, etc) (most of these info come from a call to the transor)
  • An output format string it supports
    • The version
    • The priority
    • The speed rank
    • Wether it handles decoding
      • What are the supported output formats (using Format Strings ?)
    • Wether it handles encoding
      • What are the supported input formats (using Format Strings ?)
    • Wether it handles statistics
    • Wether it handles framing (raw data feeding/reading)
    • Wether it handles seeking or not

Communicating with Transors

Transors are dynamically loadable libraries (DLL on Win32, Shared Object on UNIX, whatever on other platforms). So the calling convention is platform dependant but language independant. This is a linear, non object oriented calling method (no Corba, DCOM, etc). So it will be better for portability, simplicity and coding. The usual case is the Transor-compliant application (libmcf for example) load the Transor in memory. It then call some functions (with a specific name) with parameters in the stack, and when the Transor has finished processing, it returns an "error" code (return code). As the Transor-compliant application may call for statistics while encoding or decoding, the Transor should to be thread safe.

Care should be taken that fewer memory copies are done during the processing of data coming/going to Transors. Like for network processing, encoded or raw data should never be copied until the coding/decoding process occurs (inside the Transor).

For statistics, information about the Transor and configuration, we have mostly 3 choices :

• asking for parameters in structures, and these structures are fixed size. Not very flexible/efficient for the evolution of the API and backward compatibility.

• asking for parameters "in tree", ex : toto = ask_parm("configuration"); titi = ask_param_next(toto); tata = ask_param(titi); etc...

  It isn't very efficient as it requires many calls. But at least it's more flexible than a structure oriented API.

• XML comunication. The Transor-compliant application (TCA) asks for a buffer with either : configuration data, information or statistics. And the Transor return the data in XML form. On the other side, when the TCA wants to configure the Transor, it just send a buffer with XML configuration data. It is very flexible, efficient in terms of calls, etc. You can also have these data used for configuration directly in text mode (used in a scripting app). The major drawback might be that it's necessary to use a basic XML parser for reading/writing parameters which might be overkill on small Transors.

Secure content in Transors

Transors were made to have a portable API for dealing with various multimedia codecs. The current trend in the content industry (major video studios, major record labels) is to have secure content. That means the content can be played by legitimate users but not copied. That leads to 2 kinds of protection that can coexist : crypting the content for only legitimate users, and making the copy impossible.

We are actually against this concept of locking users, but as this kind of system might be necessary to play legally files in popular formats like RealMedia or Windows Media we need such a system.

Also no OS is currently protected enough to allow distribution of encrypted data. And if you can play a content (the final state being the analog rendering) you can copy it in one way or another. So all the current system rely on the trust of the rendering application. That's the system we'll use. Each decoded stream should contain a boolean value saying if the content can be copied or not. And the player should take that in account (of course, we're not responsible for any bad use). We won't support authentication for the moment.