Just-in-time packaging
Just-in-time packaging is a method of creating streaming formats such as HLS or DASH on the fly, at the moment a viewer requests them, instead of storing every format in advance. The service keeps one master copy of each rendition and packages segments as needed. This saves storage and makes adding new formats much easier.
Why it matters
Storing every video in every streaming format and DRM scheme multiplies storage bills, especially for long-tail content that is rarely watched. Just-in-time packaging keeps one copy and builds formats on request. It also lets a service support a new device format later without reprocessing the whole library.
How it works
- The service stores one set of encoded renditions, often as fragmented MP4 files.
- A viewer's player requests a manifest or segment in a specific format, such as HLS or DASH.
- The packager builds that manifest or segment on the fly, adding encryption if required.
- The CDN caches the result so later viewers get it without repackaging.
Just-in-time packaging vs static packaging: which is better?
Neither is always better: just-in-time packaging saves storage, while static packaging avoids work at request time. Just-in-time suits large libraries with many formats and lots of rarely watched titles. Static packaging suits small catalogs or very popular titles, where formats are reused so often that storing them costs less than building them repeatedly. Many services mix both.
Does just-in-time packaging add latency?
Just-in-time packaging adds a small delay on the first request for a segment, because the packager must build it. After that, the CDN usually caches the result, so later viewers see no extra delay. The effect is mostly felt on cold content that few people watch, where caches are often empty.
Where it's used
Large OTT services and video platforms create each streaming format only when a viewer asks for it, saving storage on videos that are rarely watched.
