If you’re delivering OTT content or a TV Everywhere service, and looking for ways to reduce your expenses, Just-In-Time (JIT) encoding and packaging might just be the solution for you. There are pros and cons to the JIT encoding and packaging workflow, which I would like to share with you, but first let’s start with tradition.

 

The traditional architecture

Traditional video processing flow takes a video asset (master file), and encodes it to various resolutions and bitrates. The variety of resolutions and bitrates enables both ABR (Adaptive Bitrate, which means adapting the video bitrate to changing network conditions), and support for viewing the video across a variety of devices.  After encoding, the files are packaged in all the required protocols, which are dictated by the supported devices (browsers, mobile phones, tablets, TVs, media streamers, game consoles, etc.).  All encoded and packaged versions of the video are stored in the service provider’s data center, so when a video is streamed to a particular device, all that is needed is to select the right file and stream it.

Pros: No heavy-duty processing is required when the video is streamed to the user.

Cons: High storage cost due to storing many copies of the video at different bitrates, resolutions and protocol packages.  Furthermore, to support a new device, you would have to go back and re-encode and re-package your entire repository in the encoding and packaging formats supported by the new device.

 

Full JIT architecture

With JIT encoding and packaging, only a single master copy of the video is stored in the data center.  When a user requests to view that video, the master file is encoded and packaged on-the-fly (just-in-time) to the required resolution, bitrate and protocol supported by the user’s device.  The encoded and packaged file can then be cached for a certain period of time in case another user with the same device profile wants to view that same video, saving the need to encode and package it again.

Pros: Significantly lower storage cost. In addition, in order to support a new device, codec (e.g., HEVC) or protocol (e.g., DASH), all you need to do is to add support for that device profile in your encoder and packager, and you’re done – no need to process the entire file repository.

Cons: Encoding the file needs to be done very quickly, so even the first user who views it won’t notice a delay in delivery.  This means that higher processing resources are needed, similar to the resources required for live video encoding.  In addition, the file needs to be encoded and packaged again after the cache expires.

 

Interim architecture

An interim solution is to use only JIT packaging.  This way, the files are pre-encoded to all the required resolutions and bitrates, but are stored in a single format.  Then, when a user requests to view that asset, the encoded files are packaged on-the-fly according to the protocol required by the user’s device.  Packaging the files requires much less computing resources than encoding them, and still some storage savings are gained as only a single format of each encode is stored.

 

Recommendations

  • For large content libraries with a diverse subscriber base and a multitude of different devices, I recommend using JIT encoding and packaging.  As an interim solution you can use JIT packaging alone, or use JIT encoding for the long-tail content that has a very small number of views.
  • For small content libraries, I don’t recommend using JIT encoding and packaging, even if you have a large number of viewers, since the cost of storing all the different versions is not so high.

I also recommend reading a great article Just in time transcoding is coming by Brian Santo.

 

Let’s recap

JIT encoding and packaging is an important workflow that brings efficiencies to large- scale video deployments.

  • Significant savings in storage cost
  • Simplified workflow
  • Reaches multiple devices
  • Easy support for new devices, codecs and protocols
  • Secure investment, adequate to subscriber growth

Consider the case of a cloud DVR implementation for a cable or satellite operator: the content repository is huge, with new content every day, multiplied by the number of channels. And sometimes due to legal issues, there’s a requirement to keep a copy per user.  In such a case, keeping just one version of the recorded program and performing JIT encoding and packaging, is not only legit – it’s absolutely crucial.


Share