4 This document provides a description of the MLT project organisation.
6 It provides *CRITICAL* architecture information, so please read carefully
7 if you plan to extend or use the MLT code base.
12 The directory heirarchy is defined as follows:
14 + docs - Location of all documentation
15 + src - All project source is provided here
16 + framework - The mlt media framework
17 + modules - All services are defined here
18 + core - Independent MLT services
19 + dv - libdv dependent services
20 + ffmpeg - ffmpeg dependent services
21 + avformat - libavformat dependent services
22 + sdl - SDL dependent services
23 + resample - libresample dependent services
24 + gtk2 - pango and pixbuf dependent services
25 + bluefish - Bluefish dependent services (*)
26 + mainconcept - mainconcept dependent services (*)
27 + inigo - A media playing test application
28 + valerie - Client API to access the server
29 + miracle - The server implementation
30 + humperdink - The evil demo
31 + albino - The simple but nice demo
32 + tests - Reserved for regression and unit tests
34 Additional subdirectories may be nested below those shown and should be
35 documented in their parent.
37 (*) Not posted to CVS due to licensing issues.
42 Configuration is triggered from the top level directory via a
45 Each source bearing subdirectory shown above have their own configure
46 script which are called automatically from the top level.
48 Typically, new modules can be introduced without modification to the
49 configure script and arguments are accepted and passed through to all
54 ./configure --help - report all configure options
55 ./configure --prefix=[dir] - target install directory (default: /usr/local)
56 ./configure --disable-[mod] - do not compile specified module(s)
57 ./configure --[other] - pass through to children
59 NB: This script must be run to register new services after a CVS checkout
65 Makefiles are generated during configuration and these are based on
66 a per directory template which must be provided by the developer.
71 To execute the mlt tools without installation, or to test a new version
72 on a system with an already installed mlt version, you should run:
76 NB: This applies to your current shell only.
81 * NOT IMPLEMENTED YET *
83 The install is triggered by running make install or make install-strip
84 from the top level directory.
86 The framework produces a single shared object which is installed in
87 $prefix/lib/ and public header files which are installed in
88 $prefix/include/mlt/framework.
90 The client produces a single shared object which is installed in
91 $prefix/lib/ and public header which are installed in
92 $prefix/include/mlt/client.
94 The server produces a single exectuable which is installed in
95 $prefix/bin/. This is linked against the framework shared object and
96 posix libs but not against any of the modules.
98 The modules produce a shared object per module and update text files
99 containing a list of modules provided by this build. These are installed
100 in $prefix/share/mlt/. It is at the discretion of the module to install
101 additional support files.
103 To allow the development of external components, mlt-client-config and
104 mlt-framework-config scripts are generated and installed in $prefix/bin.
106 After install, only those modules listed are usable by the server. No
107 module is loaded unless explicitly requested via server configuration
110 External modules are also placed in this $prefix/share/mlt, and the
111 installation of those must modify the text file accordingly before they
112 will be considered at runtime.
117 All compilation in the project has {top-level-dir}/src on the include path.
118 All headers are included as:
120 #include <framework/file.h>
122 All external modules have {prefix}/include/mlt on the include path. All
123 headers should also be included as:
125 #include <framework/file.h>
127 This allows migration of source between external and internal modules.
128 The configuration and Makefile template requirements will require
134 1. The server will interact with public interfaces from the framework only;
135 2. The modules must expose public framework interfaces only;
136 3. All modules are dynamically loaded at runtime.