|
MediaCMD4API MediaCMD4
MediaCMD 4 API Help File
|
The Drastic MediaCmd SDK is the mechanism by which all the elements of Drastic's DDRs communicate with one and other. This includes:
Controlling Drastic Titan and VVW Series DDR Servers, QuickClip locally, and QuickClip with network option remotely Controlling 9 pin serial VTRs and Servers via Sony, Odetics or VDCP protocol Receiving commands from 9 pin serial controller via Sony, Odetics or VDCP protocol Receiving commands from Drastic GUIs, servers and controllers Building HTML/Ajax status and control pages
MediaCmd is the communication method used within Drastic's DDR products. Any operation you see in a Drastic interface is available to your application through MediaCmd.
MediaCmd is a simple structure that supports a small, well defined set of commands for communicating transport, status and setup information between components in Drastic's DDR software. There are a number of fields in the structure, but the important fields are:
ctCmd ñ the primary command of this packet (Play, Pause, Stop, Record, etc) lSpeed ñ the transport speed for any play commands (integer where 65520 = normal forward play) dwPosition ñ the frame position for any play, pause or record commands dwStart ñ the starting frame for any play or record commands (inclusive) dwEnd ñ the ending frame for any play or record commands (exclusive) arbID ñ clip name, file name or other string/binary data for the command cfFlags ñ denotes which fields above are valid and their meaning
With the standard initialization of the structure, you can quickly build commands in this structure by changing a few members and sending it. The primary motion commands are ctPlay, ctPause, ctStop, ctRecStop, ctRecord, ctEject and ctTransfer. To get the current state (position, speed, start and end, current clip), the command ctGetState will return a filled in MediaCmd. For setup and less common status (e.g. video input, audio rms level, genlock) there is ctGetValue and ctSetValue. This is documented in the Low Level Header Docs.
Hopefully, you will not have to deal with the MediaCmd structure directly. The SDK includes a series of simple commands that should provide 99% of what your application needs. These functions are simply wrappers that create and send MediaCmd structures. The source for all these functions is provided in the SDK under SRC/General/vvwIF.cpp in case you need to modify or create new commands. The commands have slightly different names depending on which interface you use, but have the same root name, such as: Play(), PlayFromTo(), Stop(), Pause(), Seek(), Record() and UpdateStatus(). Commands are also included for getting clip lists (GetNextClip()) and EDL elements from ::VTR_TC time code spaces (EDLResetToStart(), EDLGetEdit()). A selection of the most common settings are also included (SetVideoInput(), SetAudioInput(), SetVideoGenlock(), GetAudioPeakRMS(), etc). This interface is documented in the MediaCmd Documentation (previously called ìVVW Interface Specificationî).
To properly work with the MediaCmd SDK, you should have a copy of the QuickClip software installed on your development system. Even if your target application will only use a part of the QuickClip software, it should all be installed for the development phase. Before proceeding with the SDK you should familiarize your self with QuickClip's operation and toolset. All the elements available within QuickClip are the same elements available to your application through the SDK. Once you have QuickClip installed, you should install the MediaCmd SDK. This will install the headers, libraries and source needed to control QuickClip from your application.
The SDK access method you should use depends on what you you would like your application to do, what programming language you are using and how involved you would like to/need to get in the low level MediaCmd structures. No matter which method you choose, the MediaCmd structure packets are exactly the same. Here are the main access methods, with their pros and cons:
ActiveX
Type: Microsoft ActiveX/COM access method
Pros: Easy to program, 1:1 relationship with QuickClip/XO interface.
Cons: Uses same config as QuickClip/XO. Requires a local copy of QuickClip.
Setup: Register VVW.DLL using RegSvr32.exe in the QuickClip installation directory.
Issues: Difficult to use when communicating via TCP/IP within the same machine. Can be overcome by using the default pipe communication system, but this requires changes for remote network control.
Direct Link
Type: Direct link to VVW.DLL
Pros: No ActiveX layer, code compatible with Linux, Irix, Mac OS-X.
Cons: Uses default config from QuickClip/XO, application must be run in QuickClip directory. Requires a local copy of QuickClip.
Setup: Link to vvw.lib, include vvw.h. Copy application into the QuickClip directory before running
Issues: Needs access to VVW.dll and all its support DLLs/D1Xs. Still needs to be setup by LocalConfig.exe or QuickClip/XO
Network DLL
Type: Direct line to vvwNet2.dll
Pros: Consistent interface between local/remote and various OSs. Does not require a local copy of QuickClip.
Cons: Requires vvwNet2.dll and support dlls
Setup: Link to vvwNet2.lib, include vvwNet2.h. Copy dll set from SDK/bin directory with your application
Issues: Use the netOpenLocal function to avoid QuickClip configuration issues. Requires a few dDLLs to be added to your application installations. Does not run the client software automatically, so your application may need to start it, depending on what your application is doing.
Network Direct
Type: Direct compile of network sources in your app or your DLL.
Pros: No extra dlls. Easy to customize and modify. Lots of commands already written.
Cons: You app needs to handle setup and may need to run QuickClip.exe/VVWServer.exe/QCRun.exe.
Setup: Copy source files from vvwNet2 into your project, modify and compile
Issues: Does not run the client software automatically, so your application may need to start it, depending on what your application is doing.
Manual
Type: Use the structures and defines to write your own communication and control layer.
Pros: This is required if you are using an unsupported development platform like PHP.
Cons: Everything has to be built and tested from the ground up.
Setup: None.
Issues: Unless you absolutely have to, this method is not recommended.
The location of the SDK directories will depend on the location you choose during the installation, but the directories within there will always be the same:
/BIN ñ Copies of the minimum dll set from a QuickClip installation. /LIB ñ Libraries required to link the vvwNet2.dll, examples and your application /INC ñ Header files required to compile vvwNet2.dll, examples and your application /Src/vwwNet2 ñ The source to our vvwNet2.dll from QuickClip /Src/General ñ Useful source files that do not compile into examples directly. The most important would be vvwIF.cpp that is the code behind the SDK functions described below. /Sample ñ Broken down into sub directories based on access type o /ActiveX ñ Examples that use the ActiveX control o /Direct ñ Examples that link directly to DLLs o /Java ñ Java based examples o /HTTP ñ Ajax based examples (must use QuickClip HTTP server to run)
PDF version of the MediaCmd Documentation http://www.drastictech.com/manuals/VVW%20Interface%20Specification.pdf
Online version of the MediaCmd Documentation http://www.drastictech.com/manuals/VVW%20Interface%20Specification.html
Windows CHM help file version of the MediaCmd headers http://www.drastictech.com/manuals/MediaCmd.chm
Online version of the MediaCmd headers http://www.drastictech.com/manuals/mediacmd/
Wiki area for HTTP XML MediaCmd http://www.drasticpreview.org/wakka.php?wakka=DrasticHttpCommands&v=d9c
1.7.3