Streaming Architecture
Just-In-Time Packaging (JITP)
Reviewed by Manish · OTT & StreamingLast updated: 2026-06-30
Just-In-Time Packaging (JITP) generates streaming formats like HLS or DASH on the fly, at the moment a player requests them, instead of pre-packaging and storing every format in advance. It cuts storage and simplifies multi-format delivery.
Enveu take
JITP shines when your catalog is large or formats change often — you store one mezzanine and let the origin produce HLS/DASH on demand instead of warehousing every variant.
PackagingDeliveryOrigin
Automate it with FlowAutomate packaging in your VoD pipeline — media workflow automation, no custom code
Where it fits in the OTT stack
Mezzanine→JIT Packager (Origin)→CDN→Player
How it works
- A single set of encoded renditions (mezzanine) is stored once.
- When a player requests a format, the origin packages segments on demand.
- It produces HLS or DASH (and the right DRM) at request time.
- The CDN caches the output so repeat requests are served from edge.
Key components
- Mezzanine/source renditions
- JIT packaging at the origin
- CDN caching of packaged output
- Multi-DRM signaling
Performance impact
- Cuts storage vs pre-packaging every format
- Simplifies adding new formats/DRM later
- First request slightly slower until cached
Common issues
- Cold-cache latency on first request
- Origin load if cache hit ratio is low
- Misconfigured DRM signaling per format
When to use it
- Large catalogs where storing every format is costly
- Frequent format/DRM changes
Signals to monitor
- Cache hit ratio at the edge
- Origin CPU at peak
- Time-to-first-segment
Real-world example
Shrinking a multi-format storage bill
A large VOD catalog stored HLS and DASH variants for every title.
Challenge
- Storing every format per title ballooned costs
- Adding a new DRM meant re-packaging the whole library
Action taken
- Switched to JIT packaging from a single mezzanine
- Let the CDN cache packaged output
Outcome
Storage dropped sharply and new formats/DRM could be added without re-packaging the catalog.
Frequently asked questions
What is just-in-time packaging?
JITP generates streaming formats (HLS/DASH) and DRM at the moment a player requests them, from a single stored mezzanine, instead of pre-packaging and storing every format.
What are the benefits of JIT packaging?
Lower storage, simpler multi-format and multi-DRM delivery, and the ability to add new formats without re-packaging the catalog. The trade-off is slightly higher first-request latency before caching.
Does JIT packaging work with DRM?
Yes — the packager applies the right encryption and signaling per format at request time, so multi-DRM is handled on demand.
When does JIT packaging save money?
When the catalogue is large and viewing concentrates in a small share of titles — you store one mezzanine set instead of every packaged format and generate HLS/DASH variants on request. For a small catalogue watched evenly, pre-packaging is simpler and cheaper.
What's the downside of just-in-time packaging?
Added origin compute and slightly higher time-to-first-byte on cache misses, plus a harder failure mode — if the packager is down, nothing plays. Good CDN caching hides most of it, but origin capacity planning becomes critical during spikes.
Build it with Enveu
Package and deliver on demand
Enveu delivers HLS/DASH with multi-DRM and efficient origin packaging across every device.