git.sesse.net Git - mlt/blob - README

   1 README
   2 ------
   3
   4         This document provides a description of the MLT project organisation.
   5
   6         It provides *CRITICAL* architecture information, so please read carefully
   7         if you plan to extend or use the MLT code base.
   8
   9 Directories
  10 -----------
  11
  12         The directory heirarchy is defined as follows:
  13
  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
  33
  34         Additional subdirectories may be nested below those shown and should be
  35         documented in their parent.
  36
  37         (*) Not posted to CVS due to licensing issues.
  38
  39 Configuration
  40 -------------
  41
  42         Configuration is triggered from the top level directory via a
  43         ./configure script.
  44
  45         Each source bearing subdirectory shown above have their own configure
  46         script which are called automatically from the top level.
  47
  48         Typically, new modules can be introduced without modification to the
  49         configure script and arguments are accepted and passed through to all
  50         subdirectories.
  51
  52         Top level usage is:
  53
  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
  58
  59         NB: This script must be run to register new services after a CVS checkout
  60         or subsequent update.
  61
  62 Compilation
  63 -----------
  64
  65         Makefiles are generated during configuration and these are based on
  66         a per directory template which must be provided by the developer.
  67
  68 Testing
  69 -------
  70
  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:
  73
  74         . setenv
  75
  76         NB: This applies to your current shell only.
  77
  78 Installation
  79 ------------
  80
  81         * NOT IMPLEMENTED YET *
  82
  83         The install is triggered by running make install or make install-strip
  84         from the top level directory.
  85
  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.
  89
  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.
  93
  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.
  97
  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.
 102
 103         To allow the development of external components, mlt-client-config and
 104         mlt-framework-config scripts are generated and installed in $prefix/bin.
 105
 106         After install, only those modules listed are usable by the server. No
 107         module is loaded unless explicitly requested via server configuration
 108         or usage.
 109
 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.
 113
 114 Development
 115 -----------
 116
 117         All compilation in the project has {top-level-dir}/src on the include path.
 118         All headers are included as:
 119
 120                 #include <framework/file.h>
 121
 122         All external modules have {prefix}/include/mlt on the include path. All
 123         headers should also be included as:
 124
 125                 #include <framework/file.h>
 126
 127         This allows migration of source between external and internal modules.
 128         The configuration and Makefile template requirements will require
 129         attention though.
 130
 131 Summary
 132 -------
 133
 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.
 137