Sophie’s Codex of Codecs, Containers, Copyrights, Confusion, and Compression

“Awful Aural & Vibrant Video”

First edition • 26 September 2026

Part of Sophie’s Cabinet of Computing Curiosities. Although file formats have already been covered, audio and video needed their own article.

Audio and video files are a right bloody mess. We use “format” to mean the arrangement of bytes in a file, the mathematics that squeezed the sound, the rules for reconstructing pictures, the name on a player’s download page, and occasionally whatever three letters happen to follow the last full stop. These things are connected, but they are not interchangeable. The resulting confusion is sufficiently well established to have its own standards documentation.^[1]

This cabinet opens those layers separately: containers first, audio codecs second, video codecs third. It then puts them back together to explain playback failures, conversion, copyright, and preservation. Obsolete formats are included deliberately. A format can leave the market while leaving your only copy of something rather important behind.

My own near miss involved videos from around 2003 which I eventually recovered using VLC’s conversion facilities. At the time, that was a useful example of why a working decoder matters; without examining the files themselves, however, I could not reliably say what they actually contained. We shall return later to one of those files, now properly inspected, as a worked example of containers, codecs, transcoding, metadata, and preservation.

Contents – A map of the mess

Read straight through, or use the links below. The pink HELP! call-outs assume no technical background; the orange SUPER-TECH call-outs are entirely optional.

Call-out key:

• purple = Cabinet notes
• pink = HELP!
• orange = SUPER-TECH.

The layers hiding inside a file

Start with a hypothetical file called holiday.mp4. Its name suggests a container from the MP4 family. Inside might be an H.264 video track, AAC audio, subtitles, timing information, and descriptive metadata. Another MP4 could hold HEVC video and entirely different audio. A player can understand the container and still fail to decode one of its tracks. Conversely, a decoder may understand the video coding but never receive it because the surrounding file is unsupported or damaged.^[2][1]

An encoder creates the coded representation; a decoder reconstructs pictures or sound from it. “Codec” commonly denotes the coding format and also the software or hardware implementing it. We therefore say both “the H.264 codec” and “this encoder produces better H.264”. The standard usually defines what a conforming bitstream means and how to decode it, while giving encoders considerable freedom over how to find a good representation.^[3]

These are conceptual layers, not a promise that every file has seven neatly separated compartments. Some elementary streams carry their own timing or metadata. Some file formats are closely tied to one codec. Some recordings are packages containing several files. The useful distinction is between jobs, rather than an insistence that every historical design followed the same architecture.

The words on the tin

MPEG’s own catalogue separates systems, video, and audio standards. That organisation is considerably more helpful than a download button labelled “MPEG”. The letters stand for Moving Picture Experts Group, but the group also standardises sound. The audio engineers did not forget which meeting they were attending.^[4][5][6]

Compression without the sales patter

Uncompressed media stores a relatively direct representation of samples or pixels. Lossless compression exploits redundancy while permitting exact recovery of the data presented to the encoder. Lossy compression allows differences in exchange for smaller output, normally trying to put those differences where people are least likely to notice them.

That last phrase carries a great deal of work. “Least likely to notice” depends on the material, the encoder, the settings, the listener or viewer, and the conditions. A recording of a harpsichord, a noisy night scene, scrolling computer text, and a talking head present different difficulties. A codec’s name alone cannot supply a universal quality ranking.

Stream copying, as implemented by FFmpeg, bypasses decoding and encoding. It is useful when the contents are suitable but the wrapper is inconvenient. It cannot make an unsupported codec become supported, nor guarantee that every piece of information has an equivalent home in the new container.^[7]

Lossless is a statement about a boundary

FLAC can reproduce the integer PCM samples supplied to it. It cannot reconstruct the information already discarded when an MP3 was made. Turning that MP3 into FLAC preserves a decoded version of the MP3; it does not restore the recording that existed before compression. Similarly, FFV1 can preserve decoded video samples without another lossy coding stage, but does not recover detail lost by Cinepak twenty-five years earlier.^[8][9]

Even “lossless conversion” needs a description of what was held constant. If the conversion silently changes 10-bit colour to 8-bit, downmixes six audio channels into two, or drops subtitles, the fact that its final encoder is lossless will offer little comfort. There is no meaningful virtue in perfectly preserving the wrong intermediate result.

Bitrate and the tyranny of arithmetic

Bitrate is the number of bits used per second. A constant bitrate aims at a steady rate; variable bitrate lets difficult passages use more. Average bitrate describes a target or measured average over time. Quality-oriented modes let size vary in pursuit of a chosen quality setting. The same numerical setting in two encoders need not mean the same thing.

For a rough size estimate, multiply total average bitrate by duration, then divide by eight to obtain bytes. Container overhead and additional streams add to the result. Decimal megabits and megabytes are used below; binary MiB and GiB are different units.

These are calculations, not recommended encoding settings. The last row also explains why video compression exists without requiring a single marketing adjective. “Only a few hours of footage” becomes an interesting conversation with the storage administrator.

A short history of constrained enthusiasm

The history is not a tidy succession in which each new format killed the old one. Telephone networks, CD-ROM drives, early web connections, broadcast systems, editors, and pocket devices imposed different constraints. We accumulated answers. Then we accumulated compatibility problems between the answers.

The periods describe prominence and context, not exact invention dates. Formats cross those boundaries and remain in use long after their supposed era. In particular, “old” can mean well understood and dependable; it can also mean the only decoder is sulking on an operating system that nobody should connect to the internet.^{[10][11][12][13][14][15][16][17]}

There is a further complication: a codec can outlive the product that introduced it. The retirement of a player or framework does not necessarily make its files unreadable. Independent implementations may keep the coding alive. Equally, having a specification does not prove that an adequate decoder exists for your precise variation.

Containers for everyday sound

Audio files do not all work the same way. WAVE and AIFF are wrappers with defined structures; FLAC is both a coding specification and, in common use, a native file format; an MP3 file commonly contains a sequence of coded audio frames with tags. A useful catalogue acknowledges the overlap instead of trying to shove every name into one perfectly rectangular pigeonhole.

WAVE goodbye to the easy assumption

WAVE is based on RIFF, which organises information into labelled chunks. One chunk describes the format, another holds audio data, and others may carry extra information. “WAV is lossless” is therefore an unreliable shortcut: a WAVE wrapper can contain a lossy encoding. It is the combination that matters.^[18][19]

Broadcast WAVE adds information intended to travel with professional audio. A recorder’s useful description, origin, timing reference, and other metadata can matter decades later. A consumer converter may preserve the sound and discard those clues. That is a successful listening copy and an incomplete preservation copy, both at once.^[20]

Traditional RIFF size fields create a roughly 4 GiB ceiling, subject to format details and implementation limits. RF64 extended that scheme; EBU now points to ITU-R BS.2088 as having effectively superseded its RF64 specification. None of this is the same as a filesystem’s maximum file size. An audio format and a USB stick can impose separate limits, because apparently one limit was insufficient.^[21]

Containers for pictures with ambitions

Video containers normally need to keep different kinds of timed material together. A film can have several audio languages, subtitles, chapters, attachments, and metadata alongside the pictures. “The video works” may mean only that the first video track happened to decode.

Examples are deliberately not exhaustive lists of permitted combinations. “Technically permitted”, “accepted by this muxer”, “played by this app”, and “accelerated by this television” are four separate tests.

MP4 and MOV are relatives with complicated paperwork

QuickTime’s format uses structures traditionally called atoms. The ISO Base Media File Format provides a related, general framework, and MP4 is a particular format built on that framework. Other descendants and applications include 3GP and fragmented media used in streaming. Knowing the family resemblance helps; treating every member as identical does not.^[29][2][39]

For many ordinary MP4 files, metadata needed to locate samples lives in a moov structure. If recording ends before that information is written, a large file can contain substantial media data but lack the information needed for normal playback. Moving a completed index towards the beginning, commonly called fast start, improves progressive delivery; it does not recreate an index that was never written. Fragmented MP4 organises timing and sample information differently, and deserves diagnosis on its own terms.^[40]

A container is sometimes only part of the package

A DVD directory, an AVCHD camera card, a Digital Cinema Package, or an Interoperable Master Format package may contain several related files, navigation information, playlists, and metadata. A single large media file is not necessarily the complete work. IMF explicitly separates compositions and their component assets; MXF is one component of that professional world, not a synonym for the whole package.^[41]

QuickTime also permits references to media outside the movie file. Losing the referenced material can leave a plausible-looking MOV that has little to play. Preserve original directory structures when importing uncertain legacy material. “I copied the biggest file” is a perfectly understandable human decision and a poor preservation policy.^[29]

Things that look like media files but are not the media

The practical question is whether the item contains the experience or describes where and how to obtain it. A playlist can be a useful part of an archive, but it cannot preserve remote media that disappears. A project can preserve creative intent, yet remain useless without the footage it edits.^{[42][43][44][36][45]}

Flash deserves its own trapdoor. SWF can contain animation, code, and interactive behaviour, and can refer to external video. FLV is a video container. Recording an SWF’s screen output may preserve one performance of it, but not every interaction, branch, or timing-dependent behaviour. This is preservation of software as well as preservation of pictures.^[46]

Audio before it becomes a codec argument

Digital audio represents a changing signal with samples. The sample rate says how often values are represented; bit depth describes their precision in a given numeric representation; channel count says how many parallel signals are stored. These are different dimensions. “24-bit” says nothing by itself about sample rate, compression, mastering quality, or whether the microphone was under a cushion.

Linear PCM, or LPCM, is the familiar direct sampled representation. Integer PCM uses a fixed range of values. Floating-point audio is useful in processing workflows because its numerical range and precision are distributed differently. A floating-point file cannot undo clipping that already happened in a microphone preamplifier or analogue-to-digital converter.

For band-limited signals, adequate sampling and reconstruction permit recovery of the waveform within the system’s limits. A digital waveform is not condemned to emerge as a staircase. Increasing the sample rate of an existing recording does not discover frequencies that were never captured. Bit-depth reduction requires care; dither can replace correlated quantisation distortion with a controlled noise floor.^[47]

Compression is not loudness control

File compression reduces the bits used to represent audio. Dynamic-range compression changes the relationship between quieter and louder passages. They are different processes with an inconveniently shared noun. A FLAC can contain heavily limited music; an MP3 can retain wide musical dynamics. Loudness normalisation is another operation again, potentially implemented as playback gain metadata rather than rewritten samples.

EBU R 128 specifies a broadcast approach to programme loudness, including a −23 LUFS target. That is not a universal commandment for every streaming service or personal recording. Loudness targets belong to delivery requirements; preservation should keep the original and record any processing used to make a derivative.^[48]

Audio codecs for music and general listening

The table distinguishes coding from its usual packaging. “Lossy” here describes the ordinary use of the named coding scheme, rather than every extension a related standards family has ever acquired.

MP3 and the success of being everywhere

MP3 is one of the rare technical labels that became ordinary vocabulary. Its success also encouraged a persistent mistake: treating every piece of compressed music as “an MP3”. AAC, Vorbis, and Opus have different bitstreams, even when they produce similarly sized files. Changing a file’s icon is not a new coding standard.

Fraunhofer records the termination of its and Technicolor’s particular MP3 licensing programme in 2017. That did not switch off MP3 files, remove copyright from recorded music, or make every piece of MP3 software subject to the same licence. Codec patent licensing, software licensing, and rights in a recording are distinct. We shall return to the lawyers after the engineers have finished making things difficult.^[5]

AAC is a family gathering

AAC is associated with both MPEG-2 and MPEG-4 specifications. Its extensions address different needs, especially efficient delivery at constrained bitrates. A decoder’s support for one member of the family does not establish support for every other member. Similarly, raw or ADTS-framed AAC and AAC inside MP4 are different packaging arrangements around coded audio.^[50][1]

M4A is especially fertile ground for confusion: it commonly contains AAC, but it can contain Apple Lossless. The extension cannot tell you whether information was discarded. The answer is inside the file’s stream description.

Opus and the usefulness of specialisation without confinement

Opus combines techniques for speech and general audio and was specified by the IETF in 2012. Its real-time usefulness does not confine it to calls: it is also used for stored audio. The coding specification and Ogg encapsulation are separate documents, which neatly demonstrates the difference this article keeps labouring.^[52][25]

FLAC and ALAC serve another purpose: keeping samples exactly while saving space. They are attractive when quality must survive repeated copying and later conversion. Lossless files can still have broken tags, missing artwork, mistaken channel labels, or an incorrect source. The mathematics only promises what the mathematics actually covers.

Speech, surround sound, and audio’s archaeological drawer

Music files get most of the attention. Telephone recordings, voicemail, dictation, games, and old streaming services leave a rather different sediment. A codec optimised for intelligible speech over a narrow channel is not necessarily a sensible choice for an orchestra. Conversely, a large music file is a rather elaborate way to transmit “your call is important to us”.

Surround sound has several layers of its own

Dolby Digital (AC-3) and Dolby Digital Plus (E-AC-3) are lossy delivery codecs. Dolby TrueHD is lossless; DTS also has a family of formats, including the lossless DTS-HD Master Audio. The badge on the amplifier does not identify every detail of the stream being delivered to it.^[63][64][65]

Dolby Atmos adds another opportunity for glorious confusion: it is an immersive audio system, not a promise that the underlying delivery is lossless. Atmos can be carried using different technologies, including lossy Dolby Digital Plus and lossless Dolby TrueHD. A player, operating system, television, connection, and receiver may all participate in deciding what actually reaches the speakers.^[66]

MIDI and tracker modules: instructions with musical consequences

A Standard MIDI File is principally a timed set of musical instructions, not a recording of the resulting sound. Different synthesisers or sound libraries can produce different performances of the same instructions. Saving the MIDI preserves editability; recording its output preserves a particular rendition. Sometimes one wants both.^[44]

Tracker modules, such as MOD, XM, S3M, and IT, commonly combine patterns with sampled instruments. Their playback semantics and effects matter, and implementations can differ. Treat them as structured musical works, rather than assuming that every file which makes a noise is a conventional stream of recorded sound.^[67]

Bluetooth brings yet another codec negotiation to the party. The codec used between a phone and headphones is a transmission choice, not necessarily the encoding in the music file. LE Audio’s LC3 is an example of a codec designed for that link. A FLAC file does not prove an uninterrupted lossless path to wireless headphones.^[68]

Video fundamentals: more than a procession of photographs

A video decoder reconstructs pictures, but pictures alone do not tell it when to display them, how wide they should look, or what their numbers mean as colours. Those details are often where a superficially successful conversion becomes a quiet disaster.

Resolution, shape, and time

Older television-derived material deserves particular care. A conventional 25-frame-per-second interlaced system represents 50 fields per second, with successive fields normally captured at different instants. Descriptions such as “50i” and “25i” are used inconsistently across products; ask whether the number counts fields or frames. Deinterlacing can produce a more convenient viewing copy, but it is a transformation, and different methods preserve different amounts of temporal and spatial information.^[69]

Colour: the numbers need a dictionary

Bit depth controls the available numerical precision. Colour primaries, transfer characteristics, and matrix coefficients help define how those numbers relate to visible colour. Full-range and limited-range coding use their available numerical range differently. Misinterpreting these properties can produce washed-out blacks, crushed shadows, or peculiar colours even when the file decodes without complaint.

HDR adds further requirements. PQ and HLG are different transfer systems covered by the ITU’s HDR television recommendations. Ten-bit video is not automatically HDR; an HDR label is not proof that the display path is handling it properly. Converting HDR to SDR normally involves tone mapping, not merely removing the HDR labels.^[70]

An alpha channel describes transparency. Many everyday delivery combinations do not carry it, even when an editing application’s source does. Converting a transparent animation into a normal H.264 viewing file will not preserve editable transparency simply because the resulting pictures look fine against one chosen background.

Video codecs for delivery: a crowded family photograph

Video compression commonly exploits both similarities within a picture and similarities between pictures. An intraframe codec codes pictures independently; an interframe codec can refer to other pictures. The latter often saves space, but random access and recovery after damage can become more involved. These are tendencies of coding structures, not a ranking of moral virtue.

Profiles, levels, and the device which says “no”

A profile identifies a set of coding capabilities; a level constrains matters such as picture size, processing rate, and buffering. “Supports H.264” is therefore an incomplete compatibility statement. A television may accept one ordinary eight-bit H.264 file and reject another using a profile, chroma format, or level outside its decoder’s capabilities.

The encoder is also part of the story. x264 encodes H.264; x265 encodes HEVC. They are implementations, not competing container formats. Two encoders targeting the same codec can produce markedly different quality at the same bitrate, and one encoder’s speed settings can change that trade-off. A codec name alone is not a quality measurement.^[27][3][15]

Editing, acquisition, and preservation codecs

Delivery codecs aim to move acceptable pictures efficiently. Editing codecs may trade larger files for easier seeking and repeated processing. Preservation choices emphasise reproducibility, documentation, and avoidance of further loss. The categories overlap, but their priorities differ.

Nor does a preservation transcode recreate a camera original. Camera raw formats can retain sensor-related information and processing choices which a rendered RGB or Y′CbCr video does not. Preserve the source package, documentation, and an accessible rendition when those original choices matter.

There is no universally correct archival master for every collection. A native DV capture, an original phone file, a carefully documented FFV1 derivative, and a professional tape digitisation have different starting points. Institutional recommendations are useful evidence, but a preferred deposit format is not an instruction to discard everything in another format.^[78][79][80]

The haunted cupboard: video from about 1990 to 2010

This is the part of the cabinet where old home videos, conference demonstrations, CD-ROM encyclopædiæ, and early web clips start rattling their chains. Many are recoverable with current software. Some need an old dependency, a missing companion file, or careful handling of a damaged container. An extension is an opening clue, not the solution.

Old interactive titles pose an additional problem. Recovering an embedded movie from a CD-ROM application preserves that movie, but not necessarily its menus, timing, branching, or relationship to other material. The object worth preserving may be the whole disc image or application package as well as the extracted media. This is where file conversion stops being the whole answer.

A notable example was the 2001 Special Edition DVD of Monty Python and the Holy Grail, whose menus contained elaborate animated sequences and jokes quite separate from the film itself.^[100]

Subtitles, captions, metadata, and the things conversion forgets

A film is not necessarily complete because its pictures move and its loudest soundtrack makes a noise. Languages, captions, audio description, chapters, alternative edits, and accessibility features can all be part of the object.

A subtitle file beside a movie can be as important as a track inside it. Keep associated files together, including language variants and any explanatory notes. A font attachment is not decorative clutter if the subtitles rely on its glyphs.

Metadata is evidence with varying reliability. A file-system modification time may record a copy operation, and a container’s creation field may reflect export rather than filming. Preserve the original values and record what you actually know instead of promoting a convenient date into a historical fact.

Streaming: the film may be in several hundred pieces

Progressive download can deliver a single ordinary media file over HTTP. Adaptive streaming commonly gives a player a manifest or playlist describing media segments and alternative representations. The player chooses among them as conditions change. Consequently, what appears on screen as “one video” may involve many files, several quality levels, separate audio, and changing URLs.

Saving an .m3u8 or .mpd file may save only directions to the pieces. Segments can expire, require authentication, or depend on keys and services. Even when the bytes remain, the ability to play them may depend on something outside the saved folder.

Copyrights, patents, licences, and the bill arriving separately

Several different rights questions get bundled into the innocent phrase “free format”. Separating them prevents both exaggerated fear and heroic overconfidence.

AOMedia publishes a royalty-free patent licence framework for its codecs. Third parties have nevertheless asserted patent licensing programmes concerning AV1. The existence of an assertion does not by itself establish its validity or application to a particular product; equally, “royalty-free” should not be paraphrased as “nobody anywhere could ever make a claim”. Commercial deployment calls for an assessment of the actual implementation and intended use.^[91][92]

MP3 provides a different historical trap. Fraunhofer announced the end of its MP3 licensing programme in 2017. That statement concerns a particular programme; it does not abolish copyright in recordings, dictate every software licence, or constitute worldwide legal advice about every possible use.^[5]

A UK note, with the date left attached

UK law has specific copyright exceptions, with conditions. Do not assume a blanket entitlement to copy any purchased disc merely because the copy is personal. The private-copying exception introduced in 2014 was quashed in 2015; the official announcement is a historical record, and current government guidance describes the exceptions which remain. Anti-circumvention rules can raise separate issues where technological protection measures are involved. This article describes the distinction, rather than deciding whether a particular act is lawful.^[93][94]

For material you created, public-domain material, appropriately licensed material, or authorised preservation work, establish the applicable permissions and proceed accordingly. The preservation problem and the rights question are related, but neither is solved by renaming .m4v to .mp4.

“It won’t play”: a practical diagnosis table

Start with the actual failure. “Unsupported file” is a user-interface summary, not a forensic report.

A rescue workflow for irreplaceable recordings

When a recording is irreplaceable, the first objective is not to improve it. It is to avoid making the situation worse.

Step 1: keep the evidence

Work on a copy and retain the original filename and folder structure. Include sidecar files, playlists, project files, card folders, and any notes explaining where the material came from. If the only copy is on failing storage, securing a readable copy takes priority over experimenting with conversion. A successful transcode is not a reason to delete the source.

Step 2: inspect before prescribing

Use MediaInfo’s detailed view or FFprobe to record the container, each stream, duration, dimensions, frame rate, sample rate, channels, language tags, and colour information. Save the report beside the original. These tools interpret what they can parse; a report can be incomplete or misleading when headers are damaged.^[45][95]

Try a reputable current player, and test with software decoding if a hardware path is troublesome. A file which plays in VLC may still fail elsewhere because VLC supplies support that the other application or operating system lacks. Playing successfully is valuable evidence, but not yet a complete preservation check.

Step 3: choose the smallest useful intervention

If the streams are already suitable and only the wrapper is inconvenient, consider remuxing. This copies compressed streams into another supported container without decoding and re-encoding them. It can preserve their encoded quality, but it can still alter or omit metadata, timing details, or unsupported stream types. If the codec is the obstacle, transcoding may be necessary.^[7]

If a source is damaged, recovery may require reconstructing an index or finding missing pieces. Moving a file into a new container cannot conjure absent picture data. When a recording was interrupted before essential headers were written, repair may need additional knowledge of the recording device and its settings.^[40]

Step 4: make a viewing copy

For an ordinary SDR home-video viewing copy, H.264 video and AAC audio in MP4 are a practical starting point, subject to the intended device’s capabilities. They are not a universal archival prescription. HDR, transparency, unusual audio, multiple tracks, and professional source formats require a more deliberate choice.

In VLC’s desktop conversion interface, add the source, choose a conversion profile, set a new destination filename, and start the conversion. Menu wording differs by platform and version: on many Windows and Linux builds the route begins with Media → Convert / Save; macOS uses a Convert / Stream interface. Examine the profile settings instead of assuming that a friendly label preserves every property.^[96][97]

Step 5: check more than the opening scene

Compare duration and stream inventories. Play sections near the beginning, middle, and end, and include difficult motion or dark scenes where relevant. Check lip-sync, image shape, orientation, colours, subtitles, and every required audio track. For important collections, automated decoding checks and more extensive content review may be justified; a few spot checks reduce risk but do not prove that every frame survived.

If you made a lossless preservation derivative, verify that the intended decoded samples and properties were preserved using a comparison appropriate to the media. A checksum of the whole new file will normally differ from the original because the packaging has changed. A checksum is excellent at answering “are these bytes still the same?” It is answering a different question from “are these two containers presenting the same film?”^[98]

Step 6: keep the recipe with the result

Record the source name, tool and version, settings, date, output name, and known changes. Keep technical reports and checksums. Store copies independently, check them periodically, and test recovery. For these purposes, a concise text file that will still make sense in ten years is a remarkable piece of technology.^[80][98]

Worked Example: one family video, two decades of formats

Nostalgia is no substitute for a codec identifier, however confident its moustache.

Often the easiest way to understand the distinction between a container and a codec is to look at a real file.

This example is a short family video from around 2003, showing one of my children singing for his grandmother. It was recorded on a very early digital stills camera which also supported low-resolution video. The original survives as an .mpg file. By 2020 this, and other files, were becoming awkward to play reliably, so I used VLC to convert them into .mp4 files.

Here we look at the detail around just one file. The conversion worked. More strikingly, a 12.2 MiB file became just 2.95 MiB, while retaining the same picture dimensions, frame rate, and running time.

The original: very much a product of its time

The original file is an MPEG Program Stream containing two separate streams:

• MPEG-1 video; and
• MPEG-1 Layer II audio, usually called MP2.

Its parameters are particularly revealing. The video is 352 × 288 pixels at 25 frames per second and 1,150 kb/s, while the audio is 44.1 kHz MP2 at 224 kb/s.

Those are essentially the classic specifications associated with PAL Video CD. This is therefore not merely an arbitrary old MPEG file: its structure and encoding are characteristic of a very particular early period in consumer digital video.^[105]

The .mpg suffix tells us surprisingly little by itself. What actually matters is that the file is an MPEG Program Stream container, within which the video happens to be MPEG-1 Video and the audio happens to be MPEG-1 Layer II.

In simplified form:

file.mpg
│
└── MPEG Program Stream container
    ├── MPEG-1 Video
    │   ├── 352 × 288
    │   ├── 25 fps
    │   └── 1,150 kb/s
    │
    └── MPEG-1 Layer II audio
        ├── 44.1 kHz
        ├── stereo
        └── 224 kb/s

That distinction becomes important when we examine the converted file.

MediaInfo identifies TMPGEnc 2.521.58.169 as the writing library. Since this is the file originally downloaded from the camera, that metadata appears to reflect part of the camera or its associated recording/transfer process, rather than a later conversion performed by me.

The conversion: the container and video codec both changed

The newer file has an .mp4 suffix and uses an MP4 container.

Inside it, VLC encoded the video using H.264, also known as AVC, one of the enormously more efficient video compression standards that followed MPEG-1.

Yet the audio was not replaced with AAC, Opus, or another newer codec. It remained MPEG-1 Layer II audio.

So the resulting file looks like this:

file-conv.mp4
│
└── MP4 container
    ├── H.264 / AVC video
    │   ├── 352 × 288
    │   ├── 25 fps
    │   └── 203 kb/s
    │
    └── MPEG-1 Layer II audio
        ├── 44.1 kHz
        ├── stereo
        └── 128 kb/s

This is a useful antidote to the idea that .mp4 means “an MP4 video codec”.

It does not.

MP4 is the container.

In this particular MP4 file the video is H.264, while the audio is MP2, a codec dating from the much earlier MPEG-1 generation. Containers are quite happy to hold streams from different technological eras, provided the particular combination is supported.

File extensions therefore give us only the outermost layer of the story.

How did 12.2 MiB become 2.95 MiB?

The original MPEG-1 video used approximately: 1,150 kb/s

The H.264 version uses only: 203 kb/s

That is a reduction of about 82% in the video bitrate.

The audio also fell from: 224 kb/s → 128 kb/s, or about 43%.

Taken together, the encoded audio and video streams fell from roughly: 1,374 kb/s → 331 kb/s

The resulting file shrank from: 12.2 MiB → 2.95 MiB

That is approximately a 76% reduction in file size, meaning that the converted file occupies only about a quarter as much storage as the original.

Or, looked at the other way around, the original is a little over four times larger.

Yet both files contain:

• 352 × 288 pixel pictures;
• 25 pictures every second;
• 4:3 video;
• two audio channels; and
• exactly the same 73 seconds of recording.

Nothing magical happened to the number of pixels; what changed was how efficiently those pixels were represented.

H.264 can exploit spatial and temporal similarities in moving pictures much more effectively than MPEG-1. It therefore needs considerably fewer bits to represent an image sequence of comparable apparent quality.

This is one of the most important distinctions when talking about digital video: Resolution is not file size.

A 352 × 288 video can be enormous or tiny depending upon its codec, bitrate, compression settings, audio, and duration.

Likewise, two files having identical resolution does not mean that they contain identical image quality. Smaller does not necessarily mean better

There is an important qualification.

The 2020 version was made by decoding the already lossy MPEG-1 original, then encoding those decoded pictures again using another lossy codec.

Conceptually:

scene captured by camera → MPEG-1 encoding → original .mpg file → decode → H.264 encoding → 2020 .mp4 copy

The second encoder cannot reconstruct image information that the original MPEG-1 encoding had already discarded.

It may also discard some additional information of its own.

This is called generation loss. Repeated conversion between lossy formats can gradually degrade material even if every individual conversion appears perfectly acceptable when viewed casually.

The striking reduction from 12.2 MiB to 2.95 MiB therefore does not mean that H.264 has somehow compressed the original information losslessly to one quarter of its former size. It means that a much newer compression system can represent the decoded MPEG-1 pictures much more economically.

For viewing purposes, that may be entirely satisfactory.

For preservation purposes, it is a different matter.

Preserve the original

The sensible archival answer is therefore not: “The MP4 is smaller, so delete the MPEG.”

It is: Keep both.

The original MPEG file is the earliest surviving digital artefact. Whatever imperfections it contains, it is the closest surviving representation of the original recording.

The H.264 version is an access copy: convenient, much smaller, and more readily usable with modern software.

Storage is cheap. Childhood is not reproducible.

There is also a broader lesson here for digital preservation. Converting old files into current formats can be extremely useful, and sometimes essential to continued accessibility, but migration should normally supplement the source artefact rather than replace it.

Future software may be better at recovering or interpreting the original than the tools available today. Once that original has been deleted, however, any information discarded during the 2020 conversion has gone with it.

Metadata can tell a different history from the recording

There is one final trap in this example. MediaInfo reports this for the MP4:

Encoded date: 2020-08-13 06:58:52 UTC
Tagged date: 2020-08-13 06:58:52 UTC

Yet the child in the recording was singing for his grandmother approximately 17 years earlier.

Nothing is wrong with the metadata. It is accurately describing the creation of this particular MP4 file.

The problem arises if somebody later assumes that the file creation or encoding date is the date on which the event was recorded.

For migrated digital material we therefore potentially have several different dates:

Date event occurred / Date original recording was digitised / Date this particular file was created / Date this copy was last modified

These dates are not necessarily the same, but are often not individually represented. Those distinctions matter enormously in archives, investigations, family history, digital forensics, and evidential work.

Fortunately, this particular file also records: Writing application: VLC 3.0.11 stream output. That is a useful archaeological clue. It tells a future examiner that this is probably not the original camera file but the output from a later processing operation.

One recording, several “formats”

So what format is this video?

For the original, all of these answers have some justification: .mpg, MPEG, MPEG Program Stream, MPEG-PS, MPEG-1 Video, MPEG-1 Layer II audio, PAL video

For the converted copy: .mp4, MP4, MPEG-4 Base Media, H.264, AVC, MPEG-1 Layer II audio, PAL video

This is why apparently innocent questions such as “What file format is it?” can produce such infuriating answers.

There may be a file extension, a container format, one or more video codecs, one or more audio codecs, profiles and levels within those codecs, metadata formats, subtitle formats, and other streams, all living inside what the user perceives as a single “video file”.

The two files shown here contain the same 73 seconds of family history. Technically, however, they belong to substantially different generations of digital video technology.

And that, in miniature, is why audio and video file formats become such a glorious mess.

SUPER-TECH workbench: FFprobe and FFmpeg

This section is optional. The commands are examples for a current FFmpeg installation, not magic repairs for every specimen. Installed builds differ in enabled encoders and decoders. Quoted filenames make spaces less troublesome. Each output-writing example uses -n to refuse to overwrite an existing destination.^[7][95][27]

Inventory first

The following reports the container and all recognised streams as JSON. Save the terminal output to a text file using your shell’s normal facilities if you want a permanent record – this is recommended.

Look for codec_name, profile, pix_fmt, sample_rate, channel_layout, time_base, and colour-related fields as appropriate. Do not assume a missing field means the corresponding property does not exist; it can mean that the tool did not establish it. Frame-rate fields also need interpretation, particularly for variable-rate or irregularly timestamped material.

Remux compatible streams

Here -map 0 requests all streams from the input, and -c copy requests stream copying. The command can fail if Matroska or the installed muxer cannot represent one of them. Investigate that stream rather than silently dropping it. Even a successful remux needs comparison of track inventory, timing, tags, chapters, and playback. This is not a promise of a byte-for-byte copy of the original container.

Make a deliberately limited viewing copy

This example is for ordinary progressive SDR material where a single video track and, if present, the first audio track are sufficient. It intentionally creates lossy eight-bit 4:2:0 H.264 and AAC output; it is unsuitable as a universal master, an HDR conversion, or a way to retain all source tracks.

CRF 18 is an example quality setting, not a guarantee of invisibility or a target file size. The preset trades encoding effort against compression efficiency. The pixel-format choice improves compatibility for this particular purpose while deliberately limiting what is preserved. This command does not resize an oversized video, deinterlace footage, perform HDR tone mapping, or ensure compatibility with every device.^[99][40]

Decode to check for reported errors

This processes recognised audio and video streams without writing a media file and prints errors at the chosen log level. It does not assess whether the actors’ faces are the right colour, whether subtitles were omitted, or whether the content matches the source. An empty error log is useful; it is not omniscience.

Choosing a format for an actual job

The useful question is not “which format is best?” It is “best for which job, source, recipient, and future?” Keep a source or preservation copy separate from a convenient distribution copy where those needs differ.

Preservation is a habit, not an extension

An archive has to survive more than a codec’s retirement. Drives fail, folders get reorganised, cloud accounts disappear, passwords are forgotten, and a helpful person tidies away “duplicate” files which turn out to contain the only surviving subtitles.

Keep originals, derivatives, and documentation recognisably related. A small manifest can list filenames, sizes, checksums, relationships, and provenance. Record whether a file is an original, a remux, a preservation derivative, or a viewing copy. Put known limitations in words: “second audio track omitted”, “deinterlaced viewing copy”, or “final minute missing from source”. These statements are considerably more useful than just a filename like final_FINAL_really_final_version3.mp4.^[98][80]

Checksums help detect changed bytes when compared with a trustworthy earlier record. They do not prove that the original bytes were correct, that the file is authentic, or that the sound is in synchronisation. A backup which has never been restored is a proposition awaiting experimental evidence.

Preserve context too: names, dates, permission information, recording equipment if known, and a description of what is happening. Retain the highest-quality source you actually possess, rather than manufacturing a larger one by upsampling. Revisit access periodically; a file that requires increasingly obscure software is giving notice, politely at first.^[78][79]

A pocket glossary for the next argument

Common claims, translated

Close the cabinet, gently

Containers organise. Codecs represent. Encoders make choices. Players impose limits. Rights holders have opinions. Storage fails. None of these facts is particularly surprising on its own; the entertainment begins when all six are concealed behind one three-letter extension.

For everyday use, a small number of well-supported combinations will do most jobs. For old collections, curiosity and restraint work better than conversion by reflex: identify the specimen, retain the source, choose a purpose for each derivative, and verify what emerged.

And if the file dates from 1999, plays only in one surviving application, and is currently on the only disk which has not yet died, the correct time to deal with it is approximately yesterday. Yesterday’s opportunity cannot be allocated by committee, but today’s can still be used.

References and further reading

Reference numbers appear immediately after the relevant text. Primary standards and official documentation are used wherever available; contemporary reporting is retained for the institutional controversies that standards documents do not record themselves.

Sources checked for this article on 25/26 September 2026. Each source title is a clickable web link. Standards describe permitted behaviour, while product documentation describes particular implementations. Historical documents are retained for historical claims. Support, licensing programmes, and deployment can change.

[1] IETF / RFC Editor. RFC 6381: The ‘Codecs’ and ‘Profiles’ Parameters for ‘Bucket’ Media Types. 2011.

[2] Library of Congress. MPEG-4 File Format, Version 2. format description.

[3] ITU-T. Recommendation H.264: Advanced video coding for generic audiovisual services. standard.

[4] MPEG. Standards catalogue. standards overview.

[5] Fraunhofer IIS. MP3: technology and termination of the licensing programme. programme ended 2017.

[6] Xiph.Org. Vorbis. project documentation.

[7] FFmpeg. FFmpeg command-line documentation. living documentation.

[8] IETF / RFC Editor. RFC 9639: Free Lossless Audio Codec (FLAC). 2024.

[9] IETF / RFC Editor. RFC 9043: FFV1 Video Coding Format Versions 0, 1, and 3. 2021; Informational RFC.

[10] Library of Congress. Audio Interchange File Format (AIFF). format description.

[11] Microsoft. AVI RIFF File Reference. developer documentation.

[12] Library of Congress. AVI with Indeo Video Compression. historical format description.

[13] Library of Congress. QuickTime with Sorenson Video Codec. historical format description.

[14] MPEG. MPEG-1 Part 2: Video. ISO/IEC 11172-2.

[15] ITU-T. Recommendation H.265: High efficiency video coding. standard.

[16] ITU-T. Recommendation H.266: Versatile video coding. standard.

[17] Alliance for Open Media. Alliance for Open Media Releases AV2 Codec. June 2026.

[18] Library of Congress. WAVE Audio File Format. format description.

[19] IETF / RFC Editor. RFC 2361: WAVE and AVI Codec Registries. 1998; historical registry.

[20] European Broadcasting Union. Tech 3285: Specification of the Broadcast Wave Format (BWF). technical specification.

[21] European Broadcasting Union. Tech 3306: RF64 — An extended File Format for Audio. includes supersession note.

[22] Library of Congress. Apple Core Audio Format (CAF). format description.

[23] Apple / macOS Forge. Apple Lossless Audio Codec: ReadMe. reference implementation documentation.

[24] IETF / RFC Editor. RFC 3533: The Ogg Encapsulation Format Version 0. 2003.

[25] IETF / RFC Editor. RFC 7845: Ogg Encapsulation for the Opus Audio Codec. 2016.

[26] Microsoft. ASF File Structure. Media Foundation documentation.

[27] FFmpeg. General Documentation: supported formats and codecs. support depends on build.

[28] Alliance for Open Media. AV1 Codec ISO Media File Format Binding. version 1.2.0.

[29] Apple. QuickTime File Format. developer specification.

[30] Apple. Apple ProRes White Paper. technical white paper.

[31] IETF / RFC Editor. RFC 9559: Matroska Media Container Format Specifications. 2024.

[32] WebM Project. WebM Container Guidelines. container restrictions and mappings.

[33] Mozilla / MDN. Media container formats (file types). developer documentation.

[34] Library of Congress. MPEG-2 Video Encoding Family. format description.

[35] Library of Congress. Flash Video File Format. historical format description.

[36] RealNetworks. RealSystem 5.0 Content Creation Guide. archived original manual.

[37] ETSI / 3GPP. TS 26.244: Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP). version 10.0.0, 2011.

[38] FADGI / SMPTE. RDD 48: MXF Archive and Preservation Format. 2018.

[39] ISO. ISO/IEC 23000-19: Common media application format (CMAF) for segmented media. 2024; public abstract.

[40] FFmpeg. FFmpeg Formats Documentation. muxers and demuxers.

[41] SMPTE. ST 2067: Interoperable Master Format. standards suite overview.

[42] IETF / RFC Editor. RFC 8216: HTTP Live Streaming. 2017.

[43] MPEG. MPEG-DASH: Media presentation description and segment formats. standards archive.

[44] MIDI Association. About MIDI, Part 1: Overview. technical introduction.

[45] MediaArea. MediaInfo. official feature and format documentation.

[46] Library of Congress. Macromedia Flash SWF File Format, Version 7. historical format description.

[47] Xiph.Org. Digital Show & Tell. sampling, reconstruction, and dither demonstration.

[48] European Broadcasting Union. R 128: Loudness normalisation and permitted maximum level of audio signals. broadcast recommendation.

[49] Fraunhofer IIS. AAC-LC. technical overview.

[50] Fraunhofer IIS. HE-AAC: High Efficiency Advanced Audio Coding. technical overview.

[51] Fraunhofer IIS. xHE-AAC. technical overview.

[52] IETF / RFC Editor. RFC 6716: Definition of the Opus Audio Codec. 2012.

[53] WavPack. WavPack documentation. lossless, lossy, and hybrid modes.

[54] Monkey’s Audio. Monkey’s Audio. official project information.

[55] ITU-T. Recommendation G.711: Pulse code modulation (PCM) of voice frequencies. standard.

[56] IETF / RFC Editor. RFC 4867: RTP Payload Format and File Storage Format for AMR and AMR-WB Audio Codecs. 2007.

[57] Xiph.Org. Speex. project status and documentation.

[58] Microsoft. Windows Media Codecs. Media Foundation documentation.

[59] Library of Congress. RealAudio (RA). historical format description.

[60] Sony. Sony History: Chapter 7 — The MiniDisc System. corporate technical history.

[61] Library of Congress. Direct Stream Digital (DSD). format description.

[62] Library of Congress. DSD Interchange File Format (DSDIFF). format description.

[63] Dolby Laboratories. Dolby TrueHD Lossless Audio. technology overview.

[64] Dolby Laboratories. Dolby Digital Plus. technology overview.

[65] DTS. Professional audio solutions. DTS-HD Master Audio information.

[66] Dolby Laboratories. Is Dolby Atmos a lossless format only?. Dolby professional support answer.

[67] OpenMPT. Manual: Module formats. tracker format documentation.

[68] Bluetooth SIG. LE Audio specifications. including the LC3 codec.

[69] FFmpeg. FFmpeg Filters Documentation. video processing and field handling.

[70] ITU-R. Recommendation BT.2100: Image parameter values for high dynamic range television. standard.

[71] WebM Project. Frequently Asked Questions. VP8, VP9, and WebM information.

[72] Alliance for Open Media. AV1 Features. codec overview.

[73] Xiph.Org. Theora. project information.

[74] Alliance for Open Media. AOMedia to Showcase AV2 Ecosystem Developments at IBC 2026. September 2026.

[75] Library of Congress. DV Video Encoding Family. format description.

[76] Avid. Avid DNx naming scheme and data rates. current and historical naming.

[77] JPEG Committee. JPEG 2000 overview. lossy and lossless capabilities.

[78] Library of Congress. Recommended Formats Statement: Audio Works. preservation and acquisition preferences.

[79] Library of Congress. Recommended Formats Statement: Moving Image Works. preservation and acquisition preferences.

[80] Digital Preservation Coalition. Digital Preservation Handbook: Moving pictures and sound. preservation guidance.

[81] Library of Congress. AVI with Cinepak Video Codec. historical format description.

[82] Library of Congress. RealVideo, Version 10. historical format description.

[83] VideoLAN. VLC media player. official project and downloads.

[84] Apple. Download QuickTime 7.7.9 for Windows. includes end-of-support notice.

[85] Microsoft. Codecs FAQ. Windows Media Player support.

[86] W3C. WebVTT: The Web Video Text Tracks Format. specification.

[87] W3C. Timed Text Markup Language 2 (TTML2). specification.

[88] IETF / RFC Editor. RFC 3550: RTP — A Transport Protocol for Real-Time Applications. 2003.

[89] IETF / RFC Editor. RFC 7826: Real-Time Streaming Protocol Version 2.0. 2016.

[90] W3C. Encrypted Media Extensions. 2017 Recommendation.

[91] Alliance for Open Media. Patent License. licensing terms.

[92] Sisvel. Video Coding Platform: AV1. licensor’s description of its programme.

[93] UK Intellectual Property Office. Exceptions to copyright. government guidance.

[94] UK Intellectual Property Office. Quashing of private copying exception. 2015; withdrawn historical notice.

[95] FFmpeg. FFprobe Documentation. stream and container inspection.

[96] VideoLAN. VLC Desktop User Documentation: Tips & Tricks. includes conversion procedure.

[97] VideoLAN. macOS: Rename ‘Convert & Save’ to ‘Convert and Stream’. 2012 source-code change record.

[98] Federal Agencies Digital Guidelines Initiative. Creating and Archiving Born Digital Video, Part IV: Selected Recommendations. 2014.

[99] FFmpeg. FFmpeg Codecs Documentation. encoder and decoder options.

[100] MCMcommunications. Monty Python and the Holy Grail 2001 DVD menus (disc 1 with orphaned extra). YouTube. 3 February 2022.

[101] Adams, Douglas. The Original Hitchhiker’s Guide to the Galaxy Radio Scripts. Pan Macmillan; authorised online extract. Vogon Constructor Fleets passage.

[102] ITU-T. Recommendation H.222.0 | ISO/IEC 13818-1: Information technology; Generic coding of moving pictures and associated audio information: Systems. Program Stream and Transport Stream definitions.

[103] ITU-T. Recommendation H.261: Video codec for audiovisual services at p × 64 kbit/s. 1993; standard.

[104] ITU-T. Recommendation H.263: Video coding for low bit rate communication. 2005; standard.

[105] The New International CD-i Association. VCD Specs/Trivia: Video CD 2.0. Historical technical summary of Video CD parameters.

[106] TMPGEnc.NET. TMPGEnc Version History. Version 2.521 released 26 September 2003.