Composer Runtime Version
  • 19 Mar 2024
  • 4 Minutes to read
  • Dark
  • PDF

Composer Runtime Version

  • Dark
  • PDF

Article summary


The Composer Runtime Version is a stand-alone application (and a separate installer package) for playback of projects outside the Desktop version. 

The runtime supports almost all desktop version features without a graphical interface (GUI). The runtime version is a console application designed for running projects - not designing projects.

In most use cases, the running project is in read-only mode, meaning that Composer Runtime Version cannot change the project file or the setting file.

The runtime version is available on both Linux and Windows platforms and utilizes GPUs and other system resources similar to how the desktop version does. 

Furthermore, the runtime version supports (or will support) the same features (excluding the user interface) as the desktop version.

On the Windows platform, the runtime version needs to be launched with elevated user permissions (Administrator). Otherwise, the settings.xml cannot be created at the first application start, and the application will not be able to create backups of apikeys.json.

Use cases

As mentioned above, the runtime version is designed for the playback of predesigned Composer projects. For designing Composer projects, the desktop version should be used.

 The most common use case is to use the Desktop version (Windows) to create the project (scenes, assets, operators, connectors, targets, etc.) and use the runtime version for playback.

After the project has been set up and approved by the customer/PO, there might be use cases where you do not want to run the desktop version in production. There might be several reasons for this:

  • Expensive Windows license costs
  • Easier deployment (Containers)
  • A more secure setup (read-only projects)

Prototyping and development

Most graphics designers, video editors, video compositors, and special effects experts are familiar with application GUI:s similar to Composer running on the Windows Desktop Platform, OSX Platform, or via a Web Gui. Composer works well in these use cases, but for production/playback, an extensive GUI is not needed.

This is where the runtime version comes into play.

Exporting projects and assets from Composer Desktop to Composer Runtime Version

To deploy a project to the runtime version, the following steps are recommended:

  • Desktop version: Use relative paths using media located in the application Media folder. Do not use files from other locations, except if the path is the same runtime environment. If the runtime version is Linux, the paths are likely not the same as on the Windows platform.
  • You can use the Collect media to move media to the Media folder.
  • If you plan to use the Linux platform for the runtime version, make sure you use the platform-independent versions of Decklink in/out and the Web Content Renderer. 
  • Copy the media files and the project file from the Desktop version to the runtime version.
Make sure you use the same application version of both the runtime and desktop versions. If the application versions are mismatched, there might be incompatibility issues.

Application startup arguments

Project files (.prj) should be located in the "Projects" folder of the application folder.

  • To launch a specific project, add the project name as the first command parameter:
    ./vindralcomposerruntime -p [project name]
     If no project name is provided, the application will try to launch the default.prj project.

  • To prohibit the start of an unlicensed version, add the argument  --licenserequired
    ./vindralcomposerruntime  -p [project name] --licenserequired

  • Linux only. If several versions of FFmpeg are installed and the OS default detects that the FFmpeg version is older than the requirement for Composer, add the argument --noffmpegversioncheck, to override the Composer verify FFmpeg version on startup. (Requires a Composer-compatible FFmpeg version installed)
    ./vindralcomposerruntime  -p [project name] --noffmpegversioncheck

  • To disable logging to disk, add the argument --nodisklog
    ./vindralcomposerruntime  -p [project name] --nodisklog

  • To limit logging to Console to include errors only, add the argument --consoleonlyerrors
    ./vindralcomposerruntime  -p [project name] --consoleonlyerrors

  •  To launch an encrypted project:
    ./vindralcomposerruntime  -p [myEncryptProjectName.prjp] -d [myEncryptKey]
    ( [myEncryptKey] is found in the Settings of the Desktop version of Composer that created the encrypted file.)

  • To activate autotests, add the argument --a
    ./vindralcomposerruntime  -p [project name] --a

  • This will remove the check to see if the user runs Composer as admin. The reason why this argument is can be used is to allow tools such as NVidia Nsight to launch Composer without elevated permissions. This will cause the HTTP API and Metrics server (Prometheus) to fail at application startup. This is because attaching an HTTP listener to a port requires elevated permissions.
    ./vindralcomposerruntime  -p [project name] --noadmincheck


Configuration of the Runtime version is defined in the settings.xml file, which corresponds to the same settings as those defined in Settings.

If settings.xml is copied to a Linux server, the URI paths in the settings.xml need to be reconfigured to match the Linux directory.



On the Windows platform, there is an install package similar to the Desktop version. More information on how to install Composer on Windows can be found here.


On the Linux platform, there is a separate .tgz package called VindralComposerRuntime-Linux.tgz. Extract this package to a directory of your choice, and launch the application using your terminal. More information on how to install Composer on Linux can be found here.


The current version is not shipped as a container, but future versions of the Linux version will be available as a container. On the Windows platform, a container version will be released as soon as NVidia provides a driver that supports using the GPU from inside a container.

Demo projects

(Documentation not completed yet)


Logging to disk and console in a similar way as the Desktop version. Log event identifiers are the same as on the desktop version.

System requirements

Windows platform: same as the desktop version.

Linux platform: same as the desktop version, but Ubuntu 20.04. Other Linux variants are most likely supported but not tested by RealSprint.


Same as for the Desktop version.

Was this article helpful?

What's Next