Understanding Property Prefixes in MPlatform SDK

Medialooks SDKs utilize a hierarchical configuration system that allows control over objects, devices, and underlying subsystems. When modifying settings at runtime via PropsSet(), certain properties require specific prefixes (such as object::, device::, file::, or encoder::), while others do not.

This article describes the structure of the property tree, the mechanisms of property storage, and the rules for using property prefixes in both MPlatform and MFormats SDKs.

The Core Concept: Prefixes Are Just Paths

[Property Tree Root]
 ├── object
 │    └── mirror
 │
 ├── device
 │    └── vanc.capture_cc
 │
 └── file
      └── info
           └── duration

The underlying rule is: Prefix = Property Tree Node Name.

Where Do Property Values Come From?

Windows Registry (Lowest Priority)
       ↓
Local.Config.xml
       ↓
PropsSet() (Highest Priority)

Level 1: Windows Registry (Lowest Priority)

The Windows Registry contains global, system-wide default values for SDK objects. These values are loaded during object instantiation.

• HKCU\Software\Medialooks\MPlatform\MFile

• HKCU\Software\Medialooks\MPlatform\MLive

• HKCU\Software\Medialooks\MPlatform\MMixer

• HKCU\Software\Medialooks\MPlatform\MPlaylist

• HKCU\Software\Medialooks\MPlatform\MPreview

• HKCU\Software\Medialooks\MPlatform\MRenderer

• HKCU\Software\Medialooks\MPlatform\MWriter

Registry settings are useful when you want to change default behavior for all applications on a machine.

Level 2: Local.Config.xml

The Local.Config.xml file is loaded from the directory where Medialooks.Runtime.x64.dll is located. Values defined in this file override the Windows Registry settings.

<config>
    <data key="MPlatform\MPlaylist">
        <attributes dynamic="false" loop="true" background="colorbars-ntsc" />
    </data>
    <data key="MFormats\MFLive\MFDeviceSCR">
        <attributes capture.show_mouse="show" capture.fps_limit="30.0" />
    </data>
</config>

The attributes defined in XML correspond directly to properties exposed through PropsGet() and PropsSet().

Local.Config.xml can be used to deploy application-specific defaults without modifying source code or Registry values.

Level 3: PropsSet() (Highest Priority)

Properties assigned through PropsSet() override both Registry and XML settings for the lifetime of that object instance.

(myPlaylist as IMProps).PropsSet("loop", "true");

Configuration Priority Example

If the same property exists in multiple places:

• Registry: loop=false

• Local.Config.xml: loop=false

• Code: (myPlaylist as IMProps).PropsSet("loop", "true");

The final runtime value becomes: loop=true (the code override wins).

The Statistics Application

The Statistics application displays the final property tree after all configuration sources have been merged. It can be used to:

• Inspect real-time property values.

• Identify available properties and their exact paths.

• Test configuration adjustments at runtime without rebuilding the application.

Open the Statistics application, locate the property in the tree, and use its parent node name as the prefix. Once you understand that prefixes are simply paths inside the property tree, it becomes much easier to work with MPlatform configurations, Registry settings, Local.Config.xml, and runtime overrides.

Object-Specific Property Groups

MFile, MLive, MMixer and MPlaylist

These objects organize their properties into multiple nodes, such as object, device, file, background, or stat. General object settings are exposed through the object node and therefore require the object:: prefix.

(myLive as IMProps).PropsSet("object::mirror", "horz");
(myFile as IMProps).PropsSet("object::deinterlace", "true");

MFile

• Common nodes: object, file, file::info, file::stat

• Context: Properties inside file:: relate to the currently opened media file rather than the MFile object itself.

string duration;
string fps;
(myFile as IMProps).PropsGet("file::info::duration", out duration);
(myFile as IMProps).PropsGet("file::stat::fps", out fps);

File-engine-specific configuration is typically associated with the MPlatform\MFile\MFileFFM registry/XML branch.

MLive

The MLive object configuration depends directly on the active hardware device or capture engine selected. Unlike general object settings, there is no single global set of device properties. Instead, the configuration tree dynamically maps the device:: prefix to a specific sub-node corresponding to the active hardware type and instance.

In the storage layer (Registry or Local.Config.xml), device properties are organized into specific separate sub-nodes under the MFormats\MFLive branch:

MFormats\MFLive (General MLive settings)
 ├── AJA2 (Properties specific to all AJA devices)
 ├── BMD (Properties specific to all Blackmagic Design devices)
 │    ├── DeckLink IP/SDI HD (Properties for this specific model)
 │    └── DeckLink IP/SDI HD (2) (Properties for the second instance of this model)
 ├── DShow (Properties for DirectShow capture engine)
 ├── MFDeviceSCR (Properties for Screen Capture engine)
 └── NDI (Properties for NDI streams)

Because different capture technologies require fundamentally different parameters, the properties available under the device:: prefix change entirely depending on what device is currently initialized.

• Blackmagic Design (BMD): To configure VANC lines data capture, the properties are routed to the BMD sub-node:

  (myLive as IMProps).PropsSet("device::vanc.capture_cc", "true");

• Screen Capture (MFDeviceSCR): To control cursor visibility, the property maps to the Screen Capture sub-node:

  (myLive as IMProps).PropsSet("device::capture.show_mouse", "false");
  

  Attempting to set device::capture.show_mouse while a DeckLink card is active has no effect, as that property does not exist within the BMD node structure.

Device configurations are instance-specific; modifying a property for one hardware device does not apply to other devices.

MMixer

• Common nodes: object, background, background::file, background::object, background::stat

(myMixer as IMProps).PropsSet("background::file", "c:\\background.png");

These properties configure the mixer's background subsystem.

Runtime Background Changes: Background properties define the mixer's startup configuration. To change the background dynamically while the mixer is already running, use the StreamsBackgroundSet() method instead of modifying background properties.

MPlaylist

MPlaylist contains several historical root-level properties such as:

(myPlaylist as IMProps).PropsSet("loop", "true");
(myPlaylist as IMProps).PropsSet("dynamic", "true");

These properties are located directly in the root node of the property tree and therefore do not require the object:: prefix.

Objects That Do Not Use object::

MPreview and MRenderer

Most MPreview and MRenderer properties are stored directly in the root node of the property tree. Because of that, no prefix is required.

• Correct: (myPreview as IMProps).PropsSet("mirror", "horz");

• Incorrect: (myPreview as IMProps).PropsSet("object::mirror", "horz");

MWriter

Most MWriter properties are also stored in the root node. These properties do not require additional prefixes. Encoder-specific configuration is typically associated with the MPlatform\MWriter\MWriterFFM branch.

Prefix Identification Method

To identify whether a property requires a prefix, inspect the object via the Statistics application:

1. Open Statistics.

2. Select your active object.

3. Locate the property in the tree view.

4. Use the parent node name as the prefix.

What About MFormats SDK?

MFormats uses a much simpler property model. Properties are accessed directly without prefixes:

(myLive as IMProps).PropsSet("mirror", "horz");

Property paths in MFormats are accessed directly and do not require object::, device::, file::, or encoder:: prefixes.