The following section covers the basic data models relevant for VidiFlow API.
PlatformUri
It is essential for users wishing to integrate against VidiFlow, that a comprehensive understanding of VidiFlow's specific URI concept be achieved. This becomes particularly relevant when it comes to naming and handling the input and output URI parameters for tasks.
DIAGRAM: ObjectUri Model
The highest level is occupied by the "ObjectUri". All other subsequent children URIs derive from the "ObjectUri".
ObjectUri
Children URIs
VpmsUri
PhysicalUri
PlatformUri
Scheme: "vpms" These are URIs from the Worker Based VPMS" (VPMS2). Please note that the new VPMS URIs (VPMS3) are now featured with the scheme "pf" instead of "vpms"! This is done with purpose of separate the contexts and avoid conflicts by renaming Worker Based VPMS (VPMS2) URI scheme into something within VidiFlow.
Schemes: "smb", "ftpe", "file" or "ftp"
Scheme: "pf" Please note that the "pf" scheme is the designated URI for addressing all objects in the VidiFlow /Vidispine world.
When naming a parameter for URI, it is important to consider the nature of the different URI before choosing.
VpmsUri: if this is a Worker Based VPMS URI (VPMS2).
PhysicalUri: if the input URI is only valid if it has one of the following schemes; "smb", "ftpe", "file", or "ftp".
PlatformUri: if the input URI identifies a VidiFlow /Vidispine object.
ObjectUri: if the allowed runtime content may be more than one of the children types.
JavaScript errors detected
Please note, these errors can depend on your browser setup.
If this problem persists, please contact our support.