Limitations, Scaling, Caching and DRM

As stated before, a VOD2Live produced livestream is functionally the same as a regular livestream. However, there are requirements and constraints as outlined below.

Capturing from a VOD2Live stream

Capturing from a VOD2Live stream is not supported. It is recommended to use Remix to generate the required clips directly from the source instead, using Unified Remix - VOD.

Scaling and caching of VOD2Live

Scaling the delivery of a VOD2Live produced livestream should be approached in the same way as scaling a regular livestream:

  • Scaling is done through caching (shield cache and CDN)

  • Adding more tracks to a stream (e.g., different video bit rates, different languages) may increase load, as this may generate more unique requests by end users

  • Configuring a longer DVR window may increase load, as this may generate more unique requests by end users

In addition to the above, the use Prefetch Headers is recommended to allow caches to prefetch media segments and get them as soon as they're available.

Note

Simply pre-caching of a (big part of a) VOD2Live livestream before you make it available may seem like an attractive option, but is not recommended. For one, simply pulling (part of) the livestream through your caches won't work because the timing information and potential SCTE 35 markers inside those segments won't match those that Origin will generate when the stream will be made available at a later time. Second, if the time of the server would be adjusted to take this into account, there is still the problem of security, as the stream will now be present on a potentially publicly shared location (e.g., a CDN).

Scaling the input of a VOD2Live produced livestream on the other hand, works different than for a regular livestream, as you're working with VOD assets instead of a Live ingest as input. This means that on the storage side, scaling recommendations follow those of a VOD setup (i.e., Recommendations for VOD).

Considerations on input for VOD2Live

Attention

At the moment, input for VOD2Live must be encoded with segment alignment between audio and video, e.g., 25 fps video with a 48 frame GOP and using 48kHz audio, or other values that match up in duration. Otherwise, audio will drift during playback. This means dropped frame rates are currently not supported. For more information about stream alignment, please refer to Content Preparation.

On the input side of things, requirements for VOD2Live are similar as for other Remix use cases. That is: available languages, bit rate ladders and encoding profiles should match as much as possible across the different VOD assets used as input. See also:

DRM protection and VOD2Live

In addition, it is good to know that input of DRM protected content is not supported, but adding DRM protection to a VOD2Live produced livestream is. That is, all of the DRM related functionality supported by Origin is available to use.

To use DRM the SMIL file should include a line referencing a CPIX document, e.g.

<meta name="cpix" content="URL" />

Where URL resolves to a CPIX document. For further info on the use of CPIX see Command-line options for specifying CPIX document URLs.

Limitations of VOD2Live

On the output side, a VOD2Live produced livestream is functionally the same as a regular livestream. The only two features that are currently not supported Virtual subclips and --time_shift.

Also, as of yet there is no way to specify an end time of a stream and it will keep looping if you leave it running. However, simply removing the Live server manifest (.isml) from the web server will make the stream unavailable and thus have the same effect. A post-roll could be added to a playlist to ensure enough time for the removal of the server manifest and prevent looping.