Single-File Videos [C ARC]
Video assets which are represented by a single physical file (e.g. Op1a MXF, self-contained MOV) can be described in VidiCore in a straightforward way. The logical video is described by an item. The item has shapes for each physical representation, e.g.:
original file as ingested,
station-format copy,
proxy video.
Each shape has multiple components (audio, video, container) pointing to the same physical file.
The different representations can be identified via VidiCore shape tags . There are shape tags for different hires formats as well as a the pre-defined shape tag original
denoting the version of the file that originally was imported into the system.
Note: shape tags will only be set automatically by VidiCore in these situations:
the
original
shape tag will be set when a file is imported to the system (either via watch folder or via API);when an item is transcoded the target format need to be defined via a shape tag; this shape tag is automatically set on the newly created shape.
However, you can set shape tags manually and you can attach multiple shape tags to a single shape to denote different aspects of a shape.
Absolute timecodes for the whole video should be taken from the startTimeCode
and durationTimeCode
metadata fields on the item. durationTimeCode
often uses a different time base than startTimeCode
, so take care to always respect the time base when doing calculations with VidiCore time code data.
Comparing It To Worker-Based VPMS
Single-file videos were modelled as SJob in worker-based VPMS. The startTimeCode
field has the same quality as SJob.TcInOfInterest
which also denotes the absolute start time code for the whole video. There is no direct correspondence to SJob.TcOutOfInterest
in VidiCore as it is highly advisable to work with start TC + duration instead of start TC and end TC (avoids the +/-1 frame irritations frequently occurring in worker-based VPMS). The end TC can be deduced from startTimeCode
+ durationTimeCode
when communicating with 3rd-party systems that need an end TC – but you then should be extremely aware of the interpretation of end TC that your 3rd-party system requires: “last visible frame” or “first frame after the last visible frame”.