Just-in-Time Packaging vs Pre-Packaged Origin

Why This Matters

Packaging is the storage line item most product managers don't read until the AWS bill triples. A pre-packaged origin can quietly multiply storage by a factor of twelve once you add HLS, DASH, multiple audio renditions, and a couple of low-latency variants — and every gigabyte gets billed every month, whether anyone watches it or not. A JIT origin replaces that storage line with an origin-CPU line, and the new line is harder to forecast: it depends on how cache-friendly the JIT path is, how the CDN is configured, whether an origin shield sits in front, and how much catch-up traffic survives a cache miss. Pick the wrong shape and you either overspend on storage you never serve, or you overspend on compute that a one-line cache rule would have absorbed. This article explains both shapes from the ground up, gives the actual arithmetic that decides between them, and shows the architecture every JIT deployment needs to be cache-friendly enough to make the trade work.

What a Streaming Origin Holds

Before we can talk about how an origin packages content, we need a clear picture of what an origin is. A streaming origin is the HTTP server that the content delivery network — the CDN — talks to when its caches do not already have the file a viewer asked for. The origin is the source of truth: every byte a viewer eventually plays comes from there originally. The CDN copies bytes from the origin to its edge servers and serves them to viewers from edges close to where the viewer's phone or TV is sitting. (For a refresher on the surrounding pipeline, see The Streaming Pipeline, End to End.)

The origin's job is to answer two kinds of HTTP requests. The first is a request for a manifest — the small text file that lists every quality rung the player can switch between, every short segment file within each rung, and any audio or subtitle alternatives the player can pick. HLS manifests are .m3u8 text files; DASH manifests are .mpd XML files. The second is a request for a segment — a 2- to 6-second binary slice of audio or video, wrapped in a container format (almost always fragmented MP4, abbreviated fMP4) that the player can decode without reference to any other segment.

The way the origin produces the answers to those two kinds of requests is what splits the world into pre-packaged and just-in-time. Both shapes return the same bytes for the same URL. The difference is when the bytes were minted.

The Pre-Packaged Shape: Everything Is a File

In a pre-packaged origin, every manifest and every segment is a real file sitting on real storage, written once at ingest, never recomputed. When a player asks for /movie-42/playlist_1080p.m3u8, the origin reads /movie-42/playlist_1080p.m3u8 from disk and returns it. When the player asks for /movie-42/segment_00042.m4s, the origin reads /movie-42/segment_00042.m4s from disk and returns it. The HTTP layer doesn't care what's behind the file; it might as well be a JPEG.

The packaging happens once, before any viewer arrives. An encoder hands the packager (Shaka Packager, Bento4, FFmpeg with the right flags — see Packaging in Depth) a finished ladder of encoded mezzanines — one file per quality rung. The packager slices each mezzanine into short segments, writes every segment to its own file, writes an HLS playlist that lists those segments, writes a DASH MPD that lists the same segments, optionally writes an MPEG-TS variant alongside the fMP4 variant for legacy players, optionally writes a low-latency HLS variant with partial segments, optionally encrypts every segment using Common Encryption, and uploads everything to the origin's storage. Every viewer who watches the title for the next ten years reads from the same files.

The pre-packaged shape is the original one. Every static HTTP server is, by accident, a pre-packaged streaming origin: you put .m3u8 and .m4s files in a directory tree, point a CDN at it, and serve millions of viewers. NGINX is a pre-packaged origin. An S3 bucket fronted by CloudFront is a pre-packaged origin. The first generation of HLS in 2009 ran exclusively on pre-packaged origins because nothing else existed.

The strength of pre-packaging is obvious. There is no packaging compute at request time; the origin's only job is to read bytes off disk and send them down a socket, which is the cheapest, most cacheable, most boring thing an HTTP server can do. The CDN caches every URL the first time any viewer asks for it, and every subsequent viewer worldwide gets the cached copy. Failure modes are simple: if a segment is missing, the player gets a 404 and that is that.

The Cost That Pre-Packaging Hides

The hidden cost of pre-packaging is storage multiplication. A modern streaming platform doesn't deliver one version of a title. It delivers many.

Consider a single 90-minute movie. The encoder ladder produces six renditions: 240p, 360p, 480p, 720p, 1080p, and 4K. That's the first multiplier — six. The platform needs HLS for iOS, Safari, and most smart TVs, and DASH for Android, Chrome, and the other smart TVs. That's the second multiplier — two. The platform supports two audio languages and one subtitle language. That's the third multiplier — small, but not zero. The platform also wants a low-latency HLS variant for live-adjacent titles and an MPEG-TS legacy variant for a stubborn long-tail of old Apple TV boxes. Add another 1.4× for that.

In the worst case the on-disk footprint per title looks like this:

6 renditions × 2 packaging formats × 2 audio tracks × 1.4 legacy/LL multiplier
= ~33.6 copies of the same content on disk per title.

A 90-minute 1080p movie at a 5 Mbps average bitrate is about 3.4 GB on the wire. Multiplied by 33.6, the title now occupies roughly 114 GB of storage. A catalogue of 1,000 titles needs 114 TB. At AWS S3 Standard pricing of around $0.023 per GB-month, that's $2,622 a month, whether anyone watches a single title or not. Add a second region for resilience and the bill doubles.

The arithmetic gets worse for the long tail. The Pareto distribution of video catalogues is brutal — typically 80% of plays land on 20% of the catalogue, and for many platforms, half the catalogue plays fewer than ten times a month. You are paying full storage rent on half a catalogue that does not produce meaningful revenue. The CDN doesn't help, because storage is at the origin, and the origin pays whether the CDN caches or not.

This is the pain JIT was invented to fix.

The JIT Shape: One Master, Many Views

A just-in-time packaging origin keeps the on-disk catalogue in a single canonical shape, usually one fragmented-MP4 file per rendition, and synthesises every protocol-specific view on demand. The mezzanine layout on disk is small: six fMP4 files per title (one per rendition), one initialisation segment per audio language, optional sidecar files for subtitles, and a small metadata description.

When a player asks for /movie-42/index.m3u8, the JIT origin reads the on-disk fMP4 files' index boxes, computes a fresh HLS multi-variant playlist that lists the available renditions, and returns it. When the player asks for the variant playlist /movie-42/playlist_1080p.m3u8, the JIT origin reads the fMP4's segment index, computes a fresh HLS media playlist that lists segment URLs, and returns it. When the player asks for /movie-42/seg_00042.m4s, the JIT origin opens the 1080p fMP4 file, seeks to the byte range that corresponds to segment 42, packages those bytes into a fresh .m4s segment with the right styp and moof boxes for the protocol the URL implies, and returns it.

The crucial point: nothing was written to disk to satisfy any of those requests. The on-disk catalogue stayed exactly as small as it was before any viewer arrived. If a million viewers all watch movie 42, the JIT origin computes the same segment a million times — unless the CDN caches it, which is the whole story of making JIT economic (see "Why You Must Shield It" below).

Figure 1. Pre-packaged origins multiply storage by the number of protocols, audio tracks, and legacy variants. JIT origins keep a single canonical master per rendition and compute every protocol-specific view at request time.

The same arithmetic from the previous section, redone for JIT:

6 renditions × 1 packaging format (fMP4 master) × ~1.1 audio overhead
= ~6.6 copies of the same content on disk per title.

A 90-minute 1080p movie ≈ 3.4 GB on the wire.
Storage per title ≈ 22.4 GB.
1,000 titles ≈ 22.4 TB ≈ $515 per month at S3 Standard.

A 5× reduction on the storage line. For a 10,000-title catalogue, the saving is $20,000+ a month. For a 100,000-title catalogue (think a major streaming platform), the saving is multiple full-time engineering salaries a year.

The trade-off is not that storage saving comes for free. The CPU that used to run once at ingest now runs at every request — or, ideally, at every cache miss. The next sections explain how that trade actually settles.

What Actually Runs at Request Time

To understand the CPU cost of a JIT origin, you have to know what it does for each request. The work is packaging, not encoding — and the difference matters. A JIT origin does not re-encode video. It does not re-compress, does not change codec, does not run x264. The frames on the disk are the same frames that come out on the wire. What the origin does is repackage: it reads the encoded samples from the master fMP4 file and rewrites the surrounding container boxes for the protocol the player asked for.

Concretely, for a single HLS segment request, a JIT origin does the following:

1. Parses the URL to learn which title, which rendition, which segment number is being asked for.
2. Opens the master fMP4 file for that rendition.
3. Reads the sidx (segment index) box to find the byte range that contains segment 42.
4. Reads those bytes from disk (or from cache memory, on a hot title).
5. Builds a new styp (segment type), sidx, moof (movie fragment header), and mdat (media data) box structure that matches the HLS-flavoured fMP4 the player expects.
6. If the segment is encrypted, applies the CENC cbcs AES-CBC pattern to the mdat payload with the right content key from the key-management system.
7. Writes the assembled segment bytes to the HTTP response body.

For a manifest request, the JIT origin reads the same sidx index, the codec-config in the moov box, and the duration of every fragment, then formats a fresh playlist or MPD. It also applies any manifest filter the request URL carries — min_video_bitrate, audio language whitelist, DRM-system whitelist for the device — and includes only the renditions and tracks that pass the filter.

The work is small compared to encoding — packaging is roughly 20 to 200 times cheaper than encoding, per second of media — but it is not free. A pre-packaged segment costs the origin one read() syscall and one sendfile(). A JIT segment costs several read()s, parsing of binary box structures, allocation of a fresh segment buffer, optional AES-CBC encryption of every macroblock, and HTTP response framing. On modern hardware, a single Unified Origin instance can serve in the rough order of 500 to 2,000 JIT segment requests per second per core, depending on segment length and whether DRM is in the path. A pre-packaged static-file server can serve tens of thousands per core. The factor is large enough that JIT origins must be designed to be cache-friendly first — every JIT request you serve is a cache miss you couldn't absorb.

Why You Must Shield It

The single most important architectural rule for a JIT origin: put an origin shield in front of it. Without one, JIT does not work economically at scale. An origin shield is a dedicated, single-tier CDN cache that sits between the rest of the CDN's edge nodes and the JIT origin. Every cache miss at any edge node anywhere in the world goes to the shield first; only a cache miss at the shield reaches the origin. CloudFront, Akamai, Fastly, and CloudFlare all offer origin-shield products. (See Origin Shielding and Tiered Caching.)

Why the shield matters specifically for JIT: a typical global CDN has dozens to hundreds of edge nodes, each with its own cache. Without a shield, the first viewer in Tokyo, the first viewer in Frankfurt, the first viewer in São Paulo, and the first viewer in Mumbai all trigger independent cache misses against the JIT origin — for the same segment. The origin packages the same bytes four times. With a shield, only the first cache miss in the world reaches the origin; every regional edge fills from the shield, not the origin.

The published numbers are large. AWS, in its re:Invent talks on MediaPackage, has cited origin-shield egress reductions of around 95% for typical OTT workloads. Cloudflare and Akamai cite similar ranges. The implication for JIT: with a shield, your origin's request load drops by roughly 20× compared to direct edge-to-origin traffic. Without a shield, JIT looks twenty times more expensive in compute than it actually has to be.

The shield needs a few extras to work properly for JIT.

• The cache key must include the manifest-filter query parameters. AWS MediaPackage's aws.manifestfilter family, Unified Origin's ?filter= parameter — these change the content of the manifest the origin returns, so they have to be part of the cache key. Otherwise viewer A's filtered manifest gets served to viewer B and the wrong renditions appear. The MediaPackage and Unified Origin documentation list the exact parameters that must be in the key.
• Cache TTLs differ between segments and manifests. Segments are immutable once published — a 5.8 segment of a VOD title never changes — so cache TTLs of 24 hours or longer are normal at the shield. Manifests, especially live manifests, change every segment duration — 2 to 6 seconds — so the shield's TTL on manifests must be short, typically 1 to 2 seconds for live, 60 seconds or more for VOD.
• The shield is part of the geometry, not a tuning knob. A team that turns on JIT without an origin shield, sees the bill, and turns JIT off again has misdiagnosed the problem. JIT without a shield is broken. JIT with a shield is one of the cheapest ways to run a large catalogue.

The 2026 Reference JIT Origins

Three pieces of software occupy almost all production JIT-origin deployments in 2026.

Unified Origin from CodeShop (the Netherlands-based Unified Streaming). The original commercial JIT origin, shipped since 2010. Runs as an Apache module (mod_smooth_streaming plus add-ons) inside an Apache HTTP Server container. Ingests a single ISMV / fMP4 / MP4 source per rendition, with a small XML descriptor (.ism) that lists which audio and video tracks belong together, and packages on the fly to HLS (TS and fMP4), MPEG-DASH (including DVB-DASH and HbbTV profiles), Smooth Streaming, and HDS. Supports CMAF output with all three major DRMs (Widevine, PlayReady, FairPlay) under the cbcs Common Encryption scheme. Used by the BBC's Video Factory for the iPlayer catalogue, by Sky, and by dozens of European broadcasters. The licensing model is per-CPU-core, which makes it expensive at very high scale but very predictable for medium-sized platforms.

AWS Elemental MediaPackage, particularly the v2 API generation. A fully managed JIT origin running on AWS. Ingests CMAF-compatible HLS or DASH from an encoder (typically AWS Elemental MediaLive), keeps a single canonical copy in S3, and packages on demand to HLS, LL-HLS, DASH, and Microsoft Smooth Streaming with FairPlay, Widevine, and PlayReady. The v2 generation, introduced in 2023 and the production default by 2026, adds origin endpoints with up to 25 attached manifests apiece, a built-in origin shield, manifest filtering via aws.manifestfilter query parameters, and tight integration with CloudFront. Pricing is per ingested GB plus per packaged GB egress — a separate model from Unified Origin's per-core licence. MediaPackage's "v2" rebranding in the AWS console is the reason you will see both "MediaPackage" and "MediaPackage v2" in 2026 deployment docs; new builds use v2 unless there is a specific reason not to.

Eyevinn Open Source Cloud's Smoothly Origin and the underlying Eyevinn Channel Engine, plus the smaller open-source Norsk (id3as) and a long tail of in-house origins built on top of Shaka Packager's library mode and a custom HTTP layer. These are the choices for platforms that need full control over the packaging logic — typically because they have unusual DRM requirements, exotic codecs (AV1, VVC), or want to avoid both the Unified per-core licence and the AWS lock-in. Eyevinn's serverless pattern, documented in their AWS Fargate posts from 2022 onwards, is the canonical "JIT origin on a tight budget" architecture for medium-sized platforms.

A quick comparison.

Origin	Type	License model	Manifest filtering	Shield required	Typical workload
Unified Origin	Commercial	Per-CPU-core	Yes (?filter=)	Yes (external)	Broadcasters, large OTT
AWS MediaPackage v2	Managed	Ingested + egress GB	Yes (aws.manifestfilter)	Built-in	AWS-stack OTT, live sports
Eyevinn Smoothly + Shaka lib	Open source	None (self-host)	Custom	Yes (external)	Mid-size OTT, dev teams
Norsk	Commercial / OSS hybrid	Per-channel	Yes	Yes (external)	Live broadcasters, e-learning

For an introduction to the packaging tools that feed any of these origins, see Packaging in Depth. For the manifest formats they emit, see HLS in Depth and MPEG-DASH in Depth. For the encryption scheme they apply, see Common Encryption (CENC).

The Storage-vs-Compute Trade-off, Worked Out

The decision between pre-packaged and JIT comes down to one question: where does the saved-storage dollar end up — in your pocket or on the origin's compute bill? The arithmetic below assumes a medium-sized catalogue and 2026 AWS list prices, no committed-spend discounts.

A catalogue of 1,000 titles, 90 minutes average, 6-rendition ladder, two audio tracks, HLS + DASH.

Pre-packaged storage = ~33.6 copies × 3.4 GB ≈ 114 GB per title × 1,000 = 114 TB.
Monthly storage (S3 Standard $0.023/GB-month) = $2,622.

JIT storage = ~6.6 copies × 3.4 GB ≈ 22.4 GB per title × 1,000 = 22.4 TB.
Monthly storage (S3 Standard $0.023/GB-month) = $515.

Storage saving = $2,107/month, or ~$25,000/year.

The origin-CPU side of the ledger depends on how many viewer-hours hit the origin per month. Assume modest scale: 1,000,000 viewer-hours per month, average 4 Mbps, average 4-second segments. That is roughly 900 segment requests per viewer-hour, so 900 million segment requests per month — but almost none of them reach the JIT origin if the architecture is right.

Total segment requests/month     = 900,000,000
Cache hit rate at CDN edges      = ~97% (typical OTT mix)
Misses reaching origin shield    = ~27,000,000
Shield hit rate                  = ~95%
Misses reaching JIT origin       = ~1,350,000 per month

JIT origin requests per second   ≈ 0.5 sustained, 5–10 at peak
Required JIT cores (1k req/s/core) = 1 core sustained, 2 cores peak

Origin compute cost (1 c6i.large EC2, $0.085/hr)
                                 = $62/month

The numbers are illustrative — your CDN's actual cache hit rate, your shield's actual coverage, and your traffic profile will shift each line by ±2× — but the shape is what matters. Storage saved: $2,107. Compute added: $62. JIT wins by roughly 30× on a medium catalogue with a typical OTT cache profile.

The break-even moves around with two variables. First, the catalogue size: a 100-title catalogue saves $200 a month on storage — not enough to justify the operational complexity, so small catalogues stay pre-packaged. Second, the cache hit rate: a long-tail-heavy catalogue with poor cache locality (every title gets a viewer or two per month) drops the shield's hit rate to 60% or 70%, multiplying origin compute by 5× to 10×. JIT still wins, but the margin narrows. A pure long-tail archive — millions of titles, dozens of viewer-hours per title per month, no hits — is the one workload where JIT pays for itself purely on storage and where cache economics are roughly neutral.

For a more granular per-stack model, the cross-cutting CDN cost calculator covers shield-and-edge math; the Streaming cost economics worked model folds packaging into the full unit economics.

Cache-Friendliness Is Not Optional

A JIT origin's reputation rises or falls on one metric: what fraction of segment requests its CDN caches absorb. Everything else — storage savings, operational flexibility, the ability to ship a new protocol next quarter — depends on the assumption that the cache layer carries 95-plus percent of traffic. When the cache layer fails to deliver that, JIT looks expensive, the team blames the origin, and a perfectly good architecture gets ripped out.

Three things break cache-friendliness on JIT origins, and all three are common.

Query-string noise. If two players ask for the same segment URL with two different ?session_id= parameters and the CDN includes the query string in the cache key, the segment is fetched from the origin twice for what is the same on-disk content. The fix is to strip the query string at the edge for segment URLs, or whitelist only the parameters that change the response (DRM key version, manifest filter), and explicitly exclude session and analytics tokens. AWS CloudFront's "Cache Policy" feature exists exactly for this; Akamai's "Cache Key" rules do the same.

Manifest fragmentation. If the JIT origin emits a slightly different manifest for each user-agent — e.g. one for Safari, one for Chrome, one for an Android TV variant — the manifest cache layer fragments by user-agent, and each per-UA manifest pulls its own segments through. The fix: keep the manifest itself UA-agnostic, push device-specific logic into the player (which knows what it can decode), and let the origin emit one manifest per content variant.

Tiny TTLs. A team that, out of caution, sets the manifest TTL to 1 second on a VOD title gives up 99% of cache hits on the manifest layer. VOD manifests do not change. They should cache for as long as the catalogue holds the title — hours or days. Live manifests are the only ones that need short TTLs, and the TTL there should match the segment duration, not be set to 1 second arbitrarily.

The cache-friendliness audit for a JIT deployment is short. (1) On a representative segment URL, does the CDN report a cache HIT on the second request from a different region? (2) Is the origin shield's hit rate above 95% during steady-state load? (3) Are the same segment URLs being computed twice because of query-string fragmentation? Three checks. They are the difference between a JIT origin that pays for itself and one that does not.

Common Mistake: Treating JIT as a Drop-In Replacement

The most expensive failure mode for a team adopting JIT is to treat it as a drop-in replacement for a static origin — to swap NGINX for Unified Origin behind the existing CDN and expect the bill to fall.

It doesn't. Without an origin shield, without a tuned cache key, without UA-agnostic manifests, JIT will deliver a comparable or higher monthly bill than the pre-packaged origin it replaced, because every cache miss now spends origin CPU instead of just origin bandwidth. The team then concludes JIT "doesn't work for us" and reverts, missing the actual architecture.

JIT is not a single product. It is a shape — JIT origin behind a tuned shield, behind a tuned CDN, behind UA-agnostic manifests — and the shape is what saves money. Adopting the origin without adopting the shape is the mistake.

The fix is a checklist, run before the migration goes to production. Origin shield enabled? Cache key excludes session tokens? Segments cache at the edge for at least 24 hours? Manifests cache at the edge for the segment duration (live) or hours (VOD)? Manifest-filter parameters are part of the cache key? Each line in the checklist matters; skipping one of them is what generates the "JIT is more expensive" anecdote.

When Pre-Packaging Still Wins

There are workloads where pre-packaging is still the correct choice in 2026.

The small static catalogue — a corporate training library with 50 titles, a documentary collection, a fixed event recording set. The storage saving from JIT is small ($100/month or less), the operational simplicity of a static-file origin is high, and the engineering cost of running and tuning a JIT origin outweighs the saving.

The pass-through low-latency live — a single live channel where the encoder writes HLS and DASH directly to an S3 bucket, the bucket is the origin, and segment age at the edge is measured in seconds. JIT adds a buffering layer that costs end-to-end latency; for sub-2-second sports feeds, that latency budget is precious. (See LL-HLS in Depth for the latency arithmetic.)

The extremely cache-hot catalogue — a viral single asset, a major launch event — where 99.99% of traffic comes from a tiny number of cached objects. Pre-packaging is simpler and the storage cost is negligible because the catalogue is small.

The pattern: pre-packaging wins where the catalogue is small, where latency is sacred, or where the cache hit rate is so high that no architecture matters much. JIT wins everywhere else.

Decision Tree: Which Origin Shape for Which Workload

A practical decision flow.

Figure 2. Choose pre-packaged when the catalogue is small, the latency budget is tight, or the protocol set is fixed. Choose JIT — always behind an origin shield — when the catalogue grows past a few hundred titles or when protocol diversity is expected to expand.

The thresholds in the tree are rough: 500 titles for the catalogue-size pivot, 1 second of glass-to-glass for the latency pivot, three protocols for the diversity pivot. They are not crisp lines; they are bands. A 400-title catalogue with high protocol diversity is a JIT case. A 600-title catalogue that only ships HLS to iOS apps is still a pre-packaged case. Use the tree as a starting point and stress-test it against the actual cost model.

The Strategic Value: New Protocol on a Tuesday

The financial case for JIT — the storage-versus-CPU arithmetic above — is the case product managers understand first, and it is enough by itself. There is a second case, harder to put in a spreadsheet, that engineers care about as much: JIT lets you ship a new protocol without re-packaging the catalogue.

Consider what happens when Apple ships a new variant of HLS, when CMAF gets a new flavour, when a customer-segment regulator suddenly requires DRM rotation on a thousand titles, when a new device family demands a manifest tweak. In a pre-packaged world, every one of those events is a re-packaging job — read every mezzanine off storage, run the new packaging settings, write every segment back, invalidate the CDN. For 10,000 titles, that is days of compute and a logistics tangle.

In a JIT world, the same change is a deploy. Update the origin's packaging logic; the next manifest request returns the new shape. The mezzanines on disk did not move. The CDN refills as viewers arrive. The total downtime is whatever it takes to redeploy the origin fleet — minutes, not days.

The reason every large OTT platform converged on JIT between 2018 and 2024 is partly the storage saving, and partly this: in a world where the streaming protocol landscape changes faster than catalogues do, the catalogue should be stored in a shape that survives protocol churn. JIT gives you that shape.

Where Fora Soft Fits In

Fora Soft has shipped video pipelines since 2005, including OTT and Internet TV platforms, e-learning catalogues, surveillance archives, and telemedicine recording systems where the same architecture decisions apply: how big is the catalogue, how many protocols and DRM systems must it serve, what latency budget can we spend at the edge, and where do storage savings end up worth more than origin compute. On the OTT side, we have built both pre-packaged origins for tightly scoped event archives and JIT origins (with origin shields, manifest-filter cache keys, and tuned CDN policies) for catalogues that grow into the thousands. On the e-learning side, JIT pays for itself the moment a course library passes a few hundred lessons. If your platform is in the band where the decision is non-obvious, the architecture review is short, concrete, and based on the same arithmetic above — and it usually saves money on the first migration.

What to Read Next

• Packaging in Depth: From Encoder Output to Manifest
• Origin Shielding and Tiered Caching
• CMAF: The Packaging Format That Unified HLS and DASH

CTA

• Talk to a streaming engineer — book a 30-minute architecture review of your current packaging stack.
• See our case studies — OTT, e-learning, and broadcast deployments where JIT origins or static origins were the right call.
• Download the JIT-vs-pre-packaged decision sheet — a one-page reference covering catalogue thresholds, storage arithmetic, cache-friendliness checklist, and the 2026 origin vendors. Download PDF

References

1. ISO/IEC 23000-19:2020 — Common Media Application Format (CMAF) for segmented media. ISO/IEC, 2020. https://www.iso.org/standard/79106.html — Tier 1. Defines the constrained fMP4 profile used as the canonical on-disk master for almost all 2026 JIT origins.
2. ISO/IEC 14496-12:2022 — ISO base media file format (8th edition). ISO/IEC, 2022. https://www.iso.org/standard/83102.html — Tier 1. Defines sidx, moof, mdat, styp, the box-level constructs every JIT origin parses and rewrites at request time.
3. ISO/IEC 23001-7:2023 — Common encryption in ISO base media file format files (4th edition). ISO/IEC, 2023. https://www.iso.org/standard/84637.html — Tier 1. Defines the cenc and cbcs protection schemes the JIT origin applies at packaging time.
4. ISO/IEC 23009-1:2022 — DASH Part 1: Media presentation description and segment formats (5th edition). ISO/IEC, 2022. https://www.iso.org/standard/83314.html — Tier 1. The DASH base specification whose MPD format JIT origins synthesise per request.
5. RFC 8216 — HTTP Live Streaming. R. Pantos, W. May. IETF, August 2017. https://datatracker.ietf.org/doc/html/rfc8216 — Tier 1. The HLS specification whose .m3u8 playlist format JIT origins synthesise per request; superseded by draft-pantos-hls-rfc8216bis for newer profiles.
6. HLS Authoring Specification for Apple Devices, revision 2025-09. Apple Inc. https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices — Tier 1. Apple's normative authoring rules that constrain what JIT origins must emit for Apple-ecosystem playback.
7. AWS Elemental MediaPackage v2 User Guide. Amazon Web Services, 2026. https://docs.aws.amazon.com/mediapackage/latest/userguide/what-is.html — Tier 3. The v2 architecture: origin endpoints, attached manifests (up to 25 per endpoint), built-in origin shield, aws.manifestfilter query-parameter family.
8. AWS Elemental MediaPackage Manifest Filtering Documentation. Amazon Web Services. https://docs.aws.amazon.com/mediapackage/latest/userguide/manifest-filtering.html — Tier 3. Defines the aws.manifestfilter query parameters and the cache-key rule they imply.
9. Unified Origin VOD Documentation. CodeShop / Unified Streaming. https://docs.unified-streaming.com/documentation/vod/index.html — Tier 3. The dynamic-packaging architecture: single .ism/fMP4 source, on-the-fly HLS / DASH / Smooth / HDS output.
10. Unified Streaming — Origin Shield Cache Recommendations. Unified Streaming. https://docs.unified-streaming.com/best-practice/caching/recommendations/shield-cache.html — Tier 3. The canonical guidance on shielding a JIT origin, including the cache-key parameters that must be honoured.
11. OTTVerse — What Is Just-In-Time Packaging (JITP) and What Are Its Benefits? Krishna Rao Vijayanagar, 2022. https://ottverse.com/what-is-just-in-time-packaging-jitp-benefits/ — Tier 4. Industry overview of the storage-multiplication problem JIT solves; useful for the "12× copies on disk" framing.
12. Eyevinn Technology — Server-less Just-in-Time Packaging with AWS Fargate and Unified Origin. Jonas Birmé, 2022. https://eyevinntechnology.medium.com/server-less-just-in-time-packaging-with-aws-fargate-and-unified-origin-by-unified-streaming-c1682dc051ca — Tier 4. Reference architecture for running Unified Origin on Fargate behind CloudFront, with the cache-key configuration that makes it work.
13. AWS Marketplace — Unified Origin VOD Streaming. CodeShop. https://aws.amazon.com/marketplace/pp/prodview-bf2bbuexjns6i — Tier 5. Confirms the per-CPU-core licensing model and AWS deployment shape for Unified Origin.
14. Unified Streaming — BBC Video Factory Case Study. CodeShop. https://www.unified-streaming.com/cases/bbc-video-factory-using-unified-origin-dynamic-packaging-all-formats-including-dvb-dash — Tier 4. The BBC's iPlayer JIT-packaging deployment; useful as evidence that JIT scales to broadcaster-size catalogues.
15. AWS Well-Architected Streaming Media Lens — Origin Selection. Amazon Web Services. https://docs.aws.amazon.com/wellarchitected/latest/streaming-media-lens/selection.html — Tier 3. AWS's own guidance on choosing between pass-through (pre-packaged) and dynamic (JIT) origins.