
Often however, it's also possible to store any arbitary binary data in another stream within the container. Indexing - to facilitate seeking, a suprisingly complex topic!.Metadata - e.g: Chapter, Scene, Artist / Track name, etc.One or more video streams - e.g: points of view.Multiple audio streams - e.g: languages, audio described, commentary, channels (stereo vs surround), etc.There are a load of different containers which have different features and benefits. One could argue that the " multiplexer" is the logical block (code) that deals with splitting or merging the streams, while the " container format" is the way the data is prepared and formatted for storage or transmission.Īt a more fundamental electronics level, a multiplexer will simply put one signal on a transmission line at a time. In this context, the term is somewhat synonymous with a " Mux" or " Multiplexer". In order to address these issues, you can multiplex the two (or more) streams into one stream. unless you deal with that carefuly and explicitly (e.g: using time codes) The audio / video sync can easily fail, with one getting ahead of the other.Lose one or the other, and the media is unusable There are two files, which must be handled as one " entity".


It'll produce the same experience for the end user, but there will be a number of issues: One option is indeed to have two separate files on disk, which you play independantly - this is often how Digital Cinema content is distributed. They do not usually come together, but rather exist as separate entities - in your case H.264 and AAC.

As you have identified, a " video" is typically actually both audio and video.
