X-Git-Url: http://research.m1stereo.tv/gitweb?a=blobdiff_plain;f=mlt%2B%2B%2FREADME;fp=mlt%2B%2B%2FREADME;h=26cc441b1234e7b3bca275719199623a5a1f811b;hb=23ecec6406d4b4f953dfa72994169207a5fbb610;hp=0000000000000000000000000000000000000000;hpb=01c1d44e8df201c3061cf20addf5421d21d8bcb0;p=melted

diff --git a/mlt++/README b/mlt++/README
new file mode 100644
index 0000000..26cc441
--- /dev/null
+++ b/mlt++/README
@@ -0,0 +1,92 @@
+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++
+
+	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
+		etc
+
+	Types:
+
+		mlt_producer			==>	Mlt::Producer
+		mlt_consumer			==>	Mlt::Consumer
+		etc
+
+	Methods:
+
+		mlt_type_method			==> Mlt:Type.method
+	ie:	mlt_playlist_append		==> Mlt::Playlist.append
+		etc
+
+	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
+				Filter
+				Producer
+					Playlist
+				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 object, but a 
+	wrapping object. This is done to keep consistency with the C api which may 
+	instantiate C instances - therefore there 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. Further to that, all modifications (to properties or its
+	state of connection) will be reflected in the original object.
+
+	This excludes the use of the RTTI to determine the real type of the object -
+	this can only be done by parsing the objects properties.
+
+LIMITATIONS
+-----------
+
+	The mechanisms for the definition of new services have deliberately not 
+	been exposed by 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).
+