Why do we need multiple resolutions of a video?

Publish a single video file and every viewer receives the same stream, whatever their connection can carry. The viewer on a train gets a file too large for the link they have; the viewer on fibre with a 27-inch monitor gets whatever you happened to export. Multiple resolutions exist so the file can stop being one decision made in advance and become a decision made continuously, on the viewer's device, while they watch.

From one source to several renditions

You upload one source file. Processing turns it into a set of renditions — the same content re-encoded at different frame sizes, each with its own video bitrate target. Each rendition is cut into short segments, and a manifest is written that lists what exists for that video and where each variant's playlist lives.

The manifest is the part the player reads first. It is not the video; it is the catalogue of what this particular video was encoded into. Everything the player does afterwards is constrained by what that list contains.

Your source is the ceiling

A rung is only produced when the source can actually support it. On DynTube, each rung is checked against the source's own height or width before it is enabled, so a 720p master does not yield a 4K rendition — and asking for one would only produce a larger file carrying the same detail. Re-encoding upwards adds bytes, never information.

Which rungs are produced is therefore decided per video, from what the source can support and from the options set on the project the video belongs to. There is no single ladder that every account and every video receives, and any article — including the older version of this one — that promises you a fixed set from 240p to 4K is describing a configuration rather than a guarantee.

A ladder is not just resizing

If renditions were only smaller pictures, one resize step would be the whole job. Three things make it more than that.

• Each rung is a resolution and a bitrate together. Frame size sets how much detail can be represented; bitrate sets how much of it survives compression. The right resolution at the wrong bitrate still looks wrong — blocky if it is starved, wasteful if it is over-fed — and how much a given rung needs depends on the content, since a talking head and a football match do not compress alike.
• The rungs have to be interchangeable mid-play. Every rung is encoded to the same normalised frame rate with a keyframe placed on a fixed interval, so the segments line up across the whole set and a player can stop taking one rendition and start taking another at a boundary without the picture breaking. That alignment, not the resize, is the expensive part of the work.
• Audio has to be accounted for separately from the picture. Depending on how the video is processed, the audio is either carried inside the video rungs or encoded once and delivered as its own track that every rung shares — which is also how a video with more than one language is served.

How the player chooses

Selection happens on the viewer's device, during playback, on a network neither you nor the hosting platform controls. The playback engine picks a rendition to start with and then keeps revisiting that choice as the play goes on. DynTube leaves that decision to the engine — the player sets a buffer target and otherwise does not steer it — so the honest description is what the choice depends on, not a rule you can predict.

What it depends on:

• How fast segments are actually arriving, and how that changes during the play, which is why the choice is revisited rather than made once.
• How much playable video is already buffered ahead of the playhead.
• The renditions the manifest advertises for that video. The engine can only choose from what exists.
• The playback engine itself and its configuration — the same video can behave differently in two browsers on the same network, because the code making the decision is different code.

When the viewer chooses

The DynTube player builds its quality menu from the renditions the manifest actually advertises, and labels them from each one's height — falling back to a bitrate label when a rendition does not match a familiar size. The list is not a fixed menu; it is a reading of that video.

• Auto is the default. The adaptive logic holds the decision until the viewer takes it away.
• If a video has fewer than two renditions there is nothing to choose between, and the menu is not shown at all.
• Picking a specific rendition pins the next segments to it rather than replacing what is already buffered, so the change lands from the following segment instead of instantly.
• Choosing Auto again hands the decision back to the adaptive logic and lifts any cap the manual choice left in place.
• Where the browser plays HLS with its own built-in engine rather than through the player's, the level list is never populated and the menu does not appear. Quality selection there is the platform's behaviour, not the player's.

Transcoding and adaptive selection are different things

These get conflated constantly, and the distinction is worth holding onto. Transcoding happens once, after upload: it is the production of the renditions and the manifest, and it is finished before anyone presses play. Adaptive selection happens on every single play: it is the runtime choice among renditions that already exist. Transcoding decides what is possible; adaptive selection decides what a given viewer gets. The mechanics of that runtime choice are covered in more depth in the adaptive streaming article linked below.

Get the most value from a rendition ladder

Multiple renditions can reduce the bytes transferred when a viewer’s connection or screen is better served by a lower rung. Use actual rendition and delivery data from your audience when estimating that benefit rather than assuming every session stays at the highest quality.

The player can also step down when throughput falls, helping it keep media buffered under changing conditions. Test the lowest rung, target devices and real page because connection loss, device decoding and page performance also affect the viewing session.

• Start with a high-quality source and verify the ladder produced by the project settings.
• Estimate delivery from the rendition mix your viewers actually receive.
• Test the lowest rung on a constrained connection and the highest rung on the largest supported screen.
• Expect a manual quality change to apply from following segments after already buffered media plays.
• Review small text and fine detail at lower renditions because every rung below the source is re-encoded.

The short version

Multiple resolutions exist because the conditions at playback are unknown at upload time. Encoding a set of renditions moves the decision from you, in advance, to the player, continuously — and that is worth doing precisely because you cannot see the viewer's connection, screen or device from where you are standing.