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.
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.
Must Fix: differentiate between longtail and most popular containt
In VOD scenarios, as opposed to Live, it is often unfeasible to let CDNs cache all content in all relevant output formats from Origin for three reasons:
Content libraries are too large, thus the costs involved would be very high
VOD content is often made available for a long period of time, thus, again, the costs involved would be very high
Most requests are for a small portion of highly popular content
Considering this, it is important to identify your most popular content and differentiate from the large portion of content that gets requested much less frequently. This large portion of less popular content is often called the 'long tail'.
For example: your most popular content may be responsible for 80% of requests, whereas it only represents only 20% of your content, with the other 80% of your content only generating 20% of the requests. In a graph showing the distribution of popularity of your content, 80% of it would be represented as the 'long tail' of the distribution.
Differentiating between the most popular content and the long tail is not always easy. In addition, you need to take into account that the distribution of popularity may change over time and certain content from the long tail can be become popular and vice versa.
In general, you may want to approach this topic in two ways:
Ensure that content that you believe will be popular is cached on the CDN before making it available (this can be done by using a tool like Unified Capture to 'pull it through' the CDN).
Consider storing your long tail content on slower, cheaper storage to save costs.
We only recommend doing the first, not the second, although doing the second may be warranted in certain setups as well.
VOD test streams
See all of our features in action on Unified Streaming Demo
Use Docker to quickly deploy Your own Video on Demand demo.
Check our tutorial on Getting started with VOD.
Read our blog on How to deploy a redundant VOD setup on AWS with Unified Origin.
Read our Unified Origin - VOD documentation.
Check our Troubleshooting VOD Streaming when you run into a problem.