Setting up Long-Term Catchup (LTCU)

Depending on the type of deployment, either NAGRA sets up content workflows, or you need to set them up yourself.

This section explains how to do it yourself. If NAGRA is setting the workflows up for you, you can ignore this section.

Overview

Long-term catch-up (LTCU) allows users to watch live TV content after it has been broadcast. This is made possible by extracting content from the head-end origin server's rolling buffer and storing it in longer-term storage.

This allows you to offer catch-up assets for a longer period at a lower cost than short-term catch-up, as only the selected channels and/or events are extracted.

A client application can make catch-up content available:

• As VOD content in a catalogue
• Via reverse EPG (usually only short-term catch-up content)

To enable LTCU, you must enable the relevant flag on the channels/events to be captured, and set up the required workflows so that OPF knows the location of the rolling buffer to extract from, the destination location for the extracted content, and so on.

Assets are extracted based on event start and end times from the EPG. So EPG schedule accuracy is very important.

If accurate EPG data is not available, it is advisable to use a different form of catch-up, for example, ingesting pre-recorded events as VOD assets.

You can also specify guard times to allow for inaccuracies. This is explained in the relevant sections of the pages that explain how to set up two-stage and single-stage workflows.

If the storageAllowed flag is set to true for a channel or event to indicate that clients can download captured content, the extracted catch-up content will also have this flag set.

Note that OpenTV Video Platform does not yet provide authorisation services for downloaded content. This flag indicates that clients can download content, as long as authorisation is handled by a third-party system.

Content protection

Note that extraction happens after the stream has already been encrypted and packaged. The captured content will share the same encryption and DRM signalisation as the live channel. So a licence authorisation request for an LTCU asset is the same as for the live channel that it was captured from. (The asset has the same DRM ID.)

Record only once (ROO)

If an event is recorded via LTCU, only one copy is stored and it can be shared with NPVR (and vice versa).

If an event is broadcast more than once (i.e. there are multiple events that are linked to the same editorial content), only one copy is stored. 

• This feature cannot be disabled. If you need to create a separate capture for each broadcast event, you must use a different editorial content ID for each event.
• If a repeat event is ingested while the original event is being purged, the capture may not be performed for the second event.
• If a repeat event is in the same ingest as the original event, the capture is sometimes made for the second event instead of the first.

Retrying/rerunning LTCU workflow jobs

OpenTV Platform supports:

• Retrying LTCU workflow jobs that have failed (for example, if there was a problem communicating with the encoder/packager).
  This can be configured to happen automatically.
• Rerunning LTCU workflow jobs that did not fail (for example, if the wrong encoder configuration was used).

To enable automatic retry for failed jobs, add the relevant parameters to:

• The capture profile
• The validation profile
• The purge profile

See the Configure and attach the required profiles section in Two-stage LTCU workflow with JITP and in Single-stage LTCU workflow without JITP.

You can manually rerun the workflow for a content in OpCon – see Running and cancelling workflows.

Workflow types

OpenTV Video Platform supports three different long-term catch-up (LTCU) workflows, which allow it to work with various different encoders and packagers:

• Two-stage with just-in-time packaging (JITP)

  Content is encoded after it is extracted from the rolling buffer but is only packaged when requested. For example, AWS Elemental works this way.

  The advantage of this approach is that JITP reduces CDN traffic and the amount of storage required.

  See Two-stage LTCU workflow with JITP.

• Two-stage without JITP

  Content is encoded after it is extracted from the rolling buffer and then packaged as a separate operation. For example, Irdeto PES works this way.

  

  PES integration is explained in its own section here.

  The advantage of this method is that you can use an encoder from one vendor and a packager from another. You can also repackage existing assets if you need to without having to transcode them again.

• Single-stage without JITP

  After extraction from the rolling buffer, content is encoded and packaged as a single operation. For example, Harmonic VOS360 works this way.

  This approach has the advantage of reduced complexity.

  See Single-stage LTCU workflow.