This page probably won't work great in Internet Explorer. We generally only support the recent versions of major browsers like Chrome, Firefox, Safari and Edge.
One minute of video contains thousands of video and audio “frames”, that must be decoded and displayed at the correct time.
If encoded frames were just stored in bulk — without instructions about how to interpret the soup of frames — playing back the video would be impossible.
The container is the layer of information that organizes all the frames to makes them... playable.
What is a container format?
People often confuse the encoding format — H.264/AVC is the most popular video codec — with the container format, identified by the file extension, like .MP4 or .MXF
Imagine the container as a shipping crate. Many goods can be stored in the crate, for example water, rum, or glasses.
Container vs Content
Liquids can obviously not be stored in a crate in bulk, they have to be inside tanks or bottles.
Glasses are very fragile and will need to be padded to resist to crate handling.
Similarly, different containers are best suited for certain types of media and for certain uses.
For example, when recording a AVCHD clip, video is encoded in H.264/AVC and stored into a MTS container.
MTS format is very good for streaming, but no so for editing.
Fortunately, the video can be re-wrapped in a more production-friendly .MOV container:
We change the container, without touching to the encoded data, and quality doesn't degrade.
Containers formats are versatile — they can store many different types of video or audio formats. The bottles of the crate could be orange juice instead of rum, only the crate markings shall be changed!
Therefore, there is a choice of different container formats for a given video format. Conversely different video formats can go inside a given container format.
Some combinations work better for a certain use case, while others are impossible for technical reasons.
Let's see how containers works and their properties...
How do containers work?
Imagine that you start watching a video, get bored, and jump to the middle to see what happens next.
The computer needs to figure out immediately which images should be displayed.
Where can those images be found inside the file?
Raw video and audio data cannot be navigated, but thanks to the container — tables and indexes referencing each frame and their timestamp — the computer knows which images and sound to decode.
Indexes work like the table of contents of a book, which lets the reader find the page he wants to read.
Inside a video file, media data — encoded images and sound — occupies most of the space.
It is “wrapped” by the container object, that gives coherence to the whole:
The container has this complexity because we have several types of data (audio, video) whose properties — frame size, duration, display order — are subject to change over time.
But not all situations require such a complex container. Simple containers also exist, we often refer to them as the “header”...
Headers and Footers
For those simple audio containers, a header is enough, because PCM audio can be described by just a few parameters, like sampling frequency, bit depth and “endianness”.
Those simple containers are the exception, not the rule.
Fixing Broken Containers
Unfortunately this container object, which gives the coherence to the video file, is also the most fragile part of it.
It can be missing, or have lost its tight coupling with the encoded media it references to.
- In failed recordings, indexes are missing (because indexes are written after recording ends)
- In recovered files, indexes are missing or useless (because referencing to wrong positions inside the file)
Our Treasured repair service solves this problem by reindexing the bad file:
We create a new container to wrap the encoded media of the bad file. Video is restored!
Use Treasured to reindex your damaged files!
Our service offers:
- FREE diagnostics and preview with Treasured
- FREE sample of repaired video
- Try before you buy with a FREE trial of your Repair Kit
- Enjoy FREE customer support by speaking directly with our trained experts
- Invaluable expertise, dedication and second to none customer service
Video Repair — online
Mac, Windows, Linux
Apple created the first multimedia container, QuickTime .MOV, in 1991, and it remains dominant after 30 years, in its various incarnations.
A dozen of containers, under the ISO standard, have been derived from MOV over the years:
Despite different file extensions and small differences, those container formats share the same properties:
- Workflow-friendly: QuickTime file format has abstract data references and track edit lists, which makes it suited for editing. Thanks to "Reference movies", MOV can do editing without copying media data, which other container formats can't do.
- Interoperability: MOV can be read and written by a variety of software, including AVID Media Composer, Adobe Premiere, Sony Vegas, GrassValley EDIUS, Da Vinci and Final Cut
- Future-proof: MOV files are codec agnostic, have metadata support, and have unlimited size and duration.
Those containers store the frames in bulk, which adds complexity to a repair.
Reindexing is only possible after correctly identifying all the frames, but bulk storage makes the “parsing” more difficult than in formats like MXF or AVI that have a short header before every frame.
To enable automated repair, usually in-camera, some manufacturers have recently added their own headers before each frame — GoPro is using GP structures — or partial indexes in the middle of the raw data — Canon is adding REPI tables, Apple has MOOF structures.
Besides MOV/MP4 family, the other format used in production is MXF.
MXF files less difficult to repair than their MOV/MP4 counterparts, because each frame is encapsulated inside its own structure, with a small header before it that can easily be detected. The raw data looks like a chocolate tray, rather than a pile of chocolate chips.
MXF format has redundant structures, which makes the recovery of corrupt files possible under almost all circumstances.
However, when the camera records video and audio in separate files, recovery is more complex because the different streams come out interleaved and need to be separated.
MXF is an open standard and can be read and written by a variety of software, including AVID Media Composer, Adobe Premiere, Sony Vegas, GrassValley EDIUS and Final Cut.
MXF has the capability to store timecode and rich metadata, on a per-frame basis. This is crucial for cinema workflows, to perform color grading and do add special effects.
MXF is built on simple but versatile structures — KLV atoms called Essence, Descriptor, Track — that can be combined together. Manufacturers and developers can add their own specific atoms, called “dark KLV triplets” because they are not standardized, to expand the possibilities. MXF format future-proof by design!
Audio containers are simple and easy to fix, with the exception of M4A (part of MOV family, see section above).
AVI (Audio Video Interleaved)
Frames inside an AVI file have a small header, typically '00dc' and '01wc' for audio and video, with the frame length encoded on 32 bits just after. This makes reindexing of AVI files almost trivial if you have basic programming skills.
Transport streams, stored in .MTS and .TS files, are by design unbreakable, so repair is never needed.
Regarding Program streams, stored in VOB and MPG files, the repair method usually consists in findings a GOP marker and truncate the file before it.
Formats like Matroska (MKV), OGG, WMV, ASF or Flash Video (F4V or FLV) are not used in Production. For this reason, while we can repair them, very little development has been done in this direction.