INTRODUCTION
- This document describes how miracle can be customised. The emphasis is on
+ This document describes how melted can be customised. The emphasis is on
showing simple examples of various aspects of the servers capabilities
- rather than on focussing on the MLT++ API.
+ rather than on focussing on the MLT API.
THE BASIC CUSTOM SERVER
- The most basic custom server exposes the entire DVCP protocol and is roughly
- equivalent to the miracle server iteself, but in this case, it lacks the
- initialisation from /etc/miracle.conf and the port is hardcoded to 5290:
+ The most basic custom server exposes the entire MVCP protocol and is roughly
+ equivalent to the melted server iteself, but in this case, it lacks the
+ initialisation from /etc/melted.conf and the port is hardcoded to 5290:
#include <iostream.h>
using namespace std;
- #include <MltMiracle.h>
+ #include <MltMelted.h>
using namespace Mlt;
int main( int argc, char **argv )
{
- Miracle server( "miracle++", 5290 );
+ Melted server( "melted++", 5290 );
if ( server.start( ) )
{
server.execute( "uadd sdl" );
Note that after the server is started, this example submits the hard coded
commands specified - further units and property settings can of course be
- specified via the DVCP protocol.
+ specified via the MVCP protocol.
- To specify initial DVCP commands from /etc/miracle.conf, it is sufficient to
+ To specify initial MVCP commands from /etc/melted.conf, it is sufficient to
specify an additional argument in the server constructor.
The wait_for_shutdown call is not required if the server is integrated in
This document focusses on the following areas of customisation:
- * the Miracle server class
+ * the Melted server class
* extending the command set
* accessing the units
* the Response object
* accessiving events
-THE MIRACLE SERVER CLASS
+THE MELTED SERVER CLASS
The full public interface of the server is as follows:
- class Miracle : public Properties
+ class Melted : public Properties
{
public:
- Miracle( char *name, int port = 5290, char *config = NULL );
- virtual ~Miracle( );
+ Melted( char *name, int port = 5290, char *config = NULL );
+ virtual ~Melted( );
mlt_properties get_properties( );
bool start( );
bool is_running( );
#include <sstring>
using namespace std;
- #include <MltMiracle.h>
+ #include <MltMelted.h>
#include <MltResponse.h>
using namespace Mlt;
class Custom :
- public Miracle
+ public Melted
{
public:
Custom( char *name = "Custom", int port = 5290, char *config = NULL ) :
- Miracle( name, port, config )
+ Melted( name, port, config )
{
}
Response *execute( char *command )
{
cerr << "command = " << command << endl;
- return Miracle::execute( command );
+ return Melted::execute( command );
}
};
int main( int argc, char **argv )
{
- Custom server( "miracle++", 5290 );
+ Custom server( "melted++", 5290 );
if ( server.start( ) )
{
server.execute( "uadd sdl" );
(5) Starting server on 5290.
command = uadd sdl
- (5) miracle++ version 0.0.1 listening on port 5290
+ (5) melted++ version 0.0.1 listening on port 5290
command = play u0
(7) Received signal 2 - shutting down.
unit( i ++ )->debug( );
return new Response( 200, "Diagnostics output" );
}
- return Miracle::execute( command );
+ return Melted::execute( command );
}
- When this runs and you send a 'debug' command via DVCP, the server will output
+ When this runs and you send a 'debug' command via MVCP, the server will output
some information on stderr, like:
(5) Starting server on 5290.
Playlist playlist( ( mlt_playlist )( unit( i )->get_data( "playlist" ) ) );
Consumer consumer( ( mlt_consumer )( unit( i )->get_data( "consumer" ) ) );
- and use the standard MLT++ wrapping methods to interact with them or you can
+ and use the standard mlt++ wrapping methods to interact with them or you can
bypass these and using the C API directly.
Obviously, this opens a lot of possibilities for the types of editing operations
- than can be carried out over the DVCP protocol - for example, you can attach filters
+ than can be carried out over the MVCP protocol - for example, you can attach filters
apply mixes/transitions between neighbouring cuts or carry out specific operations
on cuts.
response->write( output.str( ).c_str( ) );
}
}
- return response == NULL ? Miracle::execute( command ) : response;
+ return response == NULL ? Melted::execute( command ) : response;
}
Now when you connect to the server via a telnet session, you can access the
A server process would be running as follows:
- #include <mlt++/Miracle>
+ #include <melted++/Melted>
using namespace Mlt;
int main( void )
{
- Miracle miracle( "miracle", 5250 );
- miracle.start( );
- miracle.execute( "uadd sdl" );
- miracle.execute( "play u0" );
- miracle.wait_for_shutdown( );
+ Melted melted( "melted++", 5250 );
+ melted.start( );
+ melted.execute( "uadd sdl" );
+ melted.execute( "play u0" );
+ melted.wait_for_shutdown( );
return 0;
}
Typically, when you have an MLT object such as a producer or a playlist,
you can send a XML representation of this to a running server with:
- Consumer mvsp( "mvsp", "localhost:5250" );
- mvsp.connect( producer );
- mvsp.start( );
+ Consumer mvcp( "mvcp", "localhost:5250" );
+ mvcp.connect( producer );
+ mvcp.start( );
The effect of the push will be to append the producer on to the first
unit (u0).
HANDLING PUSHED DOCUMENTS
- The custom class receives PUSH'd westley either via the received or push
+ The custom class receives PUSH'd MLT XML either via the received or push
method.
The default handling is to simply append a pushed document on to the end of
You can test this in the server defined above from the command line, for
example:
- $ inigo noise: -consumer valerie:localhost:5290
+ $ melt noise: -consumer mvcp:localhost:5290
By default, the 'push' method is used - this means that the xml document
received is automatically deserialised by the server itself and then offered
Response *received( char *command, char *document )
{
cerr << document;
- Producer producer( "westley-xml", document );
+ Producer producer( "xml-string", document );
return push( command, &producer );
}
- When you push your videos in to the server via the inigo command above (or
+ When you push your videos in to the server via the melt command above (or
from other tools, such as those in the shotcut suite), you will see the xml
in the servers stderr output. If you need to carry out some operations on the
xml document (such as replacing low quality videos used in the editing process
you have flexibility in how the item is scheduled and you can carry out
manipulations on either the xml document and/or the deserialised producer.
- Typically, shotcut and inigo produce 'tractor' objects - these can be easily
+ Typically, shotcut and melt produce 'tractor' objects - these can be easily
manipulated in the push method - for example, to remove a track from the
output, we could do something like:
on 'consumer-frame-render' - this event is fired immediately before a frame
is rendered.
- See example in test/server.cpp
+ See example in src/examples/server.cpp
-DISABLING DVCP
+DISABLING MVCP
- In some cases, it is desirable to fully disable the entire DVCP command set
+ In some cases, it is desirable to fully disable the entire MVCP command set
and handle the PUSH in an application specific way (for example, the shotcut
applications all do this). The simplest way of doing this is to generate a
response that signifies the rejection of the command. In this example, the
projects / melted / blobdiff