Containers and Codecs
A container organizes media streams, while codecs define how their picture and sound data are encoded.
A file ending in MP4 may carry H.264 video with AAC sound. Another MP4 may carry HEVC with different audio. To understand the difference, follow the data through the player rather than treating the file as one indivisible format.
| Stage | What enters | What comes out |
|---|---|---|
| Container reader, or demuxer | Bytes from the MP4 | Encoded packets belonging to separate tracks |
| Video decoder | Encoded video and its configuration | Reconstructed pictures |
| Audio decoder | Encoded audio and its configuration | Sound samples |
| Playback scheduling | Pictures, samples, and timestamps | Synchronized presentation |
The container defines the package: how tracks are described, how their data is stored, and how their time and location are represented. A codec defines an encoded representation and the corresponding decoding rules. H.264 and AAC do different jobs inside the same package.
Changing the package
Suppose the video already suits the receiving app, but the app expects different packaging. A remux reads the input container and writes a new one. It copies encoded video packets through this route:
input container → demuxer → encoded video → muxer → output container
There is no picture reconstruction in that route. The output file's bytes differ because its headers, indexes, timestamps, or framing differ, while the encoded picture information can be preserved. Codec configuration may have to move from one header convention to another. That is still distinct from decoding and recompressing the pictures.
The destination must have a defined way to store the chosen tracks. An audio track may fit while a subtitle format does not, so preserving the movie's picture is only one part of preserving its contents.
Changing the representation
If the app needs a different video codec, the route becomes:
encoded video → decoder → pictures → encoder → new encoded video
The encoder makes new coding decisions from reconstructed pictures. This costs processing time and, with lossy settings, introduces another compression generation. Resizing or filtering also acts on these decoded pictures.
An audio-only conversion follows the same idea for sound while allowing video packets to be copied. The result can therefore involve transcoding without re-encoding the picture. That distinction explains why some Emby playback conversions need little video processing and others need substantial decoding, filtering, and encoding.
For a concrete source, write down the selected tracks separately: container, video codec, audio codec, and subtitles. Then compare those with the delivered stream. The question becomes which stage changed, rather than whether the file was broadly called “converted.”