.svg)
.svg)
PRODUCTS
When you upload a video and it takes time before it can be watched, what’s usually happening is pre-encoding. The platform immediately creates multiple versions of that video different resolutions and bitrates so it’s ready for every possible viewer before anyone presses play. It’s a safe approach, and for a long time it was the default.
It also means you pay the full cost upfront. Every upload trigger encoding jobs, storage, and delivery setup whether the video is watched once, a thousand times, or never.
That model breaks down fast in UGC platforms. Thousands of short videos get uploaded every day, most of which won’t see sustained traffic. But the system treats them all the same, and costs scale with uploads, not views.
Real-time transcoding changes that. You store a single master file. Nothing gets encoded until someone hits play.
TL;DR – What’s inside
This guide breaks down how real-time transcoding works and why it matters for modern video platforms. Inside, you’ll find:
At the core, it’s simple: you store one high-quality source, usually a mezzanine file. Nothing else is generated in advance.
Then a viewer shows up.
At that moment, your system makes a set of decisions:
Based on that input, you transcode exactly what’s needed , one or more renditions, at the right bitrate(s), using the right codec and then package the output into segments for delivery.
That includes:
It’s encoding + packaging + delivery, all stitched together at request time. So instead of pre-rendering five renditions of every video and hoping one of them is a close match, you generate the right one when it’s actually needed. This makes your pipeline reactive not predictive.
You just read how real-time transcoding kicks in the moment someone hits play, encoding exactly what’s needed based on device, network, and viewer context.
But that’s only half the job.
Transcoding gives you raw video. But that’s not what the player needs.
If you’re using HLS or DASH, and you almost certainly are the stream has to be:
This isn’t a separate batch step. In a real-time pipeline, it happens immediately after encoding, before the first segment is even requested.
Packaging is what turns the output into a playable stream. That means:
And it needs to be fast. Lag here means buffer icons, playback stalls, or worse, the video doesn’t play at all. In real-time systems, transcoding and packaging are tightly connected. Transcoding decides what gets delivered. Packaging decides how it reaches the viewer. If either one is missing, the pipeline breaks.
Before packaging and transcoding were coupled together, there were a few standard ways to get video ready for delivery. Each one solved a specific problem. None of them were built for what we expect today: fast playback, session-level logic, or efficiency at scale.
Let’s walk through the three common models, and where they fall short.
This diagram shows how traditional live streaming pipelines work.
The CDN then replicates segments across edge locations for faster delivery.
Why it worked:
Why it doesn’t scale today:
This model assumes every viewer gets the same stream. That’s the core limitation.
Used primarily for on-demand content, this method pre-processes everything. You take a video file, convert it into HLS/DASH chunks, generate the manifest, and store all of it, ready for whenever someone wants to stream it.
Workflow:
Why it worked:
Where it breaks:
Edge packaging tries to reduce the delay and network load by pushing the packager out to the CDN’s edge, closer to the viewer. Instead of packaging at a central origin, the stream is segmented at or near the CDN’s edge node, then handed off for delivery.
Why it helps:
But it comes with trade-offs:
None of these models are wrong. They were built for a different kind of video, when streams were predictable, devices were similar, and latency wasn’t a dealbreaker.
But today, that’s not the workload.
You’re dealing with thousands of device types. Fluctuating network conditions. Viewers who expect video to start instantly and adapt in real time. You need decisions made per session, not per file.
The diagram illustrates how a single master file moves through the pipeline, getting transformed and delivered based on each playback request:
Modern video products demand flexibility. Traditional pipelines with pre-encoded ladders can’t keep up with unpredictable formats, audiences, and workloads. Here’s where developers lean on real-time transcoding:
1. Playback in fast-moving platforms
Who it’s for: News outlets, OTT apps, UGC platforms
Why it matters: New videos appear constantly, and playback has to adapt instantly to device type, bandwidth, and viewer conditions. Real-time pipelines prevent delays and wasted storage on unused renditions.
2. Serving multilingual audiences
Who it’s for: Global streaming apps, education platforms, enterprise training systems
Why it matters: Audiences want subtitles, dubs, or alternate audio tracks in their own language. Real-time pipelines can deliver them per request without multiplying storage costs.
3. Instant live-to-VOD publishing
Who it’s for: Sports, concerts, events, classrooms
Why it matters: Viewers expect replays as soon as the event ends. Real-time transcoding turns live streams into on-demand assets immediately, without overnight processing jobs.
4. Personalized and monetized experiences
Who it’s for: Fitness platforms, e-learning apps, subscription services
Why it matters: User-level overlays, account-based watermarks, or gated content shouldn’t require separate files for every scenario. Real-time pipelines let you apply that logic dynamically at scale.
Real-time transcoding changes how you think about caching. You're no longer pre-generating thousands of segments and pushing them to the edge, you're responding to playback demand in real time. That means caching strategies need to evolve too.
Start with what’s worth caching:
Instead of brute-force caching, combine short TTLs (time to live) with edge invalidation logic. That way, you let the CDN serve what it can, while the backend steps in only when something changes, format, user context, or access control.
It’s not just about load reduction. It’s about smarter delivery: caching what matters, skipping what doesn’t, and letting your system stay responsive under pressure.
The FastPix API gives you direct control over how each video is prepared and delivered, no media pipeline complexity, no FFmpeg scripting, no manual workflows. You store a single master file and use API requests to handle everything else dynamically.
Here’s how it works:
You also get webhooks and analytics hooks:
You don’t need to spin up workers, manage queues, or pre-encode anything. The API figures out what’s needed, and delivers it. To know more on our offering please check our guides and docs.
When teams switch to real-time pipelines, the benefits go beyond performance, they show up in hard infrastructure savings and dev-time wins. Here’s what we see most often:
And just as important: your team isn’t building or maintaining this system. You’re calling an API that does the heavy lifting, reliably, scalably, and predictably.
Real-time transcoding doesn’t just cut infra costs; it clears out delivery bottlenecks. If you’re already personalizing content by user, region, or device, your video pipeline should do the same. FastPix lets you upload once, transcode on demand, and stream exactly what’s needed. Start with one video. See the difference.
JIT encoding processes video content in real-time, which can increase server load compared to serving pre-encoded content. To mitigate this, it's essential to optimize server resources and implement efficient encoding algorithms to handle on-the-fly processing without compromising performance.
Implementing JIT encoding requires robust security measures to protect content during real-time processing. This includes securing the encoding pipeline, ensuring encrypted transmission of video segments, and implementing access controls to prevent unauthorized access to the content.
JIT encoding can influence CDN performance by introducing additional processing steps before content delivery. It's crucial to configure CDNs to handle dynamic content efficiently, ensuring that encoded video segments are cached appropriately to reduce latency and improve user experience.
JIT encoding supports adaptive bitrate streaming by generating video segments in multiple quality levels on demand. This allows the streaming service to deliver the best possible video quality based on the viewer's network conditions and device capabilities, enhancing the viewing experience.
JIT encoding reduces latency by encoding only the segments needed for immediate playback. This minimizes the time between a user’s request and the start of playback, offering faster start times compared to streaming pre-encoded videos, which might involve waiting for large video files to load.
.png)
.png)
