The archivist's video codec/container FAQ h p://download.das-werksta .com/pb/mthk/info/video/FAQ-digital_vi...
The archivist's video codec and container FAQ
Back to all ar cles
Started: September 4th, 2013 Last update: September 23rd, 2016 Wri en by Peter B., Hermann Lewetz and Marion Jaks
Disclaimer
The topic of digital video formats is huge, technical and complex – and the decision of which one to choose is o en linked to given precondi ons differing from ins tu on to ins tu on. Choosing a container and codec for preserving video in digital form has a number of implica ons. Therefore, this choice should be made wisely.
Since we have started developing methods for video digi za on in 2009, we con nuously spend a lot of me evalua ng 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 evalua ons, comparisons and tests wherever possible. Please ques on our statements! We welcome feedback, comments and discussions about this subject, because we believe in exchange of informa on and experiences, rather than blindly following someone else's sugges ons.
We would like to thank Ian Henderson, from the Na onal Archives U.K., who uninten onally inspired us to finally start wri ng this down, by e-mailing us a long list of ques ons about this topic.
This ar cle represents our personal experience at the Austrian Mediathek. Topics:
Pros and cons regarding video formats for archiving Audio/video codecs the Mediathek uses Video container the Mediathek uses? FFV1 as video codec Handling born-digital video Video file size (large files/segments) Codec error resilience JPEG2000/MXF Container: MKV/MOV/MXF Archiving DVDs Performance of image sequence as format (e.g. DPX/TIFF)
1 of 7 10/1/2018, 12:06 PM The archivist's video codec/container FAQ h p://download.das-werksta .com/pb/mthk/info/video/FAQ-digital_vi...
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 resolu on 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 applica on that has to do with video can handle AVI files. Ranging from Free So ware (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 preserva on: 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 prac ce, we've had almost no interoperability issues with using AVI across different tools from different vendors. Even across different opera ng system pla orms.
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
2 of 7 10/1/2018, 12:06 PM The archivist's video codec/container FAQ h p://download.das-werksta .com/pb/mthk/info/video/FAQ-digital_vi...
something that works and is safe for long-term preserva on.
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 prac ce it doesn't ma er, because FFV1 was released as Free So ware (some call it "Open Source") from the very beginning.
What does this mean?
Quo ng Jason Garre -Glaser, the lead-developer of "x264" (the most widely used H.264 implementa on) on the ques on 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 ar ficial restric ons that would prevent anyone from transla ng C code to work in any future environment.
No ar ficial restricions:
FFV1 was developed as part of the FFmpeg project, which is Free So ware. Free So ware is defined by 4 freedoms:
You may…
1. …run the program for any purpose (USE). 2. …study how the program works (STUDY). 3. …redistribute copies so you can help others (SHARE). 4. …improve the program, and release your improvements to the public (IMPROVE).
For long-term preserva on, 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, schema cs and all parts required to build it from scratch. Now and under any, yet unknown technical condi ons in the future.
Technically, this is a viable solu on against format obsolescence. Please make up your own opinion about
3 of 7 10/1/2018, 12:06 PM The archivist's video codec/container FAQ h p://download.das-werksta .com/pb/mthk/info/video/FAQ-digital_vi...
this, and evaluate exis ng applica ons or hardware producing standardized formats (like JPEG2000 or MXF) against these above men oned proper es.
For more informa on about how so ware licensing affects archiving instu ons, and its impact on sustainability of digital solu ons 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 preserva on (e.g. DV), we would rather keep this codec and not transfer it into FFV1. Especially if the codec is lossy compressed.
See the ques on 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 informa on in their original form (header info, addi onal 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.
Un l the required storage becomes affordable, only the video files which do not fullfill the requirements for mid-term preserva on (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 considera ons (for the me 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)
FFV1 (Full name: FFmpeg Video Codec 1) H.264 / x264 (Full name: MPEG-4 AVC (Advanced Video Coding)) XviD / DivX (Full name: MPEG-4 ASP (Advanced Simple Profile)) DV (Full name: Digital Video) MPEG-1 / MPEG-2 Classic MPEG-1 or MPEG-2 as used for VCDs or DVDs.
The file is just "re-mul plexed / rewrapped" into a suitable container, without re-encoding of the video bitstream. Therefore, no quality is lost.
4 of 7 10/1/2018, 12:06 PM The archivist's video codec/container FAQ h p://download.das-werksta .com/pb/mthk/info/video/FAQ-digital_vi...
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 ming informa on 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 real me. With the version 3 of FFV1, the encoding and decoding uses mul threading 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 interes ng solu on 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 crea ng files that large, by segmen ng our captured material into segments of 1500 frames (=1 minute PAL) each.
In our everyday prac ce, this has turned out to have more advantages than disadvantages:
An applica on is needed to concatenate the segments. For automa on, we use FFmpeg. For post- processing, it works great with VirtualDub, and any video-edi ng applica on 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 alloca on. 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 sec ons for produc on.
The sor ng order of the video segment files is stored in their filename (zero-padded), so the files appear in correct order when sorted alphabe cally. 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,
5 of 7 10/1/2018, 12:06 PM The archivist's video codec/container FAQ h p://download.das-werksta .com/pb/mthk/info/video/FAQ-digital_vi...
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 o en 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 broadcas ng playout systems.
NOTE: With uncompressed video, one usually has no means of automa cally detec ng pixel errors. Some compressed codecs contain integrity informa on which allows integrity verifica on.
Bit-errors means losing informa on – no ma er how small (or big) the visual impact of that error may be: It must not happen.
Q: Why not JPEG2000/MXF?
To answer this ques on we would like to quote an e-mail we've received from another na onal A/V archive:
"Though ini ally keen I've become a li le cau ous in regards to JP2000/MXF. I think the way MXF has been documented and standardised for use in specific areas of broadcas ng and post-produc on etc is very posi ve but it appears at the moment that real world applica on 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 combina on of JP2/MXF is underrepresented in terms of simple tools to generate, play and validate."
This pre y 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 ra o.
For more details, please take a look at the JPEG2000 (lossless) sec on on our codec comparison page, as well as the test results for speed/size.
Links:
Jim Lindner's comments about JPEG2000/MXF (AMIA-L mailing list).
Q: What about MKV/MOV/MXF as container?
As men oned above, AVI causes the least problems and is s ll the best supported container for video. However, when storing content origina ng 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 Quick me container (MOV). MXF is the least supported with the most compa bility 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 ques on for us.
Unfortunately, vendors of proprietary video-produc on and edi ng products, have not yet picked up Matroska-support as desireable. Transcoding tools and playback hardware on the other hand has widely
6 of 7 10/1/2018, 12:06 PM The archivist's video codec/container FAQ h p://download.das-werksta .com/pb/mthk/info/video/FAQ-digital_vi...
spawned MKV support over the last few years. Numbers increasing.
For more details about these containers, please take a look at the video container sec on 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:
Universal Disc Format (UDF) ISO 9660
For the actual extrac on of data from op cal media, we use "dvdisaster": A tool designed for data-recovery of data stored on op cal 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 wri en sector of an op cal disk. Of course, we also checksum them during the ingest process.
This is also our approach for all op cal 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 iden cal to each other. For each file that is being read, the opera ng system must read certain file-proper es, such as access rights, file-header, etc. Addi onally, depending on the individual implementa on of the tools being used, loading a new file might add addi onal ac ons within the applica on - yet, causing more addi onal me to wait.
Österreichische Mediathek | Design by FreeCSSTemplates.org.
7 of 7 10/1/2018, 12:06 PM