Formats, Manifests, and the Meaning of ‘Best’
For yt-dlp, “best” is not a property printed on one file waiting to be picked. It is a decision made over the representations a site currently exposes, the user's priorities, and the local tools available to deliver them. This chapter explains how yt-dlp models those representations and how it turns HLS, DASH, and related manifests into comparable candidates without erasing their constraints. The result is a practical way to read a format table and predict why the highest resolution may not be the most suitable or even usable choice.
A format is a candidate, not a verdict
A media page often offers several ways to watch or listen to the same item. One may be a pre-combined file containing both video and audio. Another may contain only the video track, with the audio delivered separately. There may be multiple resolutions, codecs, languages, frame rates, dynamic ranges, containers, protocols, and estimated sizes. Some entries may be intended for live playback, some may be incomplete, and some may be protected or otherwise unplayable.
yt-dlp represents these as formats. A format is a candidate with evidence attached to it: a URL or manifest, a file extension or container, video and audio codec information, dimensions, bitrate, language, protocol, fragment details, and access or integrity qualifiers. Those fields do not all answer the same question. Height describes one aspect of visual size; codec affects compatibility and compression; bitrate may indicate data rate rather than perceptual quality; protocol affects how the bytes arrive; and the presence of audio determines whether a video is immediately usable as a complete media file.
This is why a format identifier is not a universal ranking. A service-specific code may distinguish two candidates for that service, but it does not by itself explain how either candidate compares with a format from another extractor. The shared information model adds comparable properties where the source provides them, then lets selection policy interpret those properties. If a field is unavailable, the uncertainty remains part of the decision. The system does not gain knowledge merely because a candidate has a familiar-looking name.
The default choice illustrates this policy-based design. When merging is available, yt-dlp generally prefers a strong video representation together with a strong audio representation, while retaining a fallback to a combined format. If ffmpeg is missing, if the output is being streamed directly, or if the media is live in a mode that cannot be treated as a finished file, the default can change. The same site response can therefore produce a different result on two machines or under two output modes without either result being a contradiction.
The selector language makes the user's policy explicit. A slash expresses preference with fallback: try the left choice, then use the right one if the first has no suitable candidate. A plus asks for formats to be combined, typically a video stream and an audio stream. A comma requests several formats separately. Parentheses group a choice before a filter or another operation. Conditions in brackets can constrain dimensions, size, codecs, protocol, extension, language, or other fields supplied by the extractor. These operators are useful because they express intent rather than forcing the user to memorize a service's current format codes.
Suppose a reader wants a video no larger than a certain resolution, prefers a particular codec, and is willing to merge separate streams. That request is not equivalent to “choose the row with the largest height.” The desired candidate must satisfy a set of conditions, and the fallback must be meaningful if no candidate satisfies all of them. A resolution cap can preserve storage or device compatibility. A codec preference can avoid a format the target player cannot decode.