From 1732afa34ac6db997634116699cd439bf4669081 Mon Sep 17 00:00:00 2001 From: Dan Dennedy Date: Thu, 7 May 2009 22:03:19 -0700 Subject: [PATCH] Merge mlt++/README into docs/mlt++.txt. Signed-off-by: Dan Dennedy --- docs/mlt++.txt | 157 +++++++++++++++++++++++++++++++++++-------------- mlt++/README | 135 ------------------------------------------ 2 files changed, 113 insertions(+), 179 deletions(-) delete mode 100644 mlt++/README diff --git a/docs/mlt++.txt b/docs/mlt++.txt index dbeca9a3..7784cae9 100644 --- a/docs/mlt++.txt +++ b/docs/mlt++.txt @@ -1,9 +1,118 @@ -INTRODUCTION ------------- +MLT++ +----- - This document provides a brief tutorial on the use of the mlt++ wrapper - and bindings. + This mlt sub-project provides a C++ wrapping for the MLT library. +Usage +----- + + Use the following definitions in a Makefile to compile and link with mlt++: + + CXXFLAGS=`pkg-config --cflags mlt-framework` -Wall + LDFLAGS=-lmlt++ `pkg-config --libs mlt-framework` + + Include files for the classes can either be explicitly included, ie: + + #include + etc + + Or you can include all using: + + #include + + All definitions are placed in an Mlt namespace, and adhere closely to the C + naming convention. Mappings always follow the pattern: + + Factory methods: + + mlt_factory_init ==> Mlt::Factory::init + mlt_factory_producer ==> Mlt::Factory::producer + mlt_factory_filter ==> Mlt::Factory::filter + mlt_factory_transition ==> Mlt::Factory::transition + mlt_factory_consumer ==> Mlt::Factory::consumer + mlt_factory_close ==> Mlt::Factory::close + + NB: Factory usage for service construction is optional. + + Types: + + mlt_properties ==> Mlt::Properties + mlt_frame ==> Mlt::Frame + mlt_service ==> Mlt::Service + mlt_producer ==> Mlt::Producer + mlt_filter ==> Mlt::Filter + mlt_transition ==> Mlt::Transition + mlt_consumer ==> Mlt::Consumer + + Methods: + + mlt_type_method ==> Mlt::Type.method + ie: mlt_playlist_append ==> Mlt::Playlist.append + + Parent methods are available directly on children. + + Additionally, you can specify: + + using namespace Mlt; + + To avoid the enforced use of the Mlt:: prefix. + + Enumerators and macros are reused directly from the C library. + +Class Hierarchy +--------------- + + The currently mapped objects are shown in the following hierarchy: + + Factory + Properties + Frame + Service + Consumer + Field + Filter + Multitrack + Producer + Playlist + Tractor + Transition + +Special Cases +------------- + + Care should be taken with wrapper objects. + + Taking, as an example, the C function that returns the immediate consumer of + a service: + + mlt_service mlt_service_consumer( mlt_service ); + + This maps to: + + Mlt::Service *Mlt::Service.consumer( ); + + Note that you get an object back - it is never the original c++ object, but + a wrapping object. This is done to keep consistency with the C api which may + instantiate C instances - therefore it cannot be assumed that a C++ object + exists for all mlt service instances. + + As such, it is mandatory that you delete these objects. The original will + not be affected. However, all other modifications (to properties or its + state of connection) will be reflected in the original object. + + This approach excludes the use of RTTI to determine the real type of the + object - this can only be done by parsing the objects properties. + + Objects may be invalid - always use the is_valid method to check validity + before use. + +Limitations +----------- + + The mechanisms for the definition of new services are deliberately + excluded from the C++ wrappings - this is done to ensure that service + networks constructed can be serialised and used by existing applications + which are based on the C API (such as melted). Hello World ----------- @@ -263,46 +372,6 @@ Events stderr. -Servers and Westley Docs ------------------------- - - One of the key features of MLT is its server capabilities. This feature - allows you to pass westley documents seamlessly from one process to - another and even to different computers on your network. - - The miracle playout server is one such example of an application which - uses this functionality - you can build your own servers into your own - processes with ease. - - A server process would be running as follows: - - #include - using namespace Mlt; - - int main( void ) - { - Miracle miracle( "miracle", 5250 ); - miracle.start( ); - miracle.execute( "uadd sdl" ); - miracle.execute( "play u0" ); - miracle.wait_for_shutdown( ); - return 0; - } - - Typically, when you have an MLT object such as a producer or a playlist, - you can send a westley representation of this to a running server with: - - Conumser valerie( "valerie", "localhost:5250" ); - valerie.connect( producer ); - valerie.start( ); - - The effect of the push will be to append the producer on to the first - unit (u0). - - You can completely customise the miracle server - an example of this - is shown below. - - That's All Folks... ------------------- diff --git a/mlt++/README b/mlt++/README deleted file mode 100644 index 54c63777..00000000 --- a/mlt++/README +++ /dev/null @@ -1,135 +0,0 @@ -MLT++ ------ - - This mlt sub-project provides a C++ wrapping for the MLT library. - -INSTALLATION ------------- - - ./configure [ --prefix=path ] - make - make install - -USAGE ------ - - Use the following definitions in a Makefile to compile and link with mlt++: - - CXXFLAGS=`pkg-config --cflags mlt-framework` -Wall - LDFLAGS=-lmlt++ `pkg-config --libs mlt-framework` - - Include files for the classes can either be explicitly included, ie: - - #include - etc - - Or you can include all using: - - #include - - All definitions are placed in an Mlt namespace, and adhere closely to the C - naming convention. Mappings always follow the pattern: - - Factory methods: - - mlt_factory_init ==> Mlt::Factory::init - mlt_factory_producer ==> Mlt::Factory::producer - mlt_factory_filter ==> Mlt::Factory::filter - mlt_factory_transition ==> Mlt::Factory::transition - mlt_factory_consumer ==> Mlt::Factory::consumer - mlt_factory_close ==> Mlt::Factory::close - - NB: Factory usage for service construction is optional. - - Types: - - mlt_properties ==> Mlt::Properties - mlt_frame ==> Mlt::Frame - mlt_service ==> Mlt::Service - mlt_producer ==> Mlt::Producer - mlt_filter ==> Mlt::Filter - mlt_transition ==> Mlt::Transition - mlt_consumer ==> Mlt::Consumer - - Methods: - - mlt_type_method ==> Mlt::Type.method - ie: mlt_playlist_append ==> Mlt::Playlist.append - - Parent methods are available directly on children. - - Additionally, you can specify: - - using namespace Mlt; - - To avoid the enforced use of the Mlt:: prefix. - - Enumerators and macros are reused directly from the C library. - -CLASS HIERARCHY ---------------- - - The currently mapped objects are shown in the following hierarchy: - - Factory - Properties - Frame - Service - Consumer - Field - Filter - Multitrack - Producer - Playlist - Tractor - Transition - - An additional set of classes allow apps to behave as, and communicate with, - client/server components - these components provide MLT with unique - possibilties for process to process or system to system communications. - - Miracle - Response - -SPECIAL CASES -------------- - - Care should be taken with wrapper objects. - - Taking, as an example, the C function that returns the immediate consumer of - a service: - - mlt_service mlt_service_consumer( mlt_service ); - - This maps to: - - Mlt::Service *Mlt::Service.consumer( ); - - Note that you get an object back - it is never the original c++ object, but - a wrapping object. This is done to keep consistency with the C api which may - instantiate C instances - therefore it cannot be assumed that a C++ object - exists for all mlt service instances. - - As such, it is mandatory that you delete these objects. The original will - not be affected. However, all other modifications (to properties or its - state of connection) will be reflected in the original object. - - This approach excludes the use of RTTI to determine the real type of the - object - this can only be done by parsing the objects properties. - - Objects may be invalid - always use the is_valid method to check validity - before use. - -LIMITATIONS ------------ - - The mechanisms for the definition of new services are deliberately - excluded from the C++ wrappings - this is done to ensure that service - networks constructed can be serialised and used by existing applications - which are based on the C API (such as miracle). - -SWIG ----- - - Experimental swig bindings based on mlt++ are provided. - -- 2.39.2