Why is the same file sometimes fast and sometimes slow?

It depends on the mode: stream copy (container swap only) finishes in seconds; re-encoding runs the full decode-filter-encode chain where encoding dominates. The same file can differ by two orders of magnitude between modes.

Is a stuck progress bar a crash?

Rule out fake freezes first: background tabs get throttled, and refocusing resumes the progress. A real stall shows zero change for a long time with CPU usage at zero — cancel, check the file, retry.

How do I make transcoding faster?

By value: lower the resolution (pixels scale time linearly), loosen the preset, use hardware acceleration for big archive jobs, and stream-copy whatever does not need re-encoding. Stacked, these cut time by an order of magnitude.

How it works 6 min read

Where Transcoding Time Goes: Decode, Filters, Encode

Same kind of job, wildly different runtimes — one conversion finishes in seconds, another runs for tens of minutes. The gap is not mysterious: a transcoding pipeline has three stages with very different bills.

The three stages

Stage one, demux and decode: split the container, decompress the frames back to raw pictures — single-digit percent of total time on modern hardware. Stage two, filters: scaling, cropping, subtitles, denoising — cost scales with operation count and resolution, moderate. Stage three, encoding: recompressing the processed frames — the overwhelming majority, 70-90 percent of a re-encode’s runtime.

Why encoding is so expensive: every frame goes through motion estimation, transforms, quantization and entropy coding, an order of magnitude costlier than decoding. This is also why stream copy finishes in seconds — it skips stage three entirely and pays only for file I/O.

Four variables decide the speed

Pixel count comes first: 4K has four times the pixels of 1080p and encode time scales near-linearly — dropping resolution is the harshest time cut. Codec efficiency is second: newer codecs (HEVC/AV1) compute more and take multiples longer. Preset is third: from ultrafast to veryslow, better quality per bit at multiples of the time. Hardware acceleration is fourth: GPU encoders run several to dozens of times faster at slightly softer equal-bitrate quality.

In-browser processing adds one more constraint: the sandbox limits available memory and CPU cores, so large files take longer than desktop software on the same machine.

Locating the bottleneck

Progress moving slowly but steadily: normal — the encoder is working, wait it out. Progress stuck at the very start: likely a decode-stage problem — odd container, unsupported codec, or a file too large to load comfortably. Progress flying but the output corrupt: stage three was skipped or interrupted; re-run and verify parameters.

One more fake-freeze: browsers throttle background tabs, so a de-focused processing tab can look dead — refocus it and the progress resumes. Keep the tab in the foreground for large jobs.

Spending less time, in order of value

Ranked by payoff: first ask whether 4K is needed (down to 1080p saves three quarters of the time); then loosen the preset (fast tiers for drafts, slow tiers for finals); consider hardware acceleration for large archive jobs; and never re-encode what a stream copy can do — TS to MP4 or MKV to MP4 are container swaps that finish in seconds.

Set expectations honestly: in-browser local transcoding will not match desktop software, but with zero upload and zero queue it nets out ahead for everyday workloads. Only the triple stack — very long, very many, very picky — belongs on desktop tools.