You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
|
12 years ago | |
---|---|---|
admin@daca7919fe | 12 years ago | |
cmake@f93811ed00 | 12 years ago | |
src | 13 years ago | |
swig | 15 years ago | |
test | 13 years ago | |
.gitmodules | 12 years ago | |
AUTHORS | 15 years ago | |
CUSTOMISING | 15 years ago | |
HOWTO | 15 years ago | |
LGPL | 15 years ago | |
Makefile | 15 years ago | |
README | 15 years ago | |
config.mak | 15 years ago | |
configure | 15 years ago | |
mlt++.sln | 15 years ago | |
mlt++.vcproj | 15 years ago |
README
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=`mlt-config -Wall` LDFLAGS=-lmlt++ Include files for the classes can either be explicitly included, ie: #include <mlt++/MltProducer.h> etc Or you can include all using: #include <mlt++/Mlt.h> 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.