3 Copyright (C) 2004 Ushodaya Enterprised Limited
4 Authors: Charles Yates <charles.yates@pandora.be>
5 Last Revision: 2004-03-20
13 Westley is the MLT projects XML serialisation/deserialisation format -
14 as such, it closely mirrors the internal structure of the MLT API.
16 If you just want to go straight to the DTD, then see
17 mlt/src/modules/westley/westley.dtd, which gets installed at
18 $(prefix)/share/mlt/modules/westley.dtd. Currently, the westley parser is
24 A westley document is essentially a list of 'producers' - a producer is
25 an mlt object which generates mlt frames (images and associated audio
28 There are 3 types of producer:
30 * Basic Producers - these are typically file or device oriented feeds;
31 * Playlists - these are arrangements of multiple producers;
32 * Multitracks - these are the fx encapsulators.
34 In the mlt model, producers are created and attached to 'consumers' -
35 consumers are software playback components (such as SDL), or wrappers for
36 hardware drivers (such as bluefish) or even the westley serialising
37 consumer itself (the latter doesn't receive frames - it merely
38 interrogates the connected producer for its configuration).
40 Although westley was defined as a serialisation mechanism for instantiated
41 MLT components, this document will concentrate on the hand authoring of
47 As shall become apparent through the remainder of this document, the basic
48 tenet of westley authoring is to organise the document in the following
51 1) create producer elements for each unique media clip in the project;
52 2) create playlists for each track;
53 3) create a multitrack and specify filters and transitions;
54 4) adding global filters.
56 While other uses of westley exist, the approach taken here is to maximise
57 efficiency for complex projects.
62 The simplest westley document is:
65 <producer id="producer0">
66 <property name="resource">clip1.dv</property>
70 The westley wrapping is of course superfluous here - loading this document
71 with MLT is identical to loading the clip directly.
73 Of course, you can specify additional properties. For example, consider an
74 MPEG file with multiple soundtracks - you could define a westley document to
75 ensure that the second audio track is loaded:
78 <producer id="producer0">
79 <property name="resource">clip1.mpeg</property>
80 <property name="audio_track">1</property>
84 NB: This relies on the mpeg being handled by the avformat producer, rather
85 than the mcmpeg one. See services.txt for more details.
87 A more useful example comes with the pango producer for a text producer.
89 TODO: pango example...
93 1) It is better not to specify in/out points when defining basic producers
94 as these can be specified in the playlists. The reasoning is that in/out
95 restricts the amount of the clip available, and could lead to the same clip
96 being loaded multiple times if you need different regions of the clip
98 2) A westley can be specified as a resource, so westleys can naturally
99 encapsulate other westleys.
104 Playlists provide a 'collection' structure for producers. These can be used
105 to define 'tracks' in the multitrack approach, or simple playlists for
106 sequential, single track playout.
108 As an example, the following defines two basic producers and a playlist with 3
112 <producer id="producer0">
113 <property name="resource">clip1.dv</property>
115 <producer id="producer1">
116 <property name="resource">clip2.dv</property>
118 <playlist id="playlist0">
119 <entry producer="producer0" in="0" out="2999"/>
120 <entry producer="producer1" in="0" out="999"/>
121 <entry producer="producer0" in="3000" out="6999"/>
125 Here we see how the playlist defines the in/out points of the basic
130 1) All in/out points are absolute frame positions relative to the producer
131 being appended to the playlist;
132 2) Westley documents are currently authored for a specific normalisation;
133 3) The last 'producer' in the document is the default for play out;
134 4) Playlists can reference the same producer multiple times. In/out regions
135 do not need to be contiguous - duplication and skipping is acceptable.
138 Interlude - Introducing Multitracks:
140 So far we've defined basic producers and playlists/tracks - the tractor is
141 the element that allows us to arrange our tracks and specify filters and
142 transitions. Similarly to a playlist, a tractor is a container.
144 Note that MLT doesn't see a filter or a transition as a producer in the
145 normal sense - filters and transitions are passive when it comes to seeking.
146 Internally, seeks are carried out on the producers. This is an important
147 point - MLT does not follow a traditional graph oriented model.
149 Visualising an MLT tractor and it's interaction with the consumer will
152 +----------------------------------------------+
154 | +----------+ +-+ +-+ +-+ +-+ |
155 | |multitrack| |f| |f| |t| |t| |
156 | | +------+ | |i| |i| |r| |r| |
157 | | |track0|-|--->|l|- ->|l|- ->|a|--->|a|\ |
158 | | +------+ | |t| |t| |n| |n| \ |
159 | | | |e| |e| |s| |s| \ |
160 | | +------+ | |r| |r| |i| |i| \ | +--------+
161 | | |track1|-|- ->|0|--->|1|--->|t|--->|t|-----|--->|consumer|
162 | | +------+ | | | | | |i| |i| / | +--------+
163 | | | | | | | |o| |o| / | ^
164 | | +------+ | | | | | |n| |n| / | |
165 | | |track2|-|- ->| |- ->| |--->|0|- ->|1|/ | |
166 | | +------+ | | | | | | | | | | |
167 | +----------+ +-+ +-+ +-+ +-+ | |
168 +----------------------------------------------+ |
172 |APPLICATION|--------------------------------------------+
175 Internally, all frames from all tracks pass through all the filters and
176 transitions - these are told which tracks to deal and which regions of the
179 Note that the application communicates with the producer - it can alter
180 playback speed, position, or even which producer is connected to which
183 The consumer receives the first non-blank frame (see below). It has no say
184 in the order in which gets them (the sdl consumer when used with inigo might
185 appear to be an exception - it isn't - it simply has a route back to the
186 application to allow the application to interpret key presses).
191 To create a multitrack westley, we can use two playlists and introduce a
192 tractor. For the purposes of demonstration, I'll add a filter here too:
195 <producer id="producer0">
196 <property name="resource">clip1.dv</property>
198 <producer id="producer1">
199 <property name="resource">clip2.dv</property>
201 <playlist id="playlist0">
202 <entry producer="producer0" in="0" out="2999"/>
203 <blank length="1000"/>
204 <entry producer="producer0" in="3000" out="6999"/>
205 <playlist id="playlist1">
206 <blank length="3000"/>
207 <entry producer="producer1" in="0" out="999"/>
209 <tractor id="tractor0">
211 <track producer="playlist0"/>
212 <track producer="playlist1"/>
215 <property name="track">0</property>
216 <property name="mlt_service">greyscale</property>
221 Here we see that blank frames are inserted into the first playlist and a
222 blank is provided at the beginning of the second - this can be visualised in
223 the traditional timeline widget as follows:
225 +-------+ +-------------+
227 +-------+---+-------------+
231 Adding the filter on the top track, gives us:
233 +-------+ +-------------+
235 +-------+---+-------------+
237 --------+---+-------------+
241 Note that it's only applied to the visible parts of the top track.
243 The requirement to apply a filter to the output, as opposed to a specific
244 track leads us to the final item in the Rules section above. As an example,
245 let's assume we wish to watermark all output, then we could use the
249 <producer id="producer0">
250 <property name="resource">clip1.dv</property>
252 <producer id="producer1">
253 <property name="resource">clip2.dv</property>
255 <playlist id="playlist0">
256 <entry producer="producer0" in="0" out="2999"/>
257 <blank length="1000"/>
258 <entry producer="producer0" in="3000" out="6999"/>
259 <playlist id="playlist1">
260 <blank length="3000"/>
261 <entry producer="producer1" in="0" out="999"/>
263 <tractor id="tractor0">
265 <track producer="playlist0"/>
266 <track producer="playlist1"/>
269 <property name="track">0</property>
270 <property name="mlt_service">greyscale</property>
273 <tractor id="tractor1">
275 <track producer="tractor0"/>
278 <property name="mlt_service">watermark</property>
279 <property name="resource">watermark1.png</property>
284 Here we employ another tractor and we define a single track (being the
285 tractor we previously defined) and apply a watermarking filter there.
287 This is simply provided as an example - the watermarking functionality could
288 be better handled at the playout stage itself (ie: as a filter automatically
289 placed between all producers and the consumer).
291 Tracks act like "layers" in an image processing program like the GIMP. The
292 bottom-most track takes highest priority and higher layers are overlays
293 and do not appear unless there are gaps in the lower layers or unless
294 a transition is applied that merges the tracks on the specifed region.
295 Practically speaking, for A/B video editing it does not mean too much,
296 and it will work as expected; however, as a general rule apply any CGI
297 (graphic overlays with pixbuf or titles with pango) on tracks higher than
298 your video tracks. Also, this means that any audio-only tracks that are
299 lower than your video tracks will play rather than the audio from the video
300 clip. Remember, nothing is affected like mixing or compositing until one
301 applies a transition or appropriate filter.
304 <producer id="producer0">
305 <property name="resource">clip1.dv</property>
307 <playlist id="playlist0">
308 <entry producer="producer0"/>
310 <producer id="producer1">
311 <property name="resource">clip2.mpeg</property>
313 <playlist id="playlist1">
315 <entry producer="producer1"/>
317 <tractor id="tractor0" in="0" out="315">
318 <multitrack id="multitrack0">
319 <track producer="playlist0"/>
320 <track producer="playlist1"/>
322 <transition id="transition0" in="50" out="74">
323 <property name="a_track">0</property>
324 <property name="b_track">1</property>
325 <property name="mlt_service">luma</property>
327 <transition id="transition1" in="50" out="74">
328 <property name="a_track">0</property>
329 <property name="b_track">1</property>
330 <property name="mlt_service">mix</property>
331 <property name="start">0.0</property>
332 <property name="end">1.0</property>
337 A "luma" transition is a video wipe processor that takes a greyscale bitmap
338 for the wipe definition. When one does not specify a bitmap, luma performs
339 a dissolve. The "mix" transition does an audio mix, but it interpolates
340 between the gain scaling factors between the start and end properties -
341 in this example, from 0.0 (none of track B) to 1.0 (all of track B).
342 Because the bottom track starts out with a gap specified using the <blank>
343 element, the upper track appears during the blank segment. See the demos and
344 services.txt to get an idea of the capabilities of the included transitions.
348 The information presented above is considered the MLT Westley "normal"
349 form. This is the output generated by the westley consumer, for example,
350 when used with inigo. It is the output generated when you use the
351 "Westley to File" consumer in the demo script, which beginners will find
352 most useful for learning to use westley XML. This section describes
353 alternative forms the westley producer accepts.
355 First of all, the normal form is more of a linear format with producers
356 and playlists defined prior to their usage in a multitrack. Westley
357 also accepts a hierarchical format with producers as children of tracks
358 or playlist entries and with playlists as children of tracks:
367 <property name="resource">clip1.dv</property>
376 Obviously, this example is meant to demonstrate hierarchy and not effective
377 use of playlist or multitrack!
379 Secondly, as part of error handling, westley is forgiving if you fail to
380 supply <tractor>, <track>, and <entry> where one can be understood. This
381 affords an abbreviated syntax that is less verbose and perhaps less
382 intimidating for a human to read and understand. One can simplify the
389 <property name="resource">clip1.dv</property>
395 Yes, filters and transitions can be added to the above example after the
396 closing multitrack tag (</multitrack>) because it is still enclosed within
397 the westley body tags.
399 If you specify in and out on a producer and it has been enclosed within
400 an <entry> or <playlist>, then the edit points apply to the playlist
401 entry and not to the producer itself. This facilitates re-use of media:
404 <producer id="clip1" in="25" out="78">
405 <property name="resource">clip1.dv</property>
407 <entry producer="clip1" in="119" out="347"/>
410 In the above example, the producer attribute of the entry element is
411 a reference to the preceding producer. All references must follow the
412 definition. The edit points supplied on the producer above will not affect
413 the entry that references it below because westley knows the clip is a
414 playlist entry and optimises this situation. The advantage is that one
415 does not need to determine every clip to be included ahead of time
416 and specify them outside the context of the mutlitrack timeline.
418 This form of authoring will be easier for many to visualise as a non-linear
419 editor's timeline. Here is a more complex example:
424 <producer id="foo" in="100" out="149">
425 <property name="resource">clip2.mpeg</property>
428 <entry producer="foo" in="10" out="59"/>
432 <producer id="bar" in="100" out="199">
433 <property name="resource">clip3.mpeg</property>
435 <entry out="99" producer="bar"/>
438 <filter mlt_service="greyscale" track="0"/>
439 <transition mlt_service="luma" in="25" out="49" a_track="0" b_track="1"/>
440 <transition mlt_service="luma" in="75" out="99" a_track="0" b_track="1">
441 <property name="reverse" value="1"/>
445 Did you notice something different in the last example? Properties can be
446 expressed using XML attributes on the element as well. However, only
447 non-service-specific properties are supported in this way. For example,
448 "mlt_service" is available to any producer, filter, or transition. However,
449 "resource" is actually service-specific. Notice the syntax of the last
450 property, on the last transition. Westley accepts property values using
451 the "value" attribute as well as using element text.
453 We have seen a few different ways of expressing property values. There are
454 a couple more for properties that can accept XML data. For example, the
455 GDK pixbuf producer with librsvg can handle embedded SVG, and the Pango
456 producer can handle embedded Pango markup. You can enclose the embedded XML
457 using a CDATA section:
459 <property name="resource"><![CDATA[ <svg>...</svg> ]]></property>
461 Please ensure the opening CDATA tag immediately follows the opening
462 property tag and that the section closing tag immediately precedes the
463 closing property tag.
465 However, westley can also accept inline embedded XML:
467 <property name="resource">
472 Currently, there is no namespace handling so a conflict will occur only on
473 any embedded XML that contains an element named "property" because
474 westley collects embedded XML until it reaches a closing property tag.
477 Entities and Parameterisation:
479 The westley producer parser supports XML entities. An example:
481 <?xml version="1.0"?>
483 <!ENTITY msg "Hello world!">
486 <producer id="producer0">
487 <property name="mlt_service">pango</property>
488 <property name="text">&msg;</property>
492 If you are embedding another XML document into a property value not using
493 a CNODE section, then any DOCTYPE section must be relocated before any of
494 the xml elements to be well-formed. See demo/dvg.westley for an example.
496 Entities can be used to parameterise westley! Using the above example, the
497 entity declared serves as the default value for &msg;. The entity content
498 can be overridden from the resource property supplied to the westley
499 producer. The syntax is the familiar, url-encoded query string used with
500 HTTP, e.g.: file?name=value&name=value...
502 There are a couple of rules of usage. The Miracle LOAD command and inigo
503 command line tool require you to preface the URL with "westley:" because
504 the query string destroys the filename extension matching peformed by
505 Fezzik. Also, inigo looks for '=' to tokenise property settings. Therefore,
506 one uses ':' between name and value instead of '='. Finally, since inigo
507 is run from the shell, one must enclose the URL within single quotes to
508 prevent shell filename expansion, or similar.
510 Needless to say, the ability to parameterise westley XML compositions is
511 an extremely powerful tool. An example for you to play with is available in
512 demo/entity.westley. Try overriding the name from inigo:
513 inigo 'westley:entity.westley?name:Charlie'
515 Technically, the entity declaration is not needed in the head of the XML
516 document if you always supply the parameter. However, you run the risk
517 of unpredictable behviour without one. Therefore, it is safest and a best
518 practice to always supply an entity declaration. It is improves the
519 readability as one does not need to search for the entity references to
520 see what parameters are available.
525 If one finds the above hierarchical, abbreviated format intuitive,
526 start with a simple template and fill and extend as needed:
531 ...add a playlist for each track...
533 ...add filters and transitions...
536 By using a playlist for each track, it is easier to iteratively add new
537 clips and blank regions as you develop the project. You will not have to
538 use <track> or later add <playlist> when necessary.
540 A more advanced template that allows sequencing multitracks is:
546 ...add a playlist for each track...
548 ...add filters and transitions...
555 ...add a playlist for each track...
557 ...add filters and transitions...
561 If you end up making a collection of templates for various situations, then
562 consider using XML Entities to make the template more effective by moving
563 anything that should parameterised into an entity.
565 If you want to have a silent, black background for audio and video fades,
566 then make the top track simply <producer mlt_service="colour"/>. Then,
567 use composite and volume effects. See the "Fade from/to black/silence"
568 demo for an example (demo/mlt_fade_black).
570 If you apply the reverse=1 property to a transition like "luma," then
571 be careful because it also inherently swaps the roles of A and B tracks.
572 Therefore, you need to might need to swap the a_track and b_track values
573 if it did not turn out the way you expected. See the "Clock in and out"
574 for an example (demo/mlt_clock_in_and_out).