• BuyDRM_BatchvsJITEncryption_1920x450-1
  • BatchvsJITEncryption_768x430
  • BuyDRM_BatchvsJITEncryption_372x300

Batch vs. JIT Encryption

Posted by Christopher Levy on Feb 2, 2021 9:00:00 AM

In OTT Video Delivery, several decisions need to be made regarding the choice of video codec, streaming protocol, the DRM technology, player stack, QoE and QoS analytics, etc. And, wrong decisions can significantly impact a company's bottom line as they can be costly to scale and maintain during production.One such decision is to determine whether the content needs to be packaged and encrypted ahead of time (batch processing) or just-in-time (JIT). 

Well, you might be thinking to yourself - what do these terms mean? And how do they impact my service?

Don't worry! This article will look at the pros and cons of Batch vs. JIT Encryption, where they make sense, and what you need to look out for in each paradigm.

Batch vs. Just In Time

Before we dive deep into Batch and JIT packaging and encryption, let's take a brief look at the JIT model and its history. 

As a reminder, the Just In Time model comes from the manufacturing world, where auto-makers (specifically Toyota) avoided keeping a large inventory on hand. Toyota ran its lean production lines on the philosophy - 

"Making only what is needed, only when it is needed, and only in the amount that is needed."

JIT allowed Toyota to stay agile, adapt to the customers' choices at the last minute, and avoid holding on to large amounts of car parts in their warehouses - both costly and risky. 

In recent years, the JIT paradigm has spilled into most industries, and video streaming is no stranger to it. Today, you can find JIT video compression, packaging, and encryption in video processing and delivery applications. 

Specifically, JIT Packaging and Encryption refers to packaging and encrypting a compressed video asset when an end-user requests it. JIT contrasts with the traditional video processing pipeline, where assets are almost immediately packaged and encrypted after compression.

But why do these two approaches exist? Let's learn in the next section. 

The Storage Cost Dilemma 

Assume you have a content library with ten thousand movies spanning several different genres and languages. Your team decides to deliver each video in seven profiles (or renditions) using both HLS and MPEG-DASH. 

What does this mean?

It means that you need to transcode each video into seven different renditions, store them in both mp4 and MPEG-TS container formats for MPEG-DASH and HLS, respectively.

In addition to this, you will have to encrypt them separately for Apple FairPlay Streaming and Google Widevine DRM. 

At the end of this exercise, you will need to store 28 copies of each video. Now, multiply this by the size of your content library, and the economics of scale starts looking scary.

So, the question to be answered is - 

"Do you package and encrypt your content library JIT (only when someone requests it) - adding a point of failure in your system? Or, do you splurge on storage and ensure that your content is prepped for delivery at all times?"

But don't worry. The batch-vs-JIT problem is not new in the world of video streaming, and BuyDRM isn't a newcomer either.  

Let's look at both Batch and JIT Encryption, where they are applicable, and their pros & cons. And, then let's get down to answering the batch-vs-JIT question.

Batch Encryption

Batch encryption refers to the act of encrypting content ahead of time and storing the encrypted assets on an origin server even if it has not been requested for playback by any user of the service.

Typically, this is how batch-encryption or pre-encryption works. 

A video is transcoded into multiple renditions using a transcoder. 

Each rendition is packaged for delivery using one or more streaming protocols (typically, MPEG-DASH, HLS, MSS, etc.)

Each packaged rendition is encrypted (part of the DRM process) as per the specifications of the DRM technology used. E.g., Widevine, FairPlay, or PlayReady. 

The encrypted renditions and manifests are stored on an origin server, ready to be served via a CDN. 

As you can see, a video is transcoded, packaged, and encrypted before any user has requested it for playback. Thus, this process is called pre/batch/ahead-of-time encryption. 

The advantages of batch encryption are that - 

  1. The content is encrypted at rest (i.e., when it is sitting in the origin server) and can deter hackers. 
  2. Furthermore, the above process is easy to architect and has fewer moving parts than JIT encryption (as we will soon discover). Fewer points of failure in a system typically result in easier maintenance and lower costs.  

However, there are disadvantages to ahead-of-time or batch encryption. 

  1. Storage costs increase from the sheer number of renditions stored on disk, even if the content is not popular and is not requested by anyone.
  2. Pre-encrypting content implies that the process is not agile. If someone wants to re-encrypt the content using a different key, or another technology, all the content must be re-packaged and re-encrypted. 

JIT Encryption

The term Just-In-Time or JIT refers to processing content only when requested or needed by the end-user. 

Remember our example from earlier in this article? The need to store 28 copies of every video in your content library.

When faced with such scenarios, companies might resort to JIT packaging and encryption. They store every video in a single container format (either mp4 or TS) without encryption (clear content). When a user requests a video, it is packaged, encrypted, and delivered – Just in Time! 

The packaged video is stored for a predetermined amount of time on the servers following which, they are deleted to save storage space. 

This JIT processing allows companies to avoid storing content with low engagement and, consequently, save on storage costs. 

JIT comes with a lot of advantages, such as – 

  1. Storage savings - Imagine a publisher with 10K titles, transcoded in 10 profiles, and needs to deliver them in HLS & MPEG-DASH using FairPlay, Widevine, and PlayReady. Now, we are talking about substantial storage costs that JIT can help avoid. 
  2. Ease of Key Rotation – since the video is stored in the clear, it is easy to rotate the keys each time the video needs to be re-encrypted. 
  3. Agility - if you need to change the key, or DRM technology, streaming protocol, etc., it is simpler to implement in the JIT paradigm than the batch paradigm. 

The significant disadvantages here are -  

  1. You need to store the clear content securely to avoid leaks from determined hackers. 
  2. Companies must take additional security measures to ensure that the content is safe at-rest and in-transit.
  3. Scalability: You need to ensure that you have the right processes in place that can package and encrypt a movie almost instantly once that first request comes in. These endpoints add a point of failure to your system that needs to scale with demand. 

How can BuyDRM help you?

Now, we just gave an idea of the pros and cons of batch and JIT encryption without a firm "X is better than Y" kind of answer. And, that is because there is no "one size fits all" for video delivery in 2021. 

Many decisions depend on your business's size, the scale you need to operate, your target audience, etc. 

And, BuyDRM can help you in making the right decision. We are the undisputed leaders in DRM technology and can hand-hold you every step of the way. 

BuyDRM has partnered with the best-in-class for JIT Packaging in Delivery (https://www.buydrm.com/partners/keyos-esp-partners). So, if you want to go the JIT route, then we have you covered. 

Our DRM MultiPack Utility tool also takes the headache out of the process by enabling a smooth and streamlined introduction of Hollywood-grade DRM into your production pipeline. https://www.buydrm.com/multipack-utility

Still in doubt, or you have your mind made up? Either way, do drop us a message at sales@keyos.com, and one of our DRM experts will get in touch. 

    Subscribe for Instant Notifications

    New call-to-action

    Posts by Topic

    see all