Overview

TwentyThree is a video marketing platform designed for companies and organizations to manage, deliver and track their video content across channels. The platform allows at-scale delivery of video content from redundant core origins through a global content delivery network (CDN).

This articles introduces the infrastructure in place to manage delivery; and it introduces how these methods allow for optimizing live and on-demand video delivery on corporate networks with high concurrency requirements.

This article relates to delivery of videos and streams to viewers, and does not apply to webinar or live broadcasters. For further information on optimizing your network for webinar hosts and speakers, please refer to this article.

TL;DR: TwentyThree delivers video using HTTP and HTTPS. This content can be cached locally in corporate networks. Doing so can scale both internal live streaming capacity and quality significantly, while saving 99% of public bandwidth consumption. This solution is designed to use your existing network optimization strategy instead of relying on new software solutions.

Type of video delivery

TwentyThree delivers all content, including all on-demand and live video using HTTPS. From a platform perspective this makes it possible to deliver all video assets from local CDN nodes close to the user – and it also ensures that high load is spread out and ultimately handled by CDN proxies rather than by core infrastructure.

In general terms, video content is delivered in two different ways: Full videos and HTTP Live streaming.

Full video files with Byte-Range requests

This delivery method is often termed progressive download, because the full video file is made available for the video player for download. Modern browsers will not download the full file however; instead, the URL is accessed as needed for the video player to index meta data – and to buffer the relevant parts of the video for playback by downloading only the necessary parts of the video. This means that seeking and skipping in the video is readily available to the user without any delay.

For older browsers and video players that do not support Byte-Range requests, we allow the client to select remuxed versions of the video on the fly, which means that the player is still able to skip freely in video without delay, and that the content is still delivered through HTTP and is subject to caching.

All content is served in MPEG-4 containers with video/mp4 a mime type. Qualities cover 400 kbps through 8,000 kbps (ranging from 3 MB to 60 MB per minutes in bandwidth requirement).

HTTP Live Streaming (HLS)

The HLS protocol allows the delivery of adaptive quality video content, and despite the name it supports both live video and on-demand video. Originally developed by Apple for iOS, it is now widely adopted: It is handled natively on mobile (including iOS and Android) and by TwentyThree plugins for other HTML5 and Flash players.

With HLS, video content is split into multiple small pieces covering a few seconds of videos – and the video player downloads each individual chunk individually and then stitches together the pieces during playback. Each quality has a manifest/playlist file listing available chunks. Adaptive streaming is achieved by serving a manifest referencing all available qualities, and by the player monitoring buffer state and then selecting the best possible quality level with the available bandwidth.

Specifically, this means that the player will try to play the best quality of the video available. In the case where an upcoming video chunk cannot be downloaded quickly enough to ensure smooth playback, lower quality chunks will be download instead.

All live video content on TwentyThree without exception is streamed using HLS; and on-demand content can optionally be handled using the protocol.

Manifests are delivered with the extension .m3u8 in the mime types application/x-mpegURL or application/vnd.apple.mpegurl, which chunks are accessed as .ts with a video/MP2T mime type.

HTTP, Headers and Caching Policies

As detailed above all content is handled by HTTPS. The content can be delivered from core application servers; from origin cache servers; or from CDN nodes depending on access level and access context – but in every case appropriate HTTP Cache-Control headers are delivered with the content.

The Cache-Control header attached to each manifest, chunk or video file serves two purposes. First, it describes whether and how the content can be cached:

• A public value: The content is public. Any HTTP proxy is free to save the content and serve it to any other client asking for the same URL resource.

• A no-cache value: The content is not allowed to cached and redelivered under any circumstances.

• A private value: The content is private to the client requesting it. If content is cached by the proxy, it can only serve the content to the same client. (This setting is usually used to allow browsers to locally cache private content, not for proxies to do so.)

Secondly, the header details the duration of time the content is allow to be cached for. For example, Cache-Control: public, max-age=3600 with ask for content to be cached and served to anyone asking for the same content with the next hour. (This is not intended to be a full introduction to HTTP content caching. There are many more subtleties and ways to optimize cache handling. Generally, those mechanisms lean on the concepts described here though.)

Together these properties are used to handle content distribution in the TwentyThree network: When a video is played back, the client requests it from the CDN, which retrieves it from an origin cache server; which in turn requests it from a core application server.

When a resource is first requested, the core application server will serve it with the correct caching policy attached. From here both the origin cache and every CDN node will honor the cache policy – and deliver cached versions whenever possible.

Local Bandwidth Optimization Through Caching

These policies and methods also allow for significant optimizations of bandwidth consumption on corporate networks shared by many viewers of the same content. In these cases, cache policies and headers can be used to consistently and effectively cache content behind the firewall – which means that content will only be downloaded once, even when 100s or 1,000s of viewers are watching the same content at the same time.

Even better, none of the infrastructure or configuration needed to achieve this is unique to TwentyThree: Any popular web site will deliver the same headers and be subject to behind-the-firewall caching. This means that network optimization with local HTTP proxies will serve to speed up other web services while significantly saving bandwidth consumption in bottlenecks.

Best Practices and Recommendations

Handling video streaming on a corporate network can be a drain on bandwidth and network resources. Especially in live contexts where everyone by definition are watching the same content at the same time.

For example, 200 people watching a 2 mbps live stream at the same time will consume 400-500 mbps. If this bandwidth isn't available the player will switch to worse quality and, at worst, stall entirely.

In the ideal scenario where the same people are sitting behind the same local HTTP proxy, only a single request is made to the origin – and all other requests are handled locally. Put succinctly, load on the internet connection drops by 98-99%.

Our best practice recommendations:

• Evaluate the exact bandwidth requirements for all your live streaming scenarios. If there's any chance that the number of simultaneous viewers will stress local network resources, have a plan to address this.

• Bandwidth requirements can be addressed by lowering video quality or bitrate; by lowering number of simultaneous viewers; or by caching and redelivering content locally.

• If a local HTTP cache or proxy is in place, make sure that `Cache-Control` headers are honored and enabled for *.delivery.twentythree.com and for any custom domain you have set up to work with TwentyThree." We also deliver from this domain without the *., so both variations should be included.

• Similarly, make sure that content delivered with the mime type listed above (video/mp4, application/x-mpegURL, application/vnd.apple.mpegurl, video/MP2T) is subject to caching.

• If the proxy doesn't support internal rewriting of HTTPS traffic, then make sure high-volume content is not delivered in an encrypted fashion. For the specific scope of optimizing video delivery, we recommend enabling HTTPS rewrites. Contact TwentyThree if you need to limit or disable HTTPS delivery.

• Verify by testing that caching by the HTTP proxy is working as intended.

• Finally, it's worth evaluating local network requirements and other bottleneck. (The method described here will save on public internet bandwidth consumption – but in order to deliver 500 simultaneous streams of 2 mbps behind the same proxy, the network still needs to be able to delivery a total load above 1 gbps)