Cinegy / Cavena Installation and Architecture Recommendations

Messages for the Cavena system are triggered by the Cinegy Playout engine and travel via Cinegy Event Manager. Each instance of the Cinegy Playout engine must have certain parameters set to allow messages from a specific channel to be routed to the correct Cavena instances and with the correct language specifications for that channel. This uses the standard Cinegy "Subtitle events" panel:

In this configuration dialog, the DEVICE must be CAVENA to direct calls within Cinegy Event Manager to the Cavena plug-in. Similarly, the List event must use command LOAD, and the timecode event must use command TC.

The LOAD command may optionally be suffixed with a channel identifier number (unit number) in the format ‘LOAD-{unit number}’. For example, to send commands to the 3rd channel configured on the STU, the command should be ‘LOAD-3’. The commands LOAD and LOAD-1 are functionally identical.

OP1 of the List event expects a comma-delimited set of 3 or 4 language ISO code values that shall be used to inform the Cavena system what subtitle languages are needed for that channel.

Inside the Event Manager, the Cavena plug-in allows relevant specification of how to communicate with the Cavena world. The configuration is simple, and the plug-in expects to find a Cavena STC and Cavena STU both running on the same machine with a single specification for the port used for UDP timecode packets. This may be extended in future, to allow STC and STU on different machines if needed. The dialog looks like this:

As will be noted in later dialogs, a single event manager driving multiple STC systems is itself a single point of failure, and the secondary device specifications will likely be deprecated in the future.

Debug logging increases the detail of logging written to the Event Manager log, and should not generally be enabled in production.

Once the Event Manager plug-in is enabled and configured and Cinegy Playout engine is operating, a connection should be automatically created with the relevant Cavena STC and STU unit and timecode should start flowing to the STU, as seen below:

When a playlist is loaded for the relevant channel into Cinegy Air, the "Sub ID" column inside an item in the Cinegy Air control application will be passed through to the Cavena system for selection and playback:

These Subtitle ID values are queried via the Cavena Event Manager plug-in and loaded through the Cavena STC ready for playout in the STU:

The most basic installation, showing the playout engine elements. Please note, controllers, transcoders or MAM elements are not shown as in-scope in this or other scenarios.

In this scenario, the Cinegy elements (blue) are running in a 1-1 mapping with the Cavena elements (orange). The IP outputs from both platforms are sent to and muxed by a third-party muxing platform (green) to produce a single-program output. The Cavena STU reads Cinegy Playout engine multicast output, and uses the PCR values from the master Air stream so that the resulting Subtitle TS shares a reference and can easily be combined with the downstream muxer.

This more advanced scenario shows how the resources of a physical machine, or larger virtual machine, may be driven to higher utilization by running more channels on that platform. However, as can be seen, not all elements from Cinegy or Cavena must be duplicated for each channel expansion, since some software elements may serve multiple other software elements.

It is assumed, that the above muxer is configured to differentiate each incoming stream to create multiple programs. This might be variations of the same program, for example, with differing commercials, or this might be completely alternate programming channels.

In a virtual environment, it would be considered optimal, if possible within the limits of the virtualization platform, to partition virtual resources to balance the allocated capacity to match a single-channel load. This is not always possible, due to the minimum size of GPU elements that might be passed into virtual machines defining a somewhat oversized virtual machine for some scenarios. Each Cavena STU again references the playout transport stream to generate aligned PCR values, but this is not shown in the diagram for clarity.

A variation of the first scenario, where now a single logical channel (which would be under the control of a single controller) would be split into an active / active pair of engines. At all times, both sets of software output complete channels, and may at any moment be selected by the muxer as the source of output to blend into a resulting program.

It is assumed that the muxer has the capability to discriminate between each source of transport streams, and that in the event of a detected problem with either output, the muxer will automatically (or manually) be failed between the two sources. The Cavena STU system is capable of being set up to emit on a shared multicast address; and therefore, if a primary output is already functioning, a secondary output shall remain silent unless the primary one ceases transmission. It should be noted, because the PCR values of each Cinegy Air engine are not aligned, the STU should be locked to the resulting PCR value from the muxer, instead of directly from the Cinegy Air output. In this case, if a Cinegy Air engine fails over, the PCR change will be carried over into the Cavena STU.

A variation from scenario 3 (but where the single Cinegy Air controller is not shown for clarity), but in the instance when the muxer is not providing the stream source selection. In this environment, the Cinegy Stream Switcher product is used in a cluster to resolve multiple inputs to a new single multicast output. Redundancy in muxers and multicast network pathing should be provided to prevent the output from the Stream Switcher cluster itself becoming a new single-point of failure.

Since the Cavena STU system is already capable of running with active / passive multicast output, assuming a customer does not wish to actively monitor the backup subtitle stream, then the extra component of Cinegy Stream Switcher allows the customer to generate a single resulting stream to lock against for the video playout elements. As before, locking the PCR reference to the muxer output will allow fail-over of the playout TS, but maintain a correct PCR input value to the STU unit.