In sports-related use-cases you often have multiple cameras recording the same game from different angles. The different cameras have a synchronized timecode source so that the corresponding frames in each of the different angles have identical timestamps. This allows editors to choose the best viewing angle for a scene without while keeping the exact timing.
As the different camera angles have different video content they have to be modelled as different items in VidiCore. Although the recordings for the angles have the same timecode source they need not start at exactly the same timecode. The recordings may have been started one after the other so that each angle item may have a different start timecode. Nevertheless, all camera angles share the same events (e.g. goals) which are modelled as time-based metadata field groups in VidiCore.
To avoid storing the event metadata multiple times in the VidiCore database and to be able to share the identical event metadata between the different angle items, a VidiCore collection is used to model the game. The multi-cam collection holds all metadata for the game:
non-time-based metadata like league name, stadium, etc.
time-based metadata like event.
The metadata fields and field groups on the multi-cam collection may me marked as inheritable to tell VidiCore to propagate these metadata to all items inside the collection. The multi-cam collection itself must be created with the
absoluteTime attribute and the time-based metadata on the collection must be set with absolute timecodes for
end of the
timespan. This is contrary to the usual interpretation of VidiCore treating all timespan start and end values as relative to the start of the video. However, this allows VidiCore to convert the absolute timecode information on the multi-cam collection to relative timecodes on the angle-items in this collection based on the individual
startTimeCode value of each item.
Besides the different camera angles the program stream (PGM), i.e. the version that was broadcasted, can be attached to the multi-cam collection.
In certain scenarios there may be events that are specific to an angle:
This may be the case when event logging is done individually for the different angles. From some camera angles you may see things that are not visible from other angles.
Another use-case could be QC results which apply to a specific video, not to the overall game.
Please note that this is an extension to the standard model described above where events are shared across all angles. Certain Enterprise MAM user interfaces may not support these angle-specific events.
In certain scenarios you may want to store so-called melts together with the game. Melts are only contain certain parts of the whole game; each part is a separate video asset (VidiCore item). As long as you can put your melts on the same timeline as the game, you can attach the melts to the game collection via an item containing an item sequence. If your melt has a different timeline that the game (e.g. due to repetitions of the same time interval viewed from different angles) the this item must not be placed into the game collection.
The item sequence describes timeline where the melts are put on – with gaps in between. The item to which the sequence is attached doesn’t have a hires shape – but you my create a proxy shape for easier playback. Please note that the proxy shape must cover the whole timeline of the game – so it may contain longer sequences of black frames where no video is on the melt’s timeline.
On multi-cam collections set
MultiCamVideo – see Collection Types [C ARC]. This clearly identifies the collection as representing a multi-cam asset. Caution: do not make
V3_CollectionType inheritable – this will break nested collections in other scenarios.
On multi-cam collections set the inheritable
boolean metadata field
V3_MultiCam to true. It allows other applications (e.g. MediaPortal Connector) to easily identify items that are part of a multi-cam asset without looking at the parent collection. This field must only be attached to multi-cam collections. Its inheritance ensures that it’s automatically propagated to all items in the collection.
The collection ID of the game can easily be obtained from the transient metadata field
__collection on each angle or melt item.
To define the preferred angle for a game:
V3_MultiCamPreferredAngle(string) directly on each event;
V3_MultiCamAngle(string) on each angle item.
Preferred angle is the item with the same value in
V3_MultiCamAngle as in
V3_MultiCamPreferredAngle on the event. The values of these fields do not have a special meaning, they only must be unique within each game.
Comparing It To Worker-Based VPMS
There is not such concept in worker-based VPMS.