Drastic DDR MediaCmd SDK
The Drastic MediaCmd SDK is the mechanism by which all the elements of Drastic's DDRs communicate with one another. The control features provided within the SDK include the following:
VTR Emulation - Receiving commands from 9 pin Serial Controllers via Sony, Odetics or VDCP protocol. Receiving commands from Drastic GUIs, Servers and Controllers
Controller - Controlling VVW or Titan Series DDR Servers, Drastic DDR software locally, and Drastic DDR software licensed to support network option remotely. Controlling 9 pin serial VTRs and Servers via Sony, Odetics or VDCP protocol
HTML/Ajax - Building HTML/Ajax status and control pages
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, 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 is 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 QuickClip/Drastic DDR software installed on your development system. Even if your target application will only use a part of the software, it should all be installed for the development phase. Before proceeding with the SDK you should familiarize yourself with Drastic DDR software's operation and tool set. The DDR elements available within QuickClip/Drastic DDR are the same elements available to your application through the SDK.
Once you have QuickClip/Drastic DDR installed, you should install the MediaCmd SDK. This will install the headers, libraries and source needed to control QuickClip/Drastic DDR from your application.
Choosing An Access Method
The SDK access method you should use depends on what 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:
Type: Microsoft ActiveX/COM access method
Pros: Easy to program, 1:1 relationship with QuickClipXO interface.
Cons: Uses same configuration as QuickClip/XO. Requires a local copy of QuickClip/Drastic DDR software.
Setup: Register VVW.DLL using RegSvr32.exe in the QuickClip/Drastic DDR 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.
Type: Direct link to VVW.dll, libvvw.so, vvw.dylib
Pros: No ActiveX layer, code compatible with Linux, Irix, Mac OS-X.
Cons: Uses default configuration from QuickClipXO, application must be run in QuickClip/Drastic DDR directory. Requires a local copy of QuickClip/Drastic DDR software.
Setup: Link to vvw.lib, include vvw.h. Copy application into the QuickClip/Drastic DDR directory before running
Issues: Needs access to VVW.dll and all its support DLLs/D1Xs. Still needs to be setup by DDRConfig.exe or QuickClipXO
Type: XML command interchange with the DDR internal HTTP server, optionally wrapped as SOAP
Pros: Standard, multi language, multi platform.
Cons: Not as fast or efficient as direct connection.
Setup: Standard on version 3 and 4 Drastic DDRs
Issues: Soap is optional, contact Drastic
Command Line App
Type: Network connection, command line sender
Pros: Standard, multi platform (Windows, OS-X, Linux).
Cons: Single command or command list, not interactive.
Issues: Command line.
Type: Direct line to vvwNet2.dll, libvvwnet2.so, vvwnet2.dylib
Pros: Consistent interface between local/remote and various OSs. Does not require a local copy of QuickClip/Drastic DDR software.
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/Drastic DDR configuration issues. Requires a few DLLs 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.
Type: Direct compile of network sources in your application or your DLL.
Pros: No extra DLLs. Easy to customize and modify. Lots of commands already written.
Cons: You application 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.
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.
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 them will always be the same:
\BIN – Copies of the minimum DLL set from a QuickClip/Drastic DDR 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/Drastic DDR
\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 subdirectories based on access type
\ActiveX – Examples that use the ActiveX control
\Direct – Examples that link directly to DLLs
\Java – Java based examples
\HTTP – Ajax based examples (must use QuickClip HTTP server to run)
Low Level Header Documentation
HTTP XML AJAX SOAP Documentation
Command Line Documentation
Version 3 (Deprecated) API Documentation
Pricing for this SDK is offered in the form of a quote, based on the product you are making, its application and market, and projected quantities. All information provided is considered non-binding and would be treated as confidential.