Understanding the FLV Video Format and Its Technical Structure
FLV files store video and audio as a sequence of tagged data blocks rather than a single continuous stream. The file begins with a short header that starts with the three bytes spelling FLV, followed by a version number, a byte that shows whether audio or video tracks are present, and an offset value that points to the first tag. After the header every piece of content arrives inside its own tag. Each tag carries a type byte that marks it as audio, video, or script data, then a three-byte length field, a timestamp, and finally the actual payload bytes. A player reads the header once, then walks through the tags in order, decoding only the parts it needs at any moment.
Video and Audio Codecs Commonly Found in FLV
Early FLV files most often used Sorenson Spark for video and either uncompressed PCM or MP3 for audio. Later releases added support for On2 VP6 video, which gave noticeably better image quality at the same bitrate. When Adobe opened the format further, H.264 video and AAC audio became possible inside the same container, though not every older player could handle the newer streams. Audio tracks could also use ADPCM or Nellymoser, choices that traded file size against CPU load on the decoding side. A developer testing playback on older hardware might therefore keep the audio track in MP3 even when the video had moved to H.264, simply because the machine handled MP3 decoding without extra effort.
Metadata Tags and Playback Behavior
Script data tags sit alongside the audio and video tags and carry information the player can read without decoding frames. The most frequent one begins with the string onMetaData and holds a list of key-value pairs. Typical entries record the total duration in seconds, the pixel width and height of the video, the frame rate, the audio sample rate, and a boolean that tells whether the file contains a keyframe index. A web player uses the duration value to build a seek bar and the keyframe times to jump to the nearest previous frame when the user drags the slider. Without these tags a player still works, but it must scan the entire file first to learn where the keyframes sit, which delays the start of playback on large files.
How File Size Compares with Other Web Containers
The overhead inside an FLV file stays small because each tag header is only eleven bytes long and the container does not repeat structural information at every keyframe. An MP4 file, by contrast, stores its sample tables in separate boxes that can grow when many tracks or edit lists are present. In practice a short clip encoded with the same H.264 settings often ends up a few percent larger in MP4 than in FLV, mainly from the extra box headers. The difference shrinks once the clip exceeds a few minutes because the actual video and audio data dominate. WebM files using VP8 or VP9 tend to run larger at equivalent quality when the source material contains fine detail, yet they avoid any licensing questions that once surrounded H.264. The choice between containers therefore depends less on raw size and more on which decoder the target devices already contain.
Players locate the first video tag by reading the header offset and then skip any audio tags they cannot decode. When a file mixes H.264 video with MP3 audio, a modern decoder handles both without trouble, while an older one may play only the audio until it reaches a tag it recognizes. The same tag structure lets a single file hold multiple audio tracks, each marked with its own codec identifier, though most FLV files seen on the web contain only one of each type. Because the tags arrive in presentation order, a simple streaming server can forward the file byte by byte without first rewriting the headers. This property kept FLV popular during the years when bandwidth and decoder availability varied widely across different computers.