Table of Contents
Remix nPVR enables the creation of a flexible, scalable, performant and reliable catch up or nPVR service while minimizing storage overhead.
Utilizing Unified Capture to create a time based segment archive and Unified Remix to prepare playlists based on the archive provides a number of advantages over traditional nPVR solutions:
- no storage duplication, if nPVR "recordings" overlap the content will still only be stored once
- easy changes without any repackaging or re-encoding, it's possible to update the start or end time of a recording based on broadcast as-runs just by updating the playlist
- easy to cut out breaks by creating a playlist which only includes the primary content
The solution makes use of 3 Unified Streaming Platform products:
- Capture, to create an archive of time chunks
- Remix, to combine these into programmes (pseudo-recordings) for playout
- Origin, for Just-In-Time packaging to all supported streaming formats
Remix nPVR allows for the following use case:
- nPVR (Infinite Live archiving)
The archiver process uses Unified Capture to create time based archive segments which will be used by Remix.
Unified Origin - Live¶
This Origin is used for Live playout, and for capturing / archiving.
Unified Origin - VOD nPVR playout¶
VOD playout Origin for nPVR content. Takes the remixed MP4 created by Remix and plays out all streaming formats.
Based on a SMIL input compares the scheduled sources and produces a single remixed MP4 that is a representation of the playlist. Remix uses a set of heuristics to match tracks between separate input sources to enable the production of a seamless output presentation.
Below is an example of a using remix to generate a new clip in which the closed GOP is split across multiple sources.
unified_capture --remix does not insert additional key frames at
archive segment boundaries Unified Remix cannot use the initial and final
samples inside a GOP that is split over two segments unless both segments are
in the SMIL (restoring the original sequence).
Attempting to start a clip at the first sample of the first archive segment,
will result in seeking the nearest available keyframe instead.
Creates a playlist based on a request URL.
Content Request Sequence¶
The SMIL Origin must return a SMIL 2.0 (Synchronized Multimedia Integration Language) playlist.
SMIL functionality supported by Remix¶
- 'outputDescription' meta element in head to point to target profile
- Without setting this, the first clip in the playlist will be used for the target profile
- 'seq', sequence of clips to playout
- 'par' combine multiple files into a single clip as part of the sequence, e.g. if different bitrates are stored in separate source files
- 'clipBegin', 'clipEnd', to select only parts of the clip rather than whole
- currently only supports using the "wallclock(ISO 8601)" format, not all formats included in SMIL 2.0
- can also be applied to 'par' elements, as an extension
A SMIL playlist for a simple use case that will play a pre-roll bumper and 30 seconds of Tears of Steel looks like this:
<?xml version="1.0" encoding="utf-8"?> <smil xmlns="http://www.w3.org/2001/SMIL20/Language"> <head/> <body> <seq> <video src="http://sample-content/logo_5s_dref.mp4"/> <video src="http://sample-content/tears-of-steel-dref.mp4" clipEnd="wallclock(1970-01-01T00:00:30.000Z)"/> </seq> </body> </smil>
An example for a use case with pre- and mid-roll advertisements using Sintel as the main content, targetting Sintel for the output profile:
<?xml version='1.0' encoding='UTF-8'?> <smil xmlns="http://www.w3.org/2001/SMIL20/Language"> <head> <meta name="outputDescription" content="http://storage/main/sintel/sintel_dref.mp4"/> </head> <body> <seq> <video src="http://storage/ads/origin/origin08_x264.mp4"/> <video src="http://storage/main/sintel/sintel_dref.mp4" clipEnd="wallclock(1970-01-01T00:00:30.000Z)"/> <video src="http://storage/ads/capture/capture10_x264.mp4"/> <video src="http://storage/main/sintel/sintel_dref.mp4" clipBegin="wallclock(1970-01-01T00:00:30.000Z)" clipEnd="wallclock(1970-01-01T00:01:00.000Z)"/> </seq> </body> </smil>
An example based on different bitrates in separate MP4s, using <par> to combine these MP4s into a single item:
<?xml version="1.0" encoding="utf-8"?> <smil xmlns="http://www.w3.org/2001/SMIL20/Language"> <head> </head> <body> <seq> <par> <video src="http://storage/path/to/files/file_1280.mp4" /> <video src="http://storage/path/to/files/file_1024.mp4" /> <video src="http://storage/path/to/files/file_768.mp4" /> <video src="http://storage/path/to/files/file_480.mp4" /> </par> <video src="http://local-storage.unified-streaming.com/demo/tears-of-steel/tears-of-steel-teaser-no-jpg.ism" /> </seq> </body> </smil>
Remix nPVR is flexible when it comes to deployment options, as both Unified Origin and Remix are stateless and work over HTTP. This means it can easily be deployed on both physical or virtual hosts, or using container technology such as Docker.
Supported OS and software versions¶
Remix requires Apache 2.4.x.
Recommended OS and web server versions are:
|Alpine Linux v3.11||Apache/2.4|
The size of the required storage is the following: archive length * bitrates.
Note however that it is possible to make the archive sparse by deleting unreferenced archive segments.
Remix nPVR can be deployed using various approaches:
- Bare metal
- Virtual machines as for instance Amazon EC2
- Container environments managed by for instance Kubernetes
- Content must be accessible to both Remix and Unified Origins on the same path
- Content encoding profiles should match (which it will as Capture extracts the content from the publishing point, which does not change).
- Redundant setup for the ingest to prevent gaps caused by:
- encoder failures
- upstream distribution failures, e.g. satellite outage, playout issue