Disclaimer
The topic of digital video formats is huge, technical and complex – and the decision of which
one to choose is often linked to given preconditions differing from institution to institution.
Choosing a container and codec for preserving video in digital form has a
number of implications. Therefore, this choice should be made wisely.
Since we have started developing methods for video digitization in 2009, we continuously spend
a lot of time evaluating and developing methods for responsibly storing our content to the best
of our knowledge.
We'd like to document, share and discuss our findings with others.
It is backed up by arguments and technical evaluations, comparisons and tests wherever possible.
Please question our statements! We welcome feedback, comments and discussions about this
subject, because we believe in exchange of information and experiences, rather than blindly
following someone else's suggestions.
We would like to thank Ian Henderson, from
the National Archives U.K.,
who unintentionally inspired us to finally start writing this down, by e-mailing us a long list
of questions about this topic.
This article represents our personal experience at the Austrian Mediathek.
Topics:
Q: What are the pros and cons regarding these video formats for archiving?
|
container |
video-codec |
audio-codec |
| 1. |
MXF |
JPEG2000 |
PCM (uncompressed) |
| 2. |
MXF |
Uncompressed |
PCM (uncompressed) |
| 3. |
MOV |
ProRes |
PCM (uncompressed) |
| 4. |
MKV |
FFV1 |
PCM (uncompressed) |
| 5. |
AVI |
FFV1 |
PCM (uncompressed) |
This answer is so long, that we've put a detailed comparison of the "usual suspects" on
its own page:
Comparing video codecs and containers for archives
Q: Which audio/video codecs does the Mediathek use?
For captured material, we use FFV1 for video and uncompressed PCM for audio.
Audio resolution depends on the source material, but analogue sources are captured using
48kHz 24bit, as this is
the SDI standard.
"Born digital" material, coming in as a file already, is a whole different story.
Please read up on born digital details, below.
Q: Which container does the Mediathek use?
We use AVI (Audio Video Interleaved).
Almost every application that has to do with video can handle AVI files.
Ranging from Free Software (Open Source) to proprietary tools, professional and consumer alike.
It has a quite limited set of features, but this is also a main feature for long-term
preservation: simple = robust.
Also: more features = more possible points of failure.
Some archives argue the case for containers with complex features, but do not acknowledge the
dangers accompanying this decision: the more features a container has, the more possible
points of failure are added to your archive copy.
Keeping this in mind, we made our decision for a simple container.
In practice, we've had almost no interoperability issues with using AVI across different
tools from different vendors.
Even across different operating system platforms.
We currently do not yet know of any other container that is so widely and stably supported.
Q: Would you always recommend FFV1 for capture from analogue?
Yes.
To be more precise: We recommend a lossless codec for capturing
from analogue.
The reason why we use (and recommend) FFV1 is:
The choice of lossless codecs is very small. We need something that works and is safe for
long-term preservation.
In the last few years FFV1 has proven itself to offer that:
- It's currently one of the most easily accessible lossless codecs
- It's incredibly widespread, due to its availability in FFmpeg's libraries out of the box
- It's probably the fastest lossless codec that has compression comparable to
JPEG2000-lossless
With FFV1, we can capture directly in our archiving format.
Without requiring any special hardware.
Thanks to FFmpeg, we can transcode to virtually any format.
We even run automated mass-transcodings, for example to our video content available online.
Q: How sustainable is FFV1? It's not even standardized.
It's not yet standardized. That's true.
In theory, that sounds bad.
In practice it doesn't matter, because FFV1 was released as
Free Software
(some call it "Open Source") from the very beginning.
What does this mean?
Quoting Jason Garrett-Glaser, the lead-developer of
"x264" (the most widely used
H.264 implementation) on
the question of long-term format accessibility of FFV1:
Portable C code is not going to stop working in 20, 40, or 100 years.
Something encoded in a format with open source encoders and decoders
will be available for as long as computers exist as long as it's
packaged with source code. Nobody cares about how "estoteric"
anything is: if a computer can run C code, it can decode anything.
Even if Jason was wrong, there are no artificial restrictions that would prevent
anyone from translating C code to work in any future environment.
No artificial restricions:
FFV1 was developed as part of the FFmpeg project, which is Free Software.
Free Software is defined by 4 freedoms:
You may…
- …run the program for any purpose (USE).
- …study how the program works (STUDY).
- …redistribute copies so you can help others (SHARE).
- …improve the program, and release your improvements to the public (IMPROVE).
For long-term preservation, this means that we can even
archive the source code of the encoding/decoding tool that was used to create all FFV1 files
ever in existence. Literally.
Compared to analogue video, this is the equivalent of archiving our recorder and replayer
along with our content – and even more:
Archiving the blueprints, schematics and all parts required to build it from scratch.
Now and under any, yet unknown technical conditions in the future.
Technically, this is a viable solution against format obsolescence.
Please make up your own opinion about this, and evaluate existing applications or hardware
producing standardized formats (like JPEG2000 or MXF) against these above mentioned properties.
For more information about how software licensing affects archiving instutions, and its impact
on sustainability of digital solutions and formats, there is a
video of a talk about this subject, given at the EuropeanaTech conference in 2011.
Q: Would you always recommend FFV1 for capture from digital video?
It depends.
When the original stream can be retrieved from tape and the codec fullfills our
requirements for mid-term preservation (e.g. DV), we would rather keep this codec and not
transfer it into FFV1.
Especially if the codec is lossy compressed.
See
the question about born digital files for more
details about how we handle born digital material.
Q: Would you always transfer born digital files into your archive format (FFV1)?
As most born digital files are lossy compressed and some of it store extra information
in their original form (header info, additional data files or folder structure, etc),
we always keep the original source files, as well using BagIt
for preserving the original file/folder structure. We also
checksum
the original files.
Until the required storage becomes affordable, only the video files which do not fullfill the
requirements for mid-term preservation (i.e. the codec is proprietary, or owned by one vendor, etc)
will be transferred to FFV1 – as a copy of the original file.
So, mainly due to size considerations (for the time being), our current approach is to
have a "whitelist" system.
Codecs on the whitelist will be kept in their original format and not transcoded.
Currently, our whitelist contains the following video codecs:
(Audio is always transcoded to uncompressed PCM)
The file is just "re-multiplexed / rewrapped"
into a suitable container, without re-encoding of the video bitstream. Therefore, no quality is lost.
This procedure of rewrapping has also proven to be good to detect container/wrapper issues
as early as possible in the ingest process: For example, if rewrapping causes the audio/video to go
asynchronous, it might indicate that the timing information in the source was not 100% clean.
Every other video codec will be transcoded to FFV1, preserving as much as possible
(bit-depth, pixel-format, colorspace, ...)
Q: Is it possible to capture HD in FFV1?
The actual version 1 of FFV1 is running fast enough to encode and decode SD material in
realtime.
With the version 3 of FFV1, the encoding and decoding uses multithreading and therefore
can be done faster.
Tests have shown that with FFV1 version 3 it should be possible to capture even
full HD (1920x1080) on reasonable PC hardware (Quad-Core @3.4GHz).
This might be an interesting solution for capturing HDCAM.
Q: Video files are huge! How do you deal with several-gigabytes per file?
We don't.
If we can, we avoid creating files that large, by segmenting our captured material
into segments of 1500 frames (=1 minute PAL) each.
In our everyday practice, this has turned out to have more advantages
than disadvantages:
- An application is needed to concatenate the segments. For automation, we
use FFmpeg. For post-processing, it works
great with VirtualDub, and any video-editing
application is by design built to handle video segments, anyway
- When ordering a video from the archive, only the minimimum amount of data
must be transferred, regardless of the underlying architecture (disk, tape, HSM, etc),
because no file-parsing-and-seeking is necessary to order minute-exact.
- Having a file header in every segment file, makes those files more robust and less
vulnerable to bit-errors in comparison to a single large file.
- No problem with > 2GB file allocation.
- Having one file checksum for every segment of the archive video copy,
enables archives to perform integrity checks more granular.
- Less network load when copying video sections for production.
The sorting order of the video segment files is stored in their filename (zero-padded),
so the files appear in correct order when sorted alphabetically.
This is the way we're working for years now, without problems.
The segment index number is also stored in each file's header, so it could be restored
from there – if needed.
Q: I've heard/seen that bit-errors are almost invisible in Uncompressed/J2K/etc. What about FFV1?
Compressed formats always have subsequent bytes in their bitstream dependent on each other.
Therefore, with compressed bitstreams you will always have some kind of cascade effect in
case of errors.
How robust a certain bitstream is against bit-errors, is often pointed out as very
important for the choice of a video codec. These error-concealment techniques are
very important for live-streaming video. For example, in broadcasting playout systems.
NOTE: With uncompressed video, one usually has no means of automatically detecting pixel
errors. Some compressed codecs contain integrity information which allows integrity verification.
Bit-errors means losing information –
no matter how small (or big) the visual impact of that error may be: It must not happen.
Q: Why not JPEG2000/MXF?
To answer this question we would like to quote an e-mail we've received from another
national A/V archive:
"Though initially keen I've become a little cautious in regards to JP2000/MXF.
I think the way MXF has been documented and standardised for use in specific areas of
broadcasting and post-production etc is very positive but it appears at the moment that
real world application seems to be rather random with some bespoke tailoring going on.
JP2000, though its been around for years also there's a lack of robust codec support
and the combination of JP2/MXF is underrepresented in terms of simple tools to generate,
play and validate."
This pretty much sums up the current status of JPEG2000-lossless wrapped in MXF.
Apart from these issues, JPEG2000 is very slow, compared to other codecs that have a
similar compression ratio.
For more details, please take a look at
the JPEG2000 (lossless) section on our codec comparison page, as well as the test results for speed/size.
Links:
Q: What about MKV/MOV/MXF as container?
As mentioned above, AVI causes the least problems and is
still the best supported container for video.
However, when storing content originating from a lossy codec source, preserving the
original video bitstream might not always be possible with AVI.
In the last few years, Matroska (MKV) is being widely used as replacement for AVI use cases.
This makes it already more interoperable, highly documented and well-supported – even
compared to Apple's Quicktime container (MOV).
MXF is the least supported with the most compatibility and accessibility problems.
It also has a very limited set of codecs that it supports at the moment (e.g. no FFV1 yet),
so it is completely out of the question for us.
Unfortunately, vendors of proprietary video-production and editing products, have not yet
picked up Matroska-support as desireable. Transcoding tools and playback hardware on the
other hand has widely spawned MKV support over the last few years. Numbers increasing.
For more details about these containers, please take a look at
the video container section on our comparison page.
Q: How do you archive video DVDs?
Video DVDs are actually data DVDs with a defined, standardized folder/file layout.
This means, that because the bitstream on the disk is actually a filesystem, we can read (and archive) the whole filesystem as-is.
For DVDs, this usually boils down to 2 filesystem formats:
For the actual extraction of data from optical media, we use "dvdisaster":
A tool designed for data-recovery of data stored on optical discs.
We are running dvdisaster on GNU/Linux, because the Windows version does not allow
to read original, pressed disks.
In both cases, the preserved master format is then an
"ISO image" file (.iso),
which represents every written sector of an optical disk. Of course, we also
checksum them during the ingest process.
This is also our approach for all optical discs which contain these filesystems, such as:
- Video DVDs
- Data DVDs
- Data CDs
Q: Performance of image sequences as format?
For digital film it is very common to work with one-file-per-frame image sequences and audiofiles.
The formats of choice are usually DPX or TIFF for the images and linear WAV for audio.
There's no video container or streams involved. This way of storing moving images has it's pros and cons.
At the Mediathek, we've ran performance tests regarding uncompressed image sequences (e.g. DPX) compared to uncompressed video in AVI.
We transcoded both sources to the same output format.
The image sequence as source performed tremendously slower than the videofile.
The reason for this performance difference is not data size or bandwidth, because these are almost identical to each other.
For each file that is being read, the operating system must read certain file-properties, such as access rights, file-header, etc.
Additionally, depending on the individual implementation of the tools being used, loading a new file might add additional actions
within the application - yet, causing more additional time to wait.