What is Just-in-Time Packaging?

Traditional packaging creates all bitrate variants and manifests before upload. You store these files on an origin server. When a viewer connects, the server simply serves the pre-made files. This is simple but expensive in storage.

Just-in-Time Packaging flips this model. You upload a single source file or a set of CMAF segments. The packaging server waits for a client request. When a request arrives, the server reads the source data and generates the specific manifest and segments the client needs. It does this in real time.

The process involves a few key steps:

• The client sends a request for a manifest.
• The packaging server validates the request and checks access rights.
• It generates the manifest file dynamically.
• It creates or retrieves the necessary media segments.
• It serves the data to the client.

Because the files are created on the fly, you do not need to store every possible combination of bitrate and format. This is especially useful when you support many device types or use different DRM systems. The server acts as a translator between your stored media and the specific format the player requires.

Storage costs scale with the number of files you keep. Pre-packaging creates many files for each video. If you have thousands of titles, this adds up quickly. JITP reduces this overhead. You store the source media once. The packaging layer handles the rest. This means your storage bill stays lower as your library grows.

There is also an operational benefit. When you update a video, you only replace the source file. You do not need to re-package and re-upload dozens of variant files. This speeds up content updates. It also reduces the risk of version mismatches between manifests and segments.

For operators, this model shifts the cost from storage to compute. Your origin server must work harder during peak traffic. You need to monitor CPU and memory usage closely. If your server cannot handle the packaging load, playback will stutter. Plan your infrastructure to handle these spikes. JITP is a trade-off: lower storage costs, higher processing demands. It works best when you have a large library or complex delivery requirements.

Operators often overlook the compute requirements of JITP. They assume the server will handle the load easily. It does not. Packaging is CPU-intensive. If you do not scale your origin servers, you will see latency issues during peak hours.

Another error is ignoring cache headers. JITP-generated manifests should have short cache times. If you cache them too long, clients may get stale data after a content update. Set appropriate TTLs for manifests and segments.

Finally, do not mix JITP with pre-packaged files without a clear strategy. If you have some titles pre-packaged and others JIT, your monitoring tools must handle both. This complexity can hide performance issues. Keep your packaging strategy consistent across your library to simplify operations.