How to efficiently stream videos on an internal network?

The seamless delivery of video over corporate networks has been an issue for nearly 15 years. Since then, the number and size of videos has exploded, both on demand and live. Streamlike was the first “HTTP adaptive streaming” delivery technology, before HLS and other methods that have become popular thanks to the power of their publishers: mainly Apple, then Microsoft and Adobe to a lesser extent.

Video delivery is done through a global network called the Content Delivery Network (CDN). People connected to a corporate network from an office or from home via a VPN actually connect to the CDN through the company’s Internet port.

As early as 2007 , Streamlike was streaming (as opposed to downloading) on the HTTP port (no particular rule for firewalls) in an adaptive way (automatic choice among several streams of different qualities, based on the speed of the connection). The benefits were to not saturate the internal networks and to adapt to the available bandwidth by transmitting only what is strictly necessary. HTTP streaming secures contents by preventing their downloading and provides precise engagement analytics.

Classic adaptive bitrate streaming (“ABR”). When there are many simultaneous connections through the Internet port, the quality served must be reduced so that playback can continue without interruption.

Usage tends to grow faster than infrastructure capacity. Now that Live has become widespread, that the “standard” quality of online video is high definition, that video conferences are multiplying due to the pandemic, anything that can relieve the internal networks and especially their connection to the Internet is good to take.

We will distinguish three complementary strategies. The last two are similar to creating CDNs on the corporate network, hence the name “eCDN”:

• Throttling the quality of the videos played
• Setting up cache servers
• Internal P2P distribution

The playback quality limitation

We call this “bandwidth throttling”, and we enable it by means of a parameter applied to the video player. Rather than creating low quality encodings, we hide higher quality levels in a specific context. This means that the same videos can be viewed in full quality on a consumer website and in reduced quality on your intranet.

Lowering the quality of video on the corporate network allows more users to connect simultaneously and delays the need to resize the company’s Internet access.

Quality throttling is also an eco-design measure that can easily be applied to webTVs. The data transfer volume is reduced to save greenhouse gas emissions and broadcasting costs. In “720p” resolution, the data volume is half of “1080p” or “Full HD”, while the perceived quality is the same if not viewed in full screen.

Streamlike webTVs offer a configurable “eco” mode to limit the quality spectrum, disable autoplay and darken the interface.

Cache servers

A cache server is also called a “reverse proxy”. Several cache servers on an internal network form an “eCDN” (Enterprise Content Delivery Network).

Some companies implement their own reverse proxies, but this requires significant software and hardware engineering resources, as well as a significant investment in hardware.

A reverse proxy deployed between Streamlike’s CDN and the users allows caching of data according to rules defined by the system administrator, thus reducing the volume of data downloaded from the internet.

You can choose to permanently cache an entire catalog of videos or only the most requested videos temporarily. In the first case, all video requests will be served from the cache on the corporate network. In the second case, the first requests will be served from the CDN and kept in cache, so that the next requests will be served from the internal network.

The most used software solutions are Nginx, Squid ou Varnish.

Peer-to-peer streaming (P2P)

Mesh / P2P streaming solutions do not require any hardware deployment. For the simplest ones, they consist in adding some code in the video player that will make each workstation a (re)broadcasting point. What one has already downloadesd and played will be made available to other clients on the internal network, who will share it in turn, using the WebRTC protocol.

P2P broadcasting is efficient for massively and simultaneously watched videos, i.e. for live streams on an internal network. In this case, there is virtually no Internet data transfer and the quality served can be better because it is not conditioned by the bandwidth of the network connection to the Internet. On the other hand, a latency of about thirty second is added a live stream compared to getting the stream directly from the Internet.

For VOD and content that is only occasionally accessed, there is little or no advantage to P2P streaming.

The main vendors (Lumen/Streamroot, Peer5, Kollective, Hivestreaming and Strivecast) offer solutions for one or more video players used by Streamlike (Theoplayer, Videojs and Flowplayer). Some also offer SDKs for Android and iOS. The differences are also related to the level of security and statistics provided. In general, it is possible to test the efficiency of a P2P broadcast on workstations connected to the same internal network, through a “silent test” mode.

It is very easy to combine a public broadcast via the Streamlike CDN with an internal P2P broadcast, no matter which publisher you choose. You can even decide which videos, which playlists, which webTVs will be streaming in P2P and which ones will be streaming in a classic way by the Streamlike CDN.

The price of P2P solutions varies widely among vendors. In general, prices are based on the total number of employees in the company and on usage. The economic interest is then judged on the size of the internal audiences that you want to reach directly, on the frequency of this use and on the available internet bandwidth.

Note that most publishers offer “per event” packages that are more affordable if the need is occasional or exceptional.

What should you choose?

It all depends on the need. We see two good cases for an eCDN: the complete caching of your media library on one or more servers and the frequent broadcasting of live streams (or StreamOuts) to a large number of your employees.

For exceptional operations, the activation of a P2P streaming “per event” is both efficient and economical.

Here is how we could compare the different solutions:

“ABR / CDN” = “Adaptive Bit Rate and CDN”

With an eCDN, your internal data transfers still generate Greenhouse Gases (GHG) but less electrical equipment is required (no servers in the case of P2P) than for regular streaming. The advantage is therefore with the eCDN in terms of environmental impact, at least in the cases where it is the most efficient.