Transcoding

General definition

Transcoding takes compressed media, fully decodes it to raw frames or samples, and encodes it again with different parameters. Change the codec (H.264 to VP9), the resolution (1080p down to 360p, sometimes called transsizing), the bitrate (transrating) or the frame rate, and you are transcoding. Merely moving the same encoded stream into a different container, say from MP4 to fragmented MP4 for streaming, is remuxing and costs almost nothing by comparison, because the expensive step is the encode.

In real-time calls the distinction defines the architecture. A Multipoint Control Unit (MCU) decodes every participant, composites them into one picture, and encodes a single stream per viewer; that is transcoding on every call, which is why MCUs need heavy server CPU and add tens of milliseconds of delay. A Selective Forwarding Unit (SFU) never decodes: it forwards each participant’s packets, choosing among simulcast layers the publisher already encoded. Modern calling platforms use SFUs precisely to avoid transcoding, and push adaptation to the endpoints and the encoder.

• Recording: an SFU can save each track as received, but a composite recording that shows everyone in one frame requires a mixer to decode, lay out and re-encode, which is a transcoding job
• Live streaming: a broadcast that arrives over RTMP or WebRTC is transcoded into an encoding ladder of renditions and packaged for HLS or DASH so that thousands of viewers can each pick a suitable quality
• Compatibility: a device that lacks a hardware decoder for a given video codec needs the stream transcoded to one it can play, which is why H.264 remains the safe fallback
• Archiving: recordings are often transcoded once more into a smaller long-term format after the event

The cost is compute. Software encoding of one 1080p H.264 stream in real time consumes roughly a CPU core; VP9 and AV1 cost several times more. Hardware encoders on GPUs and dedicated media chips handle many streams per device, and cloud services price transcoding per minute of output. FFmpeg is the common open-source tool for offline and pipeline transcoding, and most video platforms wrap it or a hardware equivalent. Planning a media feature means deciding early where, if anywhere, transcoding happens, because it sets both the server bill and the latency budget.

In the Ethora ecosystem

Ethora’s voice and video calls are built on WebRTC with an SFU media server, which means there is no transcoding in the call path: each participant encodes once, the SFU forwards packets and picks simulcast layers, and quality adapts at the edges. That keeps server cost proportional to bandwidth rather than to CPU-heavy encoding, and it keeps the latency of a group call close to a one-to-one call. Audio-only calls are available as an opt-in for products that do not need video at all.

If a product built on Ethora needs a composited recording or a broadcast to a large audience, that is a separate media pipeline downstream of the SFU rather than part of the calling stack, and it is easiest to scope alongside the deployment: on a dedicated or self-hosted installation the media server and any transcoding workers run inside your own cloud account, so recordings and streams stay under your data controls. The voice and video call API page lists what the calling features include today.