Three questions decide the cost and the quality of almost every delivered video file: which container carries the streams, which constant-quality knob governs the bitrate, and which silicon does the arithmetic. This portal answers those questions with reproducible reasoning rather than slogans.
The encoding workflow, stage by stage
Every transcode passes through the same conceptual stages. A demuxer splits the source into its elementary streams; a decoder reconstructs frames into a linear colour space; a filter graph resizes, normalises and deinterlaces; an encoder compresses the result against a rate or quality target; and a muxer writes the output bitstream back into a container. Errors introduced anywhere in that chain survive to the end, which is why mature pipelines validate each stage rather than trusting the final file alone.
In practice the encoder stage deserves most of the attention, because it is where the compression ratio is decided. Rate control receives raw frames and a budget, and it must decide how many bits each frame is allowed. Constant-quality modes hand the encoder a perceptual target and let the bitrate float; constant-bitrate modes hand it a fixed envelope and let quality float. Most on-demand catalogues live somewhere between those poles, using capped quality to keep peaks from destabilising delivery.
1. Container differences: MP4, MKV and WebM
A container answers fewer questions than people assume. It defines an index, a packet layout and a set of metadata boxes, but it does not define compression. The same AV1 bitstream can be carried in MP4 for compatibility with consumer television hardware and in WebM for progressive web playback. Matroska is the most permissive of the three and is the natural home for multiple audio tracks, chapters and attached subtitles. Understanding which container is the right carrier is a compatibility decision, not a quality decision. The container formats module expands this comparison in detail.
2. Constant-quality algorithms: CRF and RF
Constant Rate Factor and its siblings describe the same underlying idea with different arithmetic: give the encoder a perceptual target, and let the number of bits follow the content. Lower values mean higher quality and larger files. Because the relationship between the number and the result depends on the codec, the resolution, the frame rate and the source noise floor, there is no universal correct value. There is only a value that is defensible for a stated delivery target. The CRF and RF module walks through the derivation.
3. GPU acceleration: NVENC, Intel QuickSync and Apple VideoToolbox
Hardware encoders trade some compression efficiency and fine-grained control for enormous throughput and low power draw. NVENC on NVIDIA silicon, QuickSync on Intel integrated graphics and VideoToolbox on Apple platforms each expose a different subset of the codecs and features available in software encoders. For archival masters, software encoders still lead; for high-volume delivery, hardware encoders frequently win on economics. The GPU acceleration module and the tooling comparison map those trade-offs concretely.
How to read this portal
The keyframe strip at the top of every page mirrors the structure of a GOP: a standards group at the start, a practice group in the middle, field notes that record measured settings, and a reference group at the end. Each group opens onto its own pages. The glossary defines every acronym on first use elsewhere, and the FAQ collects the questions that recur in editorial correspondence.
Nothing on this site is a call to acquire software, and no binaries are offered here. Our work is analysis: we document parameters, compare approaches and explain the engineering reasoning behind published defaults. Where we cite a product, we use its name for identification and analysis only.