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
originalshape 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”.