Choosing the Right Codec - A Practical Guide to Video and Audio Compression - page 173

The current state of the art for players is to deliver architectures that allow different
codecs to be plugged in at run time. The players are separated somewhat from the codecs.
This is how it's done:
A player provides a framework and a foundation with code that is necessary for
playing back all video formats. This framework and foundation include the user interface
(UI), for example, with its play and pause buttons, menu and file-opening dialogs, and
general look and feel.
Once all the generic handling of a particular video format is dealt with, any special-
ized code that deals with translating and decoding a specific video format is contained in
a plug-in module. All of these plug-in modules support the same application interface, so
the player can call for the same things to be done regardless of the format selected. The
plug-in then deals with the specifics of a particular video-encoding or playback process,
having been delegated with that task by the player application.
It's a very neat concept and allows codecs and players to upgraded independently.
It creates opportunities for third parties to create their own plug-in modules or to make a
player and then use a readily available library of plug-ins.

8.3.1 Open Standards Versus Proprietary Implementations

With an open standard, everyone gets to compete equally. Products are differentiated
according to quality of manufacture, reliability, price, and functionality. With a proprietary
implementation, you are locked in at the creative and consumption ends of the delivery
chain. You have to justify for yourself whether this is good or bad. Decisions about this
tend to be based on reach and market penetration of certain players or platforms.
Going with any of the proprietary codecs locks you into one or another company's
future strategy. You are entirely at the mercy of any decisions the company might make to
immediately cease support of its player on a particular platform. Companies do that sort
of thing, often with little or no warning.
Real Networks video is available everywhere; QuickTime is available on Mac OS and
Windows but is not available on Linux without your using special tricks. Windows Media
support is likewise available on Mac OS and Windows but not on Linux unless you use
those same techniques to run Windows dynamic link libraries (DLLs) in a Windows emu-
lation framework.
A DLL module contains dynamically linked library software written in Intel machine
code and is designed to be shared between several applications to avoid duplication of the
same code every time. Linux operating systems can generally cope with this quite easily
by running the DLLs inside a framework, and provided they are on an Intel-based com-
puter, everything is fine.
Mac OS systems use a completely different processor that does not natively under-
stand the Intel code without the necessary software support being provided. The PowerPC
chip in a Macintosh needs to run a translation or emulation engine to interpret that Intel
machine code. It is possible (Virtual PC does it, for example), but it is not very easy to set
up. Ideally, the software inside the DLL should be recompiled for the PowerPC, but this is
not always feasible.