4 This mlt sub-project provides a C++ wrapping for the MLT library.
9 ./configure [ --prefix=path ]
16 Use the following definitions in a Makefile to compile and link with mlt++:
18 CXXFLAGS=`mlt-config -Wall`
21 All definitions are placed in an Mlt namespace, and adhere closely to the C
22 naming convention. Mappings always follow the pattern:
26 mlt_factory_init => Mlt::Factory::init
27 mlt_factory_producer => Mlt::Factory::producer
32 mlt_producer ==> Mlt::Producer
33 mlt_consumer ==> Mlt::Consumer
38 mlt_type_method ==> Mlt:Type.method
39 ie: mlt_playlist_append ==> Mlt::Playlist.append
42 Enumerators and macros are reused directly from the C library.
47 The currently mapped objects are shown in the following hierarchy:
62 Care should be taken with wrapper objects.
64 Taking, as an example, the C function that returns the immediate consumer of
67 mlt_service mlt_service_consumer( mlt_service );
71 Mlt::Service *Mlt::Service.consumer( );
73 Note that you get an object back - it is never the original object, but a
74 wrapping object. This is done to keep consistency with the C api which may
75 instantiate C instances - therefore there it cannot be assumed that a C++
76 object exists for all mlt service instances.
78 As such, it is mandatory that you delete these objects. The original will
79 not be affected. Further to that, all modifications (to properties or its
80 state of connection) will be reflected in the original object.
82 This excludes the use of the RTTI to determine the real type of the object -
83 this can only be done by parsing the objects properties.
85 Non-NULL objects may be invalid - always use the is_valid method to
86 check validity before use.
91 The mechanisms for the definition of new services have deliberately not
92 been exposed by the C++ wrappings - this is done to ensure that service
93 networks constructed can be serialised and used by existing applications
94 which are based on the C API (such as miracle).