-README
-------
+MLT FRAMEWORK README
+--------------------
- This document provides a description of the VPS project organisation.
+ Sponsored by Ushodaya Enterprises Limited
+ Written by Charles Yates <charles.yates@pandora.be>
+ and Dan Dennedy <dan@dennedy.org>
- It provides *CRITICAL* architecture information, so please read carefully
- if you plan to extend or use the VPS code base.
+ MLT is a LGPL multimedia framework designed for television broadcasting,
+ and melted is a GPL multi-unit video playout server with realtime
+ effects.
-Directories
------------
+ This document provides a quick reference for the minimal configuration,
+ build and installation of MLT.
+
+ See the docs directory for usage details.
+
+ See the website for development details:
+ http://www.mltframework.org/twiki/bin/view/MLT/Documentation
+ http://www.mltframework.org/twiki/bin/view/MLT/Contributing
+ http://www.mltframework.org/twiki/bin/view/MLT/ToDo
- The directory heirarchy is defined as follows:
-
- + docs - Location of all text and source format
- documentation
- + src - All project source is provided here
- + client - Client API to access the server
- + framework - The media framework - this code is 100% posix
- and as such contain no implementations
- requiring additional libraries
- + modules - All components are defined here with a
- subdirectory for each dependency
- + bluefish - Bluefish dependent modules and test code
- + ffmpeg - ffmpeg dependent modules and test code
- + mainconcept - mainconcept dependent modules and test code
- + SDL - SDL dependent modules and test code
- + server - The server implementation
-
- Additional subdirectories may be nested below those shown and should be
- documented in their parent or here.
Configuration
-------------
- Configuration is triggered from the top level directory via a
- ./configure script.
+ Configuration is triggered by running:
+
+ ./configure
- Each source bearing subdirectory shown above have their own configure
- script which are called automatically from the top level.
+ More information on usage is found by running:
- Typically, new modules can be introduced without modification to the
- configure script and arguments are accepted and passed through to all
- subdirectories.
+ ./configure --help
- Top level usage is:
+ NB: This script must be run to register new services after a CVS checkout
+ or subsequent update.
- ./configure --help - report all configure options
- ./configure --prefix=[dir] - target install directory (default: /usr/local)
- ./configure --disable-[mod] - do not compile specified module(s)
- ./configure --[other] - pass through to children
Compilation
-----------
- Makefiles are generated during configuration and these are based on
- a per directory template which must be provided by the developer.
+ Once configured, it should be sufficient to run:
-Installation
-------------
+ make
- The install is triggered by running make install or make install-strip
- from the top level directory.
-
- The framework produces a single shared object which is installed in
- $prefix/lib/ and public header files which are installed in
- $prefix/include/mlt/framework.
-
- The client produces a single shared object which is installed in
- $prefix/lib/ and public header which are installed in
- $prefix/include/mlt/client.
-
- The server produces a single exectuable which is installed in
- $prefix/bin/. This is linked against the framework shared object and
- posix libs but not against any of the modules.
-
- The modules produce a shared object per module and a text file containing
- a list of modules provided by this build. These are installed in
- $prefix/share/mlt/. It is at the discretion of the module to install
- additional support files.
-
- To allow the development of external components, mlt-client-config and
- mlt-framework-config scripts are generated and installed in $prefix/bin.
+ to compile the system.
- After install, only those modules listed are usable by the server. No
- module is loaded unless explicitly requested via server configuration
- or usage.
- External modules are also placed in this $prefix/share/mlt, and the
- installation of those must modify the text file accordingly before they
- will be considered at runtime.
+Testing
+-------
-Development
------------
+ To execute the mlt tools without installation, or to test a new version
+ on a system with an already installed mlt version, you should run:
- All compilation in the project has {top-level-dir}/src on the include path.
- All headers are included as:
+ . setenv
- #include <framework/file.h>
-
- All external modules have {prefix}/include/mlt on the include path. All
- headers should also be included as:
+ NB: This applies to your current shell only and it assumes a bash or
+ regular bourne shell is in use.
- #include <framework/file.h>
- This allows migration of source between external and internal
- modules. The configuration and Makefile template requirements will require
- attention though.
+Installation
+------------
-Summary
--------
+ The install is triggered by running:
+
+ make install
+
- 1. The server will interact with public interfaces from the framework only;
- 2. The modules must expose public framework interfaces only;
- 3. All modules are dynamically loaded at runtime.
+More Information
+----------------
+ For more detailed information, please refer to docs/install.txt.
projects / mlt / blobdiff