Digital Archiving of Video Tapes to FFV1

The most common challenge in digitising moving image is the file sizes that result from the actual digitisation. The file sizes can be huge and with that comes the increased cost of storage and maintenance for long term preservation.

Common consensus consider 10-bit uncompressed to be the preservation standard for moving image because it uses no file compression.

It is considered the most reliable safest format for moving image preservation at the current time. 10-bit uncompressed deliver high image resolution, colour quality and sharpness whilst avoiding motion compensation and compression artefacts.


1 hour of 10-bit uncompressed video can produce a 100gb file. To put it into perspective it would take 21 DVDs to store a video of this size. As you can see, its a lot of data!


(Full name: FFmpeg Video Codec 1)
Contained by‎: ‎AVI‎, ‎MKV‎, ‎MOV‎
Latest release‎: ‎Version 3 (FFV1.3)

FFV1 is a video codec developed within FFmpeg. It is lossless, meaning that it compresses video without introducing quantization degradations. Therefore, FFV1 is a good choice for archiving and preservation. A lossless codec comparison found FFV1 to be the “most balanced”, offering “relatively good speed and high compression”. There are two versions of the codec supported by ffmpeg, version 1 and 3.


FFV1 is a lossless codec which can store its own aspect ratio data which has started to gain in popularity as an alternative to 10-bit uncompressed. FFV1 uses lossless compression (think of a zip drive) to store digitised moving image at reduced file sizes without any data loss.

FFV1 is part of the open-source FFmpeg project which has been around since 2003. FFV1 uses entropy encoding to deliver mathematically lossless intra-frame compression. As a result this produces substantially smaller file sizes when compared to 10-bit uncompressed digitisation.


The testing shows that files encoded to FFV1 produces files around 1/3rd smaller than 10-bit uncompressed. Both formats can be carried in a variety of different wrappers (container files) such as AVI (Microsoft), MOV (Apple) or MKV (open source).

The encoded video and audio streams are wrapped together in the container with other data streams that include technical metadata. The type and variety of data that a container can hold are specific to that container format.


Reduced files produced using FFV1 are exciting but there are some downsides. FFV1 is open source and as such will not play on video software on MAC and Windows, nor can FFV1 be utilised within commercially available digitisation hardware and software. It can only be converted using ‘terminal command’. This is because currently Apple, Microsoft, Adobe and Black-magic has not adopted the codec or announced plans to do so.

Any file format that does not eventually achieve widespread adoption and universal playback within the broadcasting and film-making communities has a higher risk of long term obsolescence and lack of engineering support.

I should also mention that FFV1 version 3 is nearing release. It is now available in ffmpeg under experimental status as testing completes. The version 3 adds multithreaded encoding, which should speed up encoding by about 2.5 times. For long term digital preservation FFV1 version 3 also incorporates mandated checksums per frame. Thus if any digital damage occurs to the file in storage or transmission, an ffv1 decoder should be able to identify which frames were affected, which makes the preservationist’s response much more specific than if only enabled with a whole file checksum.

Generally I’d recommend that an uncompressed codec may be the safer choice for an archive with limited digital preservation infrastructure since the technology dependencies, consequences of digital damage, and requirements for access may be less severe than with lossless codecs.

Oxford Duplication Centre

Digitisation specialists within audio, video, film, image and text.

Leave a Comment