Video transcoding in Emby

Emby video transcoding creates a new encoded video representation when the selected source needs another format, bitrate or picture presentation for playback.

In Emby's video-transcoding mode, the server produces a replacement encoded video representation for the playback session. It decodes the source pictures, performs any required picture processing, and encodes the output.

The video codec name can remain the same. H.264 video encoded again at another bitrate or resolution is still a new video representation.

What requires another representation?

Session requirement	Possible video work
Source codec or parameters are unusable in this path	Encode an accepted video format/configuration
Delivery needs a lower video bitrate	Produce another rate-controlled representation
Picture dimensions must change	Scale decoded pictures before encoding
An HDR source needs an SDR server output	Apply suitable colour/range processing and encode the result
Subtitles must become picture content	Render subtitle pixels before video encoding

These operations describe different reasons to use the same broad conversion pipeline. They do not imply that every session needs every stage or filter.

Emby's Transcoding documentation identifies format, bitrate and subtitle handling among the reasons a session can need conversion. The actual plan depends on the source, selected tracks and client context.

A same-codec example

Take an original fictional source with 1920 × 1080 H.264 video and a target requiring 1280 × 720 H.264 at a lower rate.

Property	Source	Requested output in this example
Codec family	H.264	H.264
Picture dimensions	1920 × 1080	1280 × 720
Frame cadence	24 fps	24 fps
Video representation	Existing encoded stream	Newly encoded stream

The matching codec labels do not make this a stream copy. The dimensions and encoding decisions have changed.

A lossy output adds another approximation of the reconstructed pictures. Its result depends on the output dimensions, bitrate/rate control, encoder and content complexity. Copying the original video would preserve its encoded representation but would not perform the requested scaling or rate reduction.

Other streams can take another path

A session that encodes replacement video can still copy compatible audio. It can supply subtitles separately, convert them to another supported form, or burn them into the pictures if that is required.

Thus the mode does not imply that all tracks were encoded. The per-stream operations explain which content and technical properties changed.

Likewise, a Direct Stream session can convert audio while preserving video. Looking only for any occurrence of the word “transcode” obscures that distinction.

Requirements and capacity are different questions

Selecting an appropriate output plan does not establish that the server can produce it fast enough under current load. Decoding, filtering, encoding, storage and delivery all contribute to the result.

Hardware can accelerate supported parts of a pipeline, but a hardware encoder does not automatically accelerate every filter or remove transfer costs. The bottleneck article develops a simple capacity example.

A lower requested bitrate can reduce delivery demand while adding server processing. A compatible original source can reduce conversion demand while requiring more network throughput. These are different constraints rather than a universal ranking of modes.

The source remains the source

On-the-fly playback conversion ordinarily creates session output without replacing the original library resource. Its technical output description should therefore remain separate from the source description.

For the 1080p-to-720p example, source media information can correctly report 1920 × 1080 while playback information reports the 1280 × 720 output. Those values describe different points in the same session.