Codec Support in Containers
A valid container and codec combination needs both a defined storage mapping and software that implements it.
A muxer needs more than the encoded bytes of a soundtrack. It needs a codec mapping telling it how to describe those bytes in the chosen container.
A mapping supplies a codec identifier, a place for decoder configuration, boundaries for encoded units, and any timing or initialization rules particular to that codec. The corresponding reader follows the same rules in reverse.
For example, AAC in Matroska has an A_AAC identifier and defined configuration handling. AAC in MP4 has an audio sample entry and its own configuration representation. Copying the sound between them can retain the coded audio while translating those surrounding descriptions.
A proposed output with three tracks
Suppose a source has H.264 video, AAC sound, and a subtitle track. The destination is WebM. First ask whether the destination defines acceptable mappings for the selected components. WebM's video/audio conventions cover a constrained collection, rather than all the mappings available in Matroska. The H.264/AAC pair cannot simply be relabelled as WebM.
At that point there are distinct choices: keep an accommodating container, or convert the encoded components to formats the destination supports. A subtitle that does not fit introduces its own choice to omit, convert, render, or use another package. Those are content and processing decisions, not a failed compression of the movie.
| Check | Evidence that answers it |
|---|---|
| Format mapping exists | The container's specification or registration and applicable carriage rules |
| Writer implements it | The muxer's documented support for this combination |
| Reader implements it | The app or playback framework's container and mapping support |
| Decoder handles the track | The codec, configuration, and resource limits available in that path |
These checks are ordered because each solves a different problem. A registered MP4 code tells developers how a representation is identified; it does not install that representation in an older writer or reader.
Why one conversion can combine copying and encoding
If a different destination accepts the video mapping but needs another audio format, the video branch can be a copy while the audio branch decodes and re-encodes. Emby can similarly choose a delivery route based on the selected combination rather than one global “supported file” label.
A useful before/after record lists the selected components and the treatment of each. It makes an absent commentary track or a changed subtitle visible, even when the main video was copied successfully.