Live video transcoding guide
Start with the output contract, not a preset name
Video transcoding takes an already encoded input, decodes it and creates a different encoded output. In a live workflow, that may mean changing H.264 to HEVC, scaling 1080p to 720p, lowering bitrate for a constrained destination or building several aligned renditions for adaptive playback. The useful question is not “Which preset is best?” It is “What must each receiver be able to decode, and what evidence will prove it?”
The working definition
Encoding creates a compressed representation from a source. Transcoding converts an encoded source into another encoded representation. Transmuxing changes the container or delivery wrapper while preserving the encoded media. Scaling changes image dimensions and usually happens inside a transcode. Keeping those operations separate prevents an unnecessary generation of compression.
Callaba applies supported video and audio processing inside a Restreaming workflow, in cloud or on self-hosted Linux infrastructure. Use Callaba Live Video Transcoding to compare product and deployment options. When it is time to configure a job, follow the current controls in the Restreaming user guide.
The moving workload bar and readiness markers explain the processing sequence; they do not report measured utilization or promise a specific number of outputs. Reduced-motion users receive the same static decision diagram.
Transcode only when the receiver contract requires it
Every full transcode consumes processing capacity and can remove picture detail. Preserve the source when its codec, profile, resolution, cadence, audio and rate already satisfy the destination. Transcode when a real mismatch exists: the receiver cannot decode the source, the raster or bitrate is unsuitable, the destination requires another keyframe interval, the audio layout differs, or an adaptive ladder needs additional renditions.
Contribution normalization
A field encoder sends a high-quality feed, but the control room expects another bitrate, raster or codec. Build one normalized handoff and verify it at the production decoder.
Platform-specific output
A social or OTT destination publishes its own media requirements. Create a separate output only for the settings that differ instead of changing the common source for every receiver.
Adaptive playback
Several aligned renditions give an HLS or DASH player choices as bandwidth and device conditions change. The ladder still needs compatible packaging and playback validation.
Archive or proxy creation
A recording or editorial system may need another codec or a lower-resolution proxy. Treat that as a separate deliverable with its own quality and timing requirements.
Write the profile as a contract
| Profile field | Decision | Acceptance evidence |
|---|---|---|
| Codec and profile | Choose a codec, profile, level and bit depth supported by the final receiver. | Decode representative motion, graphics and color on the actual destination. |
| Resolution and aspect | Set the output raster and scaling policy; define crop, pad or preserve behavior. | No distorted geometry, accidental crop or unexpected black bars. |
| Frame cadence | Preserve cadence unless a receiver explicitly requires conversion. State any interlace handling. | Motion has no unexplained judder, duplicate cadence or field artefacts. |
| Rate control | Choose target rate, quality policy, preset and enough headroom for difficult scenes. | Measured bitrate remains acceptable while motion and detail meet the visual target. |
| GOP and keyframes | Align the keyframe interval with the packager or destination requirement. | Probe the output and verify clean segment and rendition changes. |
| Audio | Specify codec, sample rate, bitrate, channel count and selected program. | Listen after the final handoff and check synchronization; meters alone are insufficient. |
A profile name such as “1080p high” is not a contract. It omits the codec, rate-control behavior, frame cadence, GOP, audio and receiver. Version the complete profile so an operator can tell what changed after an incident.
Build an adaptive ladder from audience evidence
An adaptive bitrate ladder is a set of related renditions that a compatible player can switch between. More rungs are not automatically better. Each output adds processing, packaging, delivery and quality-assurance work. Start with the devices, displays and network conditions the audience actually uses. Add a rendition when it closes a meaningful compatibility or bandwidth gap.
Keep keyframes aligned across the ladder when the packaging and player workflow depends on clean switching. Test startup on a constrained connection, movement through the ladder, recovery after a bandwidth drop and the highest-rendition picture on a large screen. A valid manifest does not prove a useful viewing experience.
Choose CPU or acceleration from a concurrent-load test
Software encoding on CPU can be flexible and easy to place. A supported GPU or dedicated media engine can improve live-stream density and make processing time more predictable for repeatable profiles. Neither label is a capacity result. Filters, scaling, audio, multiplexing, device memory and network traffic may become the limiting resource even when an encode engine has headroom.
Test the exact inputs and outputs at expected concurrency. Record initialization time, processing stability, dropped or duplicated frames, resource headroom and recovery after one input disappears. Reserve capacity for a restart or replacement path. The related hardware acceleration and Enhanced RTMP guide covers accelerator boundaries and modern-codec signalling in more depth.
Configure one Callaba output before building the ladder
- Verify the input. Confirm its codec, raster, frame rate, bitrate, keyframe cadence and audio before changing anything. If the source itself is wrong, transcoding can hide rather than solve the upstream fault.
- Create one Restream. Select the proven source and the intended destination. Enable only the video and audio changes required by that receiver.
- Decode the result. Check picture, movement, audio, synchronization and destination state. Use a real receiver or player, not only a connected indicator.
- Exercise interruption. Stop and restore the source. Observe whether the processing output reconnects and whether the receiver resumes without an undocumented action.
- Add concurrency gradually. Create the next rendition or stream only after the first profile has a recorded baseline. Measure the complete planned set at peak load.
If the first operation passes, the Restream live-transcoding API workflow can reproduce an approved profile from an authenticated control system. API success confirms the control request; it does not prove that the output looks or sounds correct.
Diagnose the boundary that is actually failing
Input is absent or unstable
Preserve the profile and investigate contribution first: encoder state, transport, incoming bitrate, packet behavior and decoded source. Changing output quality cannot create missing source frames.
Input is healthy, output will not start
Check codec availability, profile support, output URL, container and destination authentication. Keep the known-good input running while isolating the processing stage.
Output connects but video is black
Inspect codec profile, bit depth, pixel format, raster and receiver support. A network connection is not evidence that the destination can decode the media.
Latency grows under load
Look for queued processing, exhausted sessions, an expensive filter or destination backpressure. Reduce concurrency or simplify the profile before changing unrelated transport controls.
Official technical references
- FFmpeg transcoding documentation — decode, filter and encode processing terminology.
- Apple HLS authoring specification — current media and rendition requirements for Apple playback environments.
- W3C Media Source Extensions — browser media-buffer and adaptive playback interface context.
Frequently asked questions
What is the difference between encoding and transcoding?
Encoding creates compressed media from a source. Transcoding decodes an already encoded input and creates a different encoded output, such as another codec, bitrate or resolution.
Do I need to transcode every live stream?
No. Preserve the source when it already meets the receiver contract. Transcode only to solve a documented codec, resolution, bitrate, cadence, audio or rendition requirement.
How many renditions should an ABR ladder contain?
Use the fewest renditions that cover meaningful device and bandwidth conditions. Test startup, switching and visual quality with representative viewers and content rather than selecting a fixed count.
Turn one receiver requirement into a measured profile
Start with one verified input and one required output. Accept the profile only after the final receiver decodes it, the deployment sustains it, and the workflow recovers from an interruption.
Explore Callaba Live Video Transcoding