Starting with Cinegy Air 11.3 direct integration is available between Cinegy Playout and the Cavena Subtitling platform. This takes the form of a plugin, hosted by the Cinegy Event Manager service, which provides relevant interoperability between a Cinegy Playout engine and the Cavena Subtitle Control software.

This post outlines how to configure the Cavena solution, and how to arrange the relevant software components as aligned to various user requirements for density and availability. The preferred logical architectural arrangement is driven by practicality in a software-only world, and so the pricing model for customers is subject to suitable arrangement to avoid unfavorable terms when following this arrangement. This is because repeated deployment of some elements has little material cost in a pure-software world (where there is no constrained access to physical I/O, such as LTC boards, GPI triggers and serial ports) and so the commercial model must follow the preferred logical model. Specific of a repeatable, commercial package following these logical and commercial patterns is outside the scope of this document, but expected to be a result following the release of this document.

Configuring Cinegy Playout

Messages for the Cavena system are triggered by the Cinegy Playout Engine and travel via the 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 Subtitling panel:


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

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 plugin allows relevant specification of how to communicate with the Cavena world. The configuration is simple, and the plugin 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 plugin 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 Air Control will be passed through to the Cavena system for selection and playback:


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


Application Installation Scenarios

Depending on the requirements, a simple single channel environment might be required, or a complex multi-channel, high-availability environment might be needed. In all cases, it is recommended that the STC and STU servicing the channel are installed inside the same environment as the Playout engine service. This eliminates any problems due to network interruption or recovery – instead, the overall task of playing out a channel with subtitles becomes a single logical unit and operates correctly or fails as a single unit.

Scenario 1 – Single Channel, no Redundancy

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 the 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.

Scenario 2 – Multiple Channels, no Redundancy

This more advanced scenario shows how the resources of a physical machine, or larger virtual machine, may be driven to a 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, above, 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.

Scenario 3 – Single Channel with Redundancy (switched by Muxer)

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 ceases transmission. It should be noted, because the PCR values of each Air engine are not aligned, the STU should be locked to the resulting PCR value from the muxer, instead of directly from the Air output. In this case, if an Air engine fails over, the PCR change will be carried over into the Cavena STU.

Scenario 4 - Single Channel with Redundancy (switched by Cinegy Stream Switcher)

A variation from scenario 3 (but where the single 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 the customer does not wish to actively monitor the backup subtitle stream, then the extra component of Cinegy Stream Switcher allows a 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.