Why Encoding Takes Longer Than Playback
A device that plays a two-hour film without effort may spend twenty minutes exporting a three-minute clip. The asymmetry is designed in rather than accidental.
Encoding is a search, decoding is a recipe
An encoder must choose among an enormous number of valid ways to describe the same footage. Different block sizes, prediction modes and motion vectors all produce decodable output of differing quality and size.
Finding a good combination means trying many and evaluating each. The evaluation itself requires partially reconstructing the result to see how far it strays from the original.
A decoder faces no such choice. It reads the decisions already recorded in the file and carries them out in order, which is arithmetic rather than exploration.
Motion search dominates the cost
For every block the encoder looks for a similar region in nearby frames. Searching a wider area finds better matches and produces smaller files, but the work grows quickly with the search range.
Presets that promise speed mostly shrink that search. They accept slightly worse matches in exchange for finishing sooner, which shows up as a larger file at equal quality.
Slower presets are not doing anything different in kind. They are simply looking harder before committing.
Looking ahead requires buffering the future
Good rate allocation depends on knowing what is coming. An encoder that has seen the next few seconds can save data before a difficult passage arrives.
That lookahead means holding many frames in memory and analyzing them before writing anything. Live encoding cannot afford it and consequently produces larger files at comparable quality.
Some workflows analyze the whole video once and encode on a second pass. The first pass writes nothing usable and roughly doubles the time.
Dedicated hardware trades quality for speed
Fixed-function encoders built into processors and graphics chips are dramatically faster than general-purpose code. They implement a narrower set of decisions and search less thoroughly.
The output is entirely valid and plays anywhere, but at equal file size it usually looks slightly worse. The gap narrows at generous bitrates and widens at tight ones.
Live streaming and screen recording favor hardware encoding because finishing in real time is non-negotiable. Archival exports favor software encoding because time is available.
Parallelism helps encoding unevenly
Decoding parallelizes awkwardly because frames depend on earlier frames in a fixed order. Adding processor cores yields less than you might hope.
Encoding parallelizes better, since independent segments and separate frame regions can be examined simultaneously. Long exports scale reasonably with available cores.
The limit is dependency. Decisions about one frame inform the next, so some of the work remains stubbornly sequential no matter how many cores are available.
