This is the master class of Reggae. It estabilishes basic methods and attributes. It also performs Reggae initialization when opened the first time after boot. All other classes are subclasses of multimedia.class. This class is also responsible for data formats detection and automatic building of decoding tree. It also provides secondary functionality like event logging, metadata support, AltiVec friendly memory allocations and more. Because of all these features multimedia.class is the one and only Reggae class having shared library API except of BOOPSI (object) one.
Streams form input data abstraction layer of Reggae. A stream is always the first object in any Reggae processing structure. It has one output port. All streams have common set of attributes and methods for data fetching and control. Currently available streams are:
Every media format recognized by Reggae has its own demuxer. Demuxer class is responsible for format recognition, header decoding, metadata extraction and demultiplexing (hence the name) media streams to separate output ports. While there is no real demultiplexing in simple audio or image formats, splitting functionality between demuxer and decoder allows for code reusing, as multiple demuxers may use the same decoder class (for example all demuxers for audio formats using uncompressed PCM, use audiopcm.decoder).
There are also a few "general" demuxers not associated with particular data format. They either handle some common metadata (like id3tag.demuxer), or common compression schemes at datastream level (xpk.demuxer). Such demuxers are usually the first stage of demuxer cascade.
A decoder takes a single, demuxed media stream and converts it to one of Reggae common formats. This conversion usually means decompression and decoding of stream. Some decoders are dedicated to one particular media format, some are more general and used with many demuxers.
A Reggae filter accepts data in one of Reggae common formats, performs some transformation on data and deliver them in the same or other Reggae common format. Most filters have the same format on inputs and outputs, but it is not the rule of thumb. Imagine a filter generating visualisations for audio player, it will accept audio and generate video.
Outputs form output abstraction layer of Reggae. They are not symmetrical to streams however. Outputs can be divided into two groups:
Constructing a chain of connected Reggae objects does not start data processing automatically. Reggae is a pull-driven system, so something must pull data at the end of chain. It may be the application, who actively call MMM_Pull() method on output port(s) at the end of chain. Then it just gets data in some memory buffer and can do whatever it wants with them. Alternatively the last chain object may be an instance of some Reggae output class. Then the whole processing is done by Reggae.
Every Reggae output object creates a subprocess which pulls data from the chain of objects and either stores them or presents to the user. It means that all Reggae data processing is automatically offloaded from application to the subprocess. Main application process is free to handle GUI, display processing progress and control the processing by performing methods on the output object. Subprocessing Reggae chain makes creating GUI-based applications easier, and allows for example background processing, just by setting subprocess priority below 0. It may be useful for storage outputs. User presentation outputs have to work in real time, so their default priorities are above 0.
There are some helper classes, which are used by Reggae internally, but may be interesting for advanced Reggae programmers. Here is a brief description of them: