X-Git-Url: http://research.m1stereo.tv/gitweb?a=blobdiff_plain;f=docs%2Fmelted%2B%2B.txt;h=78863e7251b0825ef62892d897de78559230f7a5;hb=07a6c505e67f743795cd36c8c22e6214ea6c0a7f;hp=711d901c337133772643562039f007bdffab9129;hpb=f5a43889f0ea29962f2d32b5dab0fcd25bebb945;p=melted diff --git a/docs/melted++.txt b/docs/melted++.txt index 711d901..78863e7 100644 --- a/docs/melted++.txt +++ b/docs/melted++.txt @@ -7,26 +7,26 @@ Last Revision: 2009-05-14 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 using namespace std; - #include + #include using namespace Mlt; int main( int argc, char **argv ) { - Miracle server( "miracle++", 5290 ); + Melted server( "melted++", 5290 ); if ( server.start( ) ) { server.execute( "uadd sdl" ); @@ -42,9 +42,9 @@ THE BASIC CUSTOM SERVER 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 @@ -55,24 +55,24 @@ CUSTOMISATION 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 * pushing documents * handling pushed documents - * accessiving events + * accessing 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( ); @@ -99,29 +99,29 @@ EXTENDING THE COMMAND SET #include using namespace std; - #include + #include #include 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" ); @@ -142,7 +142,7 @@ EXTENDING THE COMMAND SET (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. @@ -167,10 +167,10 @@ ACCESSING UNIT PROPERTIES 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. @@ -185,11 +185,11 @@ ACCESSING UNIT PROPERTIES 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. @@ -218,7 +218,7 @@ THE RESPONSE OBJECT 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 @@ -255,32 +255,32 @@ PUSHING DOCUMENTS A server process would be running as follows: - #include + #include 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 @@ -289,7 +289,7 @@ HANDLING PUSHED DOCUMENTS 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 @@ -329,11 +329,11 @@ HANDLING PUSHED DOCUMENTS 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 @@ -347,7 +347,7 @@ OTHER MANIPULATIONS 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: @@ -387,12 +387,12 @@ EVENT HANDLING 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