Recommendations for VOD

In VOD workflows Unified Origin is placed between the storage and a Content Delivery Network (CDN), with a shield cache between Origin and CDN and a reverse proxy cache between Origin and storage being recommended to ensure robustness and increase performance:

player --> cdn --> unified origin --> (remote) storage

Building a large scale VOD platform based on Unified Origin presents several challenges:

  • Storing large collections of media content in a reliable, secure and cost effective way

  • Making the stored large collections of media content available to Origin in a secure and reliable manner with low enough latency and high enough throughput

  • Preparing the media content and configuring Origin in a way that ensures that all required output formats are delivered according to their specification (e.g., DASH, HLS and Smooth)

  • Scaling Origin and the infrastructure around it so that it can meet the demand of the expected maximum of concurrent users (and beyond)

  • Securing Origin to protect your content and the availability of your service

  • Integrating one or multiple CDNs to ensure efficient and timely delivery at high volumes and throughout different regions

  • Differentiating between the most popular content and your 'long tail' content to achieve the best performance at scale while offering customers access to a vast collection of media content

Should Fix: use object-based cloud storage to store large content libraries

Most VOD services rely on a vast library of media content to offer their customers a wide variety of choices to stream. Storing such a library in a secure, reliable and cost effective manner is challenging. Among our customers, object-based cloud storage is a popular solution to solve this issue and we believe this to be a good choice for a number of reasons:

  • Scale as you go, virtually unlimited storage capabilities

  • Reliability and fault tolerance (nine nines reliability), makes the risk of losing media assets due to disk corruption virtually non-existent

  • Fast access and well defined API's as well as bandwidth rate limiting

  • Relatively cost effective and inexpensive

  • Security and authentication mechanisms are provided

  • In case Origin runs in the same cloud environment, there are often no costs for the traffic between Origin and the storage

Origin can work with different object-based cloud storage solutions such as AWS S3, Azure Blob and OpenStack Swift.

Note

  • Naming of the content can also be important, as different names may lead to content being stored on different underlying hard drive sectors within a remote cloud storage environment.

  • Other storage methods can used as well, but at this point we have no concrete guidelines defined for them. In case you have any questions, please contact us.

Should Fix: enable Apache subrequests to access to remote storage

Traditionally, Origin has relied on curl to connect to remote storage (and by default, still does). In version 1.10.28 GA support for Apache's native subrequests functionality was added, with which a significant increase in performance can be achieved. One of the main benefits of Apache subrequests is that a pool of connections is maintained, thus allowing for intelligent re-use of these connections.

To learn more about enabling subrequests, please refer to the relevant section of our documentation: Requirements.

Should Fix: put a caching proxy between remote storage and Origin

Remote object-based storage generally offers high throughput, but relatively high latency as well. That's why you want to decrease the number of round trips between the remote storage and Origin as much as possible. This can be done by putting a reverse caching proxy between the remote storage and Origin:

player --> cdn --> unified origin --> cache proxy --> (cloud) storage

For every request that Origin needs to serve, it reads the server manifest first and after that the index of the relevant media. Only after it has read the index does it know where in the source it should look for the media samples it needs. Depending on how the media file is packaged (ISMV, progressive MP4, or CMAF) it may take multiple read requests in order to get from the index to the media data. This means that several round trips happen before Origin fetches any media data.

To make the most efficient use of this caching proxy, we recommend a specific setup for your stream: instead of creating a server manifest that references your source content directly, dref MP4s should be used as an intermediary. These dref MP4s contain all of the index information from the source files, but none of the media data, making them small and ideal for caching.

The setup that we recommend creates dref MP4s for all source content first, then uses these dref MP4s to create the server manifests (.ism's) and finally stores the source content, dref MP4s and server manifests alongside each other on the remote storage. Then, the caching proxy is configured such that it will cache the dref MP4s and the ISMs.

Please refer to Cloud Storage Reducing Latency to learn more about this setup, and how you can configure a NGINX-based caching proxy to make use of it.

The setup with the cloud storage and Unified Origin for VOD can be extended with an intermediate proxy.

Should Fix: secure access to your remote storage

Another important aspect for cloud storage is to secure access. We recommend to restrict access to your remote storage by requiring requests to be signed with the proper signature, or by only allowing requests from the virtual private cloud that Origin is running in (e.g., by making use of AWS's VPC Endpoint functionality, as described in our blog How to deploy a redundant VOD setup on AWS with Unified Origin).

The advantage of the latter option is that it saves the overhead that is generated by additional TLS handshakes that the signing requires, plus there is no need to share security credentials with modules that need to sign the request.

More information about configuring Origin to sign requests to remote storage using S3 authentication can be found in the relevant section of our documentation: Using S3 with Authentication.

Must Fix: use your metrics to define how to scale

When working with large enough content libraries caching all content becomes unfeasible. This means that the number of requests for relatively unpopular content will determine the load on Origin, as these will be the requests that hit Origin directly (instead of being served from the CDN or shield cache in front of Origin).

As a correctly configured Unified Origin instance is bound by I/O and not CPU or memory, a simple approach to determine when to scale would be to consider the outgoing link bandwidth. Given that an instance provides a maximum link of 10 Gb/s or 1 Gb/s, and assuming 2 Mbit/s streams, the result would be a maximum concurrent number of users of 5000 or 500, if each of these users would request a different video stream.

Note that these numbers do not take the link to the remote storage into consideration. As that link may reduce the final maximum throughput with 10-20 percent, 4000 or 400 would be a more realistic number given a link of 10 Gb/s or 1 Gb/s and still assuming 2 Mbit/s streams.

When it comes to scaling, one could spin up new cloud instances or containers running Origin and distribute the requests through a load balancer, when the number of concurrent users approaches the theoretical limit as calculated above.

Must Fix: set up load balancing across different origins

When running a significantly large VOD streaming service, you will need to run multiple Origins or at least be able to scale your setup to run multiple Origins when demand is peaking.

To intelligently ditribute incoming requests across Origins a properly configured load balancer is crucial. Whether to choose a load balancer that operates on the network or the application layer is a matter of preference. For distributing the incoming requests a straightforward round robin approach may be used, although a more complex process is possible, too.

Use request to a media segment of locally stored asset as a health check There are no real Origin-specific optimizations for load balancers to mention, except for the way the health of an Origin instance should be checked. Basically, it comes down to pointing the load balancer to an endpoint of the Origin instance that will make Origin generate a media segment from a locally stored asset. The asset should be stored locally to limit the health check to the Origin instance itself, instead of including the storage backend as well.

VOD test streams

Learn more