The XML-File

XML is a markup language for documents containing structured information.

Studio 9 is using an XML-File to describe the user interface of an effect.
For the VirtualDubShell Vdub2RTFX I enhanced this XML-file with additional information. In this chapter I will describe these enhancements.

A typical vdubrtfx-xml-file  contains following information:( e.g. dummyfilter1.xml)

<EffectDescriptor name="DummyFilter1" type="VideoFilter">

<UIObject name="DummyFilter1" rackname="Filter" foldername="HL's VD-Filter" piconname="" />

<Property guid="35e7ce00-4872-11d0-90c3-0000e8ce8250"  subguid="42134168-1209-4c14-860F-1DFF4F0D09B6">

<parameter name="FILTERDATA" id="0" type="opaque" />

</Property>

<EditorVDUB name="DummyFilter1" type="CustomUI" />

<VDUB>

<Compatibility>

<atSequenceBegin InitProc="no" StartProc="yes" ReadParams="yes" />

<atSceneBegin      InitProc="no" StartProc="yes" ReadParams="yes" />

<atEveryFrame                                                        ReadParams="no" />

<atParamChange   InitProc="no" StartProc="yes" ReadParams="yes" />

<General OneInstance="no" MFDOffset="0" MFDSize="0"/>

</Compatibility>

</VDUB>

</EffectDescriptor>

Description of the sections:

<Effectdescriptor>, <UIObject> and <Property> are defined and used by Studio 9.

<VDUB>
 is the section I added to the file. This section is ignored by Studio 9. This is the big advantage of xml-files.

<EditorVDUB>
defines the type of user interface to use for the VDUB-filters
type = “CustomUI” - the original user interface of the virtualdub filter is used
type = “StudioUI” - the Studio user interface is used, the user interface has to be defined in this XML-file

<compatibility>
provides means to adapt the behavior of a vdub-filter to studio.

To be able to use these parameters you need to understand the difference in the filter usage of virtualdub and studio.

Virtualdub is using following simplified sequence for rendering videos:

1. the filter is loaded
2. initialisation of the filter (InitProc)
3. define the filter parameters via a dialogbox
4. add additional filters
5. start rendering
6. start every filter (StartProc) - allocation of local memory for the filter, precalculation of data
7. process every single frame
8. end rendering

The renderprocess is running for the complete video loaded.

For storing the parameters of the filter, virtualdub is using a table called "myFilterData" (MFD-Table).

Unfortunately the filter is not only storing the filter parameters in this table, but additional local information like pointers to local memory frames or other internal data is stored here too. This data is normaly defined in the "StartProc" and may be dependend on the input parameters.

Studio works different:

Studio devides the video into scenes. For every scene you may use different filters with differnt parameters.

During "Editing" you can jump through the video as you like. At every frame of the video Studio is passing the current effect parameters to the filter. So the preview image is calculated with the right parameters wherever you jump. (this is the theory)

Only the render-sequence seams to be linear. But this is not true. During final rendering Studio is rendering the high resolution video and at the same time with lower priority the low resolution preview video.

With the compatibilty parameters you can adapt the vdub-filter behavior to the studio behavior.

The vdub2rtfx-plugin defines several states of the filter:

• Filter LOADED
• Filter in use (the filter is assigned to a scene) -> a new MFD-table is created, the InitProc of the virtualdub-filter is called
• ParamChange (the filter parameters are changed using the original vdub-filter-dialog) -> parameters are stored in the mfd-table
• SequenceBegin (a render sequence is started)-> The parameters should be read from Studio and stored in the MFD-table and the "StartProc" should be called.
• SceneBegin (a new scene starts) -> the parameters may have changed and have to be read again from Studio and stored in the MFD-table, if the result of the "StartProc" is dependand on the filter-parameters the "StartProc" has to be called.
• EveryFrame (a frame is processed) -> normaly the filter params are read from Studio every frame. Unfortunatly this may destroy the local information stored in the mfd-table. So for most of the vdub-filter it is better to not read the params at every frame.

In the <compatibility> section you can change this behavior:

• <atSequenceBegin> defines what happens when a sequence starts
• <atSceneBegin>   defines what happens when a scene starts
• <atParamChange>   defines what happens after the parameter dialog was opened
• <atEveryFrame>   defines what happens at every frame

possible actions are:

• InitProc = yes, the vdub filter is initilaised
• StartProc = yes, the virtualdub filter may allocate memory and precalculate data
• ReadParams = yes, the parameters are read from Studio and the mfd-table is overwritten with this data

<general> defines some general parameters

• OneInstance = yes, the vdub2rtfx-plugins tries to simulate the virtualdub single instance rendering by omitting the preview rendering. (should be need not necessary anymore)
• MFD-Offset and MFDSize - define the begin and the size of real parameter section in the mfd-table. This allows the plugin to skip the local values the vdubfilter stored in the mfd-table making reading of parameters more robust. This allows normaly the reading of the parameters at every frame, making the preview more save.
• To be able to determine the offset and size of the mfd-table there is a hidden parameter available:
  MFDShow = yes, writes a hexdump of the MFD-table before and after the parameter-dialog was opened to a file called "logfile.txt". This file is located in the studio 9 program directory.