4 This document provides a brief tutorial on the use of the mlt++ wrapper
11 The mlt++ wrapper is a c++ wrapper for the mlt C library. As such, it
12 provides clean C++ access to the underlying library.
14 An example of use is as follows:
16 #include <mlt++/Mlt.h>
22 Producer p( "pango:", "Hello World" );
29 This is a fairly typical example of mlt++ usage - create a 'producer' (an
30 object which produces 'frames'), create a 'consumer' (an object which consumes
31 frames), connect them together, start the consumer and wait until done (here
32 we just wait for the user to close the window).
34 In this case, we construct a window as a consumer using the 'sdl' consumer
35 (SDL is a standard portable library which provides platform independent
36 access to accelerated video display and audio) and use the 'pango'
37 producer to generate frames with the words 'Hello World' (pango is a
38 library from the gtk toolkit).
40 The main point of this example is to show that mlt uses existing libraries
41 to provide its functionality - this keeps the framework itself very small.
43 Note that mlt is designed to be housed in GUI or server type applications -
44 typically, applications don't wait around for the consumer to be stopped in
47 So far, we've introduced the Producer and Consumer mlt classes. We'll cover
48 each of these in more detail later in the tutorial, but for now, we'll
49 briefly cover the remaining classes.
55 Another simple class is the Playlist - this is direct extension of Producer
56 and it allows you to maintain a list of producer objects.
58 As a simple example of the Playlist in action, we'll convert the example
59 above into an application which plays multiple video or audio files.
61 #include <mlt++/Mlt.h>
64 int main( int argc, char **argv )
68 for ( int i = 1; i < argc; i ++ )
70 Producer p( argv[i] );
80 Now you can run the program as:
82 ./player *.avi *.mp3 *.jpg etc
84 In this case, we construct a playlist by simply appending producers to it.
85 Notice that although the scope of the Producer is limited to the inner
86 for loop, we can safely add it to the playlist - this is due to the fact
87 that all mlt objects maintain reference counts and no object is really
88 destroyed until all the references are gone. In this case, when the list
89 object goes out of scope, all the producers we created will automatically
96 So far, we've shown how you can load and play media. We've given a brief
97 intro to the Playlist container, now it's time to start manipulating
100 For the next example, I'll add a 'watermark' to the video - a watermark
101 is used by broadcasters to brand the channel and normally consists of a
102 logo of some sort. We'll just use some black text on a partially
103 transparent red background.
105 #include <mlt++/Mlt.h>
108 int main( int argc, char **argv )
112 for ( int i = 1; i < argc; i ++ )
114 Producer p( argv[i] );
118 Filter f( "watermark", "pango:" );
119 f.set( "producer.text", "MLT++" );
120 f.set( "producer.fgcolour", "0x000000ff" );
121 f.set( "producer.bgcolour", "0xff000080" );
129 Notice that the watermark filter reuses the 'pango' producer we showed in the
130 first example. In fact, you could use any producer here - if you wanted to
131 use a graphic or a video, you would just construct the filter with a full path
132 to that as the second argument.
134 We manipulate the filter using the set method - this method was also shown
135 in the first example.
137 Finally, we attach the filter to the playlist. This ensure that all frames
138 that are obtained from the playlist are watermarked.
144 When you add a clip to a playlist, the a cut object is created - this is merely a
145 wrapper for the producer, spanning the specified in and out points.
147 Whenever you retrieve a clip from a playlist, you will always get a cut object.
148 This allows you to attach filters to a specific part of a producer and should
149 the position of the cut in the playlist change, then the filter will remain
150 correctly associated to it.
152 A producer and a cut are generally identical in behaviour, but should you need to
153 distinguish between them, you can use:
155 if ( producer.is_cut( ) )
157 and to retrieve the parent of a cut, you can use:
159 Producer parent = producer.parent_cut( );
161 Filters that are attached directly to a parent are executed before any filters
168 A tractor is an object that allows the manipulation of multiple video and audio
171 Stepping away from the player example we've been tinkering with for a minute,
172 let's assume we want to do something like dub a video with some audio. This
173 a very trivial thing to do:
175 Tractor *dub( char *video_file, char *audio_file )
177 Tractor *tractor = new Tractor( );
178 Producer video( video_file );
179 Producer audio( audio_file );
180 tractor->set_track( video, 0 );
181 tractor->set_track( audio, 1 );
185 That's all that needs to be done - you can now connect the returned object to a
186 consumer, or add it to a playlist, or even apply it as a track to another tractor.
192 Let's now assume we want to mix the audio between two tracks - to do this, we
193 need to introduce the concept of a transition. A transition in mlt is a service
194 which combines frames from two producers to produce a new frame.
196 Tractor *mix( char *video_file, char *audio_file )
198 Tractor *tractor = new Tractor( );
199 Transition mix( "mix" );
200 Producer video( video_file );
201 Producer audio( audio_file );
202 tractor.set_track( video, 0 );
203 tractor.set_track( audio, 1 );
204 tractor.field.plant_transition( mix, 0, 1 );
208 The tractor returned will now mix the audio from the original video and the
215 There is a convenience function which simplifies the process of applying
216 transitions betwee adjacent cuts on a playlist. This is often preferable
217 to use over the constuction of your own tractor and transition set up.
219 To apply a 25 frame luma transition between the first and second cut on
220 the playlist, you could use:
223 playlist.mix( 0, 25, luma );
229 Typically, applications need to be informed when changes occur in an mlt++ object.
230 This facilitates application services such as undo/redo management, or project
231 rendering in a timeline type widget and many other types of operations which an
234 As an example, consider the following:
242 Westley( MltTractor &tractor ) :
244 consumer( "westley" )
246 consumer.connect( tractor );
247 tractor.listen( tractor, "producer-changed",
248 ( mlt_listener )Westley::listener );
251 static void listener( Properties *tractor, Westley *object )
262 Now, each time the tractor is changed, the westley representation is output to
266 Servers and Westley Docs
267 ------------------------
269 One of the key features of MLT is its server capabilities. This feature
270 allows you to pass westley documents seamlessly from one process to
271 another and even to different computers on your network.
273 The miracle playout server is one such example of an application which
274 uses this functionality - you can build your own servers into your own
277 A server process would be running as follows:
279 #include <mlt++/Miracle>
284 Miracle miracle( "miracle", 5250 );
286 miracle.execute( "uadd sdl" );
287 miracle.execute( "play u0" );
288 miracle.wait_for_shutdown( );
292 Typically, when you have an MLT object such as a producer or a playlist,
293 you can send a westley representation of this to a running server with:
295 Conumser valerie( "valerie", "localhost:5250" );
296 valerie.connect( producer );
299 The effect of the push will be to append the producer on to the first
302 You can completely customise the miracle server - an example of this
309 And that, believe it or not, is a fairly complete summary of the classes you'll
310 typically be interfacing with in mlt++. Obviously, there's a little more to it
311 than this - a couple of intrisinc classes have been glossed over (notably, the
312 Properties and Service base classes). The next section will cover all of the
313 above, but in much more detail...
319 The previous section was designed to give you a whistle stop tour through the major
320 framework classes. This section will take you through the scenic route.
323 Introducing Base Classes
324 ------------------------
326 Services in mlt are the collective noun for Producers, Filters, Transitions and
327 Consumer. A Service is also the base class from which all of these classes
328 extend. It provides the basic connectivity which has been shown throughout the
329 examples in the previous section.
331 Properties are the main way in which we communicate with the Services -
332 essentially, it provides get/set methods for named values. All services extend
339 Properties provide the general mechanism for communicating with Services -
340 through the Properties interface, we are able to manipulate and serialise
343 For example, to dump all the properties to stdout, you can use something
346 void dump( Properties &properties )
348 for ( int i = 0; i < properties.count( ); i ++ )
349 cout << Properties.get_name( i ) << " = " << Properties.get( i ) << endl;
352 Note that the properties object handles type conversion, so the following
355 properties.set( "hello", "10.5" );
356 int hello_int = properties.get_int( "hello" );
357 double hello_double = properties.get_double( "hello" );
359 A couple of convenience methods are provide to examine or serialise property
366 will report all serialisable properties on stderr, in the form:
368 Object: [ ref=1, in=0, out=0, track=0, u=75, v=150, _unique_id=15,
369 mlt_type=filter, mlt_service=sepia ]
375 Typically, all the services are constructed via the specific classes
376 constructor. Often, you will receive Service objects rather than their
377 specific type. In order to access the extended classes interface,
378 you will need to create a reference.
380 For example, given an arbitrary Service object, you can determine its
381 type by using the type method - this will return a 'service_type' which
382 has values of producer_type, filter_type etc. Alternatively, you can
383 create a wrapping object and check on its validity.
385 bool do_we_have_a_producer( Service &service )
387 Producer producer( service );
388 return producer.is_valid( );
396 Servers and Westley Docs
397 ------------------------
399 For various reasons, you might want to serialise a producer to a string.
400 To do this, you just need to specify a property to write to:
402 Consumer westley( "westley", "buffer" );
403 westley.connect( producer );
405 buffer = westley.get( "buffer" );
407 You can use any name you want, and you can change it using the "resource"
408 property. Any name with a '.' in it is considered to be a file. Hence, you
409 can use a westley consumer to store multiple instances of the same MLT
410 object - useful if you want to provide undo/redo capabilities in an
413 Should you receive an xml document as a string, and you want to send it
414 on to a server, you can use:
416 Conumser valerie( "valerie", "localhost:5250" );
417 valerie.set( "westley", buffer );
420 If you need to obtain an MLT object from a string:
422 Producer producer( "westley-xml", buffer );
424 The following shows a working example of an extended server:
426 class ShotcutServer : public Miracle
429 ShotcutServer( char *id, int port ) :
434 void set_receive_doc( bool doc )
436 set( "push-parser-off", doc );
439 // Reject all commands other than push/receive
440 Response *execute( char *command )
442 valerie_response response = valerie_response_init( );
443 valerie_response_set_error( response, 400, "Not OK" );
444 return new Response( response );
447 // Push document handler
448 Response *received( char *command, char *doc )
450 valerie_response response = valerie_response_init( );
451 // Use doc in some way and assign Response
453 valerie_response_set_error( response, 200, "OK" );
454 return new Response( response );
457 // Push service handler
458 Response *push( char *command, Service *service )
460 valerie_response response = valerie_response_init( );
461 // Use service in some way and assign Response
462 if ( service != NULL )
463 valerie_response_set_error( response, 200, "OK" );
464 return new Response( response );
468 NB: Should you be incorporating this into a GUI application, remember that the
469 execute, received and push methods are invoked from a thread - make sure that
470 you honour the locking requirements of your GUI toolkit before interacting with