FFV1 at the Österreichische Mediathek

In 2010 the Austrian Mediathek decided to use FFV1 as an archiving codec for their video digitization. At that time the decision was a rather brave one, since the Austrian Mediathek was at that time one of the very first users of that codec for long term preservation.
With that in mind the decision for FFV1 was not an easy one: intensive research and tests were performed prior to making a decision.

Since 2011 the Austrian Mediathek is digitizing their video stock directly in FFV1.
In the following years several institutions joined the user community of FFV1 as a preservation format.
Especially in the last couple of years there has been a lot of progress in the field of FFV1 thanks to the PREFORMA project and the efforts for the standardization of FFV1 of the CELLAR working group (Codec Encoding for LossLess Archiving and Realtime transmission).

Discussion

Despite the growth of use of FFV1 in the archiving community and increasing reports of positive practical experiences with FFV1, there are still critical voices in the community.
Since the Austrian Mediathek is strongly associated with FFV1, we are often confronted with questions and critique regarding the use of FFV1.

In the following section we collected common critical questions and answer to them. It is the goal of this text to overcome uncertainties and to clarify the arguments that led to the Austrian Mediathek's decision.

FFV1 takes so much storage space. Why not use a lossy codec for archiving? This is often the choice of broadcast archives.

The question of storage space is not specific to FFV1 – it rather questions the principles of digital archiving: lossy or lossless?
Every kind of lossless archiving of video content takes a lot of storage space. If you on the other hand choose to accept losses in picture quality – like it is often the case with broadcast or production archives – the necessary storage space reduces drastically: but parts of the original information are permanently lost.
The top priority of broadcast or production archives often lies on fast access to their digital videos and easy use in their editing workflows. The premise of fast access and optimization for editing purpose is often the reason for using lossy codecs in broadcast/production archives. In archives with no priority on fast access or optimization for editing workflows the principle of preserving media content without additional losses should be applied.

The principle of lossless preservation is especially pursued when unique and cultural precious recordings are solely existent on endangered physical carriers.
An example for endangered media are video recordings on magnetic tape. In that cases digitization offers the only way to save and preserve the recordings for the future. Since the lifespan of analogue video formats is limited due to the limited availability of video recorders and their limited lifespan (in a few years time many recordings on analogue video tape will be forever lost), a digitization process should be performed in the best quality possible. This digitization process will most likely not be able to be repeated in the future.
For that reason "lossless" is the paradigm for preservation of endangered analogue media.

In the area of digital preservation of endangered analogue audio carriers the principle of lossless digital archiving is stated in the IASA's (International Association of Sound and Audiovisual Archives) whitepaper TC-03:

"Data reduction is a powerful tool in the dissemination of audio signals. Its use is, however, counter to the ethical principle of preserving as much of the primary information as possible.
Data reduction does not permit the restoration of the signal to its original acoustic condition and will, in addition, limit the further use of the recording because of the artefacts generated when cascading perceptually coded material – for example, in the making of a new programme incorporating the original sounds."
(Source: IASA-TC 03, 2005:9)

In the area of video archiving there is still a discussion about the ways of preserving digital video content. This is for large parts due to the diversity of video archives, their different objectives and environments. Again, the differences in the main emphasis of broadcast/production archives with their top priority on availability and editing and of archives with a sole preservation purpose must be mentioned.
With this in mind it does not seem realistic that in the near future there will be an agreement in the archive community on the use of one single video codec for archiving purposes.

FFV1 is a codec which only uses procedures of lossless compression of video content. Therein lies one of the biggest advantages of the use of FFV1 since the necessary storage space and the related costs are reduced. Especially for archives which follow the paradigm of lossless preservation and which are bound to keep their storage space as small as possible, the use of FFV1 is a reasonable option.

FFV1 is not known in the field of professional video production. If the codec would be a good choice it would be widely known.

Lossless codecs are not common in video production or private use, since in that areas other criteria are decisive in making a codec choice than in the field of archiving.
The envisaged use case defines the choice of a codec. Since the production of lossless preservation copies is currently not a prevalent use case in production or the private domain, lossless codecs are not common in that areas. When it comes to audio files, working with lossless or uncompressed files has become a standard use case in media archives (including broadcast archives) and even in the private sphere.

Therefore it is not surprising if video production professionals or private persons have never heard of certain lossless codecs like FFV1.

Examples of codecs with lossless compression:

• JPEG2000 lossless
• Dirac (BBC)
• H.264 lossless
• Huffyuv
• Lagarith
• Snow

Why not using uncompressed?

The term "uncompressed video“ describes the storing of video data without a compression scheme. This means that the data is present in its entirety without reduction. That kind of storing data needs the biggest capacity of storage space. Video files that size demand high requirements on the infrastructure (network, replay on workstations,...).
With uncompressed video data the visible effects of data loss are less than in the case of compressed information (bigger parts of the image might be affected than otherwise) and is not affected by the problem of format obsolescence.
The disadvantages of uncompressed video lie in the high amount of necessary storage space, which often is not affordable for archives, as well as the fact that uncompressed methods do usually not offer any error detection mechanisms.

To minimize the risk of data loss it is recommended to store at least 3 copies of a digital item (distributed over different storage pools and different physical carriers). Especially when choosing uncompressed video as preservation format storing so many copies is often not affordable for archives. In contrast, using lossless compression methods the amount of necessary storage space is reduced so that for the same capacity of one uncompressed file two to three lossless compressed copies can be stored.

FFV1 (version 3) does have additional advantages over uncompressed video like multithreading encoding (faster encoding/decoding) and checksums (CRC) for every single frame, so that data loss can be easily identified.

Why does the Austrian Mediathek not use the well known and common codec JPEG2000?

JPEG2000 is a very common video codec in its lossy variant. JPEG2000 lossy is for example used in the Digital Cinema Package (DCP), which is used in cinema distribution and therefore is well known in the field of video production.
JPEG2000 also offers a lossless variant which is used by archives as a preservation codec. One of the best known archives that use JPEG2000 lossless is the U. S. Library of Congress.
The main advantage of JPEG2000 lossless is – comparable to FFV1 – the use of lossless compression methods for video data. For SD (standard definition) video FFV1 and JPEG2000 lossless show similar results regarding compression rates, while FFV1 does need less computing power.
The biggest disadvantage of JPEG2000 lossless lies in incompatibility issues which emerged due to different versions of this format issued by different producers. That incompatibility issues in many cases are a result of the high complexity of JPEG2000 lossless. The used algorithms demand significantly higher processing power than FFV1 which has a negative effect on hardware requirements and the time needed for opening or transcoding to other formats.
Despite the popularity of JPEG2000 in the production industry that format is not widely supported by applications – especially in its lossless variant.

A short excursion into the history of the Austrian Mediathek …

Originally the Austrian Mediathek did plan to choose JPEG2000 lossless as a preservation format. In the following, a series of tests were performed (2010) which finally led to the conclusion that there are problems in the different implementations of JPEG2000 lossless and that there was no way at that time to replay the files on our normal infrastructure without buying special hardware (2010).
For us it did seem too risky to make a preservation decision for a format which we could only replay using special hardware. At the time of the Mediathek's decision making process there only existed one proprietary application to open and transcode JPEG2000 lossless which would have resulted in a full-on vendor dependency of our digital collection.

With that experiences we started to look for alternative codecs that also work with lossless compression methods.
In the course of research we came across FFV1. After intensive tests with FFV1 we came to the conclusion that we could perform our whole archiving workflows with FFV1, without the use of special hardware and without being restricted to proprietary software or hardware.
Already in 2011, there were enough open source tools available to directly digitize in the codec FFV1 on standard hardware (thanks to FFmpeg – see below).
After our initial test led us into a dead end, with FFV1 we found a way to realize our necessary workflows of digitization and transcoding.
At the time of decision making FFV1 was without alternative for the Austrian Mediathek. Up to today we perform all our archiving tasks with FFV1 and do not see the necessity to think about other alternatives of lossless archiving.

Windows Media Player cannot replay FFV1. Therefore the codec seems unsuitable for archiving.

The formats a video player can deal with are dependent on the codec libraries that player uses. Some players use FFmpeg as a codec library. FFmpeg is an open source project, which includes software for transcoding, recording, streaming, remuxing/rewrapping as well as a codec library.
FFV1 was developed as part of the FFmpeg project. This means that every player working with the FFmpeg codec library is able to replay FFV1. Since FFmpeg's codec library is widely used, FFV1 does have in regard of its special use case a wide spread.
Windows Media Player as an example is proprietary software. Which codecs a proprietary software supports is defined by the choices of the respective company. As user of a proprietary player you are bound to the use of codecs which are widespread in the chosen target group of the product. Specialized codecs like FFV1 are usually not considered when a company issues a player meant for the use of private persons.

On a windows system "DirectShow" offers the option of installing additional codecs on the system.

A common player that uses the FFmpeg codec library – and therefore can replay FFV1 – is VLC Media Player. VLC is open source software and is freely available to everyone. VLC is also available on all platforms: Windows, MAC, Linux.

In principle the question of how many players can deal with a special archiving codec is of low relevance to the decision of a preservation format. Whereas it is of high relevance to know if the access to replay the chosen format might in any way be restricted or vulnerable (e. g. patents/licenses, obsolescence of proprietary software). With this in mind the fact that FFV1 is part of the project FFmpeg is an important advantage. Since it is an open source project there are no limitations that could suddenly prevent access and replay options.
Even if the worst case scenario does occur and FFmpeg does end the support of FFV1 one could access the old FFmpeg source codes to transcode the files to a different then better supported format. This is a very decisive advantage of open source codecs in contrast to closed, proprietary codecs where a company might unilateral decide to end the support of their own formats – which might be the case when the company wants to promote their newly developed formats.
Open source implementations of codecs offer an important and necessary reinsurance for long term preservation of media. Having this safety net in place, the question whether a certain company does support a specific codec in its products is negligible. Paramount for a long term perspective is the question of availability of open implementations.

Further reading:
More on the topic “risk assessment” regarding FFV1 as an archiving codec:

• Risk assessment considerations – Using FFV1 for preservation (article by Peter Bubestinger).

FFV1 is not supported in every editing suite.

What codecs an editing software supports depends on the codec libraries it uses. If FFmpeg is used as a codec library FFV1 is directly supported.
Software that supports FFV1 (Wikipedia)
In many open source editing tools FFV1 support is innately included. With some applications one might need to install an additional codec library to work with FFV1 directly. Windows software can often deal with FFV1, when a codec library with "DirectShow" support is installed.
If your editing software does not directly support FFV1 you could also create an intermediate copy in a different format that your software does support. This step is currently necessary for the use of most lossless codecs.
The direct support of FFV1 in editing tools was not a relevant criteria for the Austrian Mediathek's codec decision since editing workflows are not the top priority in our archive.
Nevertheless we perform our editing projects without any additional transcoding directly in FFV1 using the following software:

• VirtualDub

• VirtualDub FFV1

• Avidemux 

• Kdenlive

Examples of editing software with direct FFV1-support:
Shotcut, Openshot, Natron

Do I need to work on the command line in order to be able to work with FFV1 files?

There are enough player and editing tools with graphical user interfaces (GUI) to directly replay and edit FFV1 files. However it is highly recommended in the field of video archiving to work with the software FFmpeg. FFmpeg is an open source project which includes software for transcoding, recording, streaming and remuxing.

There are applications that offer a GUI for FFmpeg, but not always provide the full potential of FFmpeg.

Examples: WinFF, VirtualDub FFV1

Even if FFV1 is not used by your archive FFmpeg is a Swiss Army knife for the work with video. Especially in the field of archiving FFmpeg is the software of choice when needing to perform exact transcoding tasks. To use the full potential of FFmpeg it is recommended to learn the basics of using it on the command line. FFmpeg is available on Windows, Mac and Linux.

Video and film archivists have collected a series of examples and commands to help archivists get started with the use of FFmpeg on the command line.

FFV1 is not standardized and therefore not a suitable option for video archiving.

The standardization of FFV1 is currently work in progress. The CELLAR (Codec Encoding for LossLess Archiving and Realtime transmission) working group pursuits the standardization efforts through the IETF (Internet Engineering Task Force) as part of the PREFORMA project.
Main contributors in the CELLAR working group are, among others, Reto Kromer, Kieran O'Leary (Irish Film Institute, Peter Bubestinger (AV-RD), Dave Rice and Jérôme Martinez, whose company "MediaArea" is known for its widely used and in the archive community highly valued software "MediaInfo".

The Austrian Mediathek decided 2010 for the use of FFV1 as an archiving codec, although it was not standardized at that time. The basis of this decision to not exclude FFV1 as an option for a preservation format was the fact that FFV1 does only exist in its current implementation of FFmpeg. This implementation functions as a reference implementation. Because of its free availability within FFmpeg there is no motivation for companies to develop their own implementation which might lead to incompatibility issues. In addition FFmpeg's source code can be archived with the produced files so that future access is guaranteed.
 
Due to its being embedded in FFmpeg there is no foreseeable risk of the development of other not fully compatible implementations.
Nevertheless the lack of standardizing of FFV1 was one of the most common points of criticism that we encountered. Thanks to the efforts of the CELLAR Working Group that critique will be obsolete in the near future.

In the meantime a new version of FFV1 has been developed. Are there incompatibility issues to be expected?

Since its use in the archiving community two versions of FFV1 were published: FFV1.1 and FFV1.3.
FFV1.3 is an upgraded version of FFV1 with the following improvements: multithreading encoding/decoding, CRC checksums and saving of the display aspect ratio (DAR).
There are no incompatibility problems since FFmpeg – which serves as a reference implementation – does permanently support both versions of FFV1. Even the FFmpeg fork “LibAV” does support both versions of FFV1.
Because of the many improvements of version 3 it is recommended to use that version.

What software can I use to encode or transcode to FFV1?

At the Austrian Mediathek we work with the open source software VirtualDub, Kdenlive, Avidemux und VLC for editing and replay. Usually we use FFmpeg directly on the command line for transcoding. Especially in archiving environments where exact transcoding is necessary FFmpeg is highly recommended.
For beginners this website is a great help: https://amiaopensource.github.io/ffmprovisr/

More tools supporting FFV1:
Shotcut, Openshot, Handbrake, WinFF, MediaCoder

What about performance? It takes so long to encode a file in FFV1.

Working with lossless codecs is always very resource intensive since a lot of information has to be processed. In comparison to other lossless Codecs like JPEG2000 lossless or Dirac FFV1 does show a better performance. That means that actually its good performance (encoding/decoding) and its little demands on the CPU of workstations is one of the strong arguments in favor of FFV1.
Performance tests that compare different lossless codecs show that FFV1 is able to produce the smallest files in the shortest period of time.
 

Who is behind FFV1? Whom do I contact in the case of problems?

FFV1 is a codec that was developed as part of the open source project FFmpeg. FFV1 was developed by Michael Niedermayer in the year 2003. At the moment the CELLAR working group pursues in close cooperation with Niedermayer the standardization of FFV1. As mentioned above the main contributors in the CELLAR working group are, among others, Reto Kromer, Kieran O'Leary (Irish Film Institute), Peter Bubestinger (AV-RD), Dave Rice and Jérôme Martinez.

Since FFV1 is implemented as “Free and Open Source Software”(FOSS), the four freedoms of FOSS apply to it as well: “use, study, share and improve”.

The source code of the FFmpeg implementation of FFV1 is available to the public under a free software license. Therefore every programmer can add further developments to FFV1. After a precise testing and review procedure by FFmpeg developers changes might be adopted or refused. Any problems or faults can be reported and discussed either on the CELLAR mailing list or if necessary directly on the FFmpeg mailing list.

The development of FFV1 version 3 was initiated by Peter Bubestinger and Dave Rice. It was financed by the Austrian Mediathek in cooperation with other institutions and companies. That advancement was made possible through directly contacting Michael Niedermayer.

An example where another independent developer added improvements to FFV1 was the addition of color space support of 48bit/16bpc RGB in the year 2016 by Georg Lippitsch. That improvement was initiated and financed by the archivist and film specialist Reto Kromer.
That example shows that independent specialists can be engaged with tasks regarding FFV1 even if the current developers might not be available in the future.

FFV1 does not cost any money. I don't trust products that are for free ...

It is often the case that people are skeptical towards open source software because of its "being for free". The fear behind that skepticism is that there must be something shady about it if it is offered for free.

The easiest way to meet that skepticism is to test an open source product yourself and see if it keeps its promises. One of the great advantages of open source products is that they do offer the possibility to test them without prior financial investment.

Furthermore – and that is the main advantage (as the name “open source” indicates) – the source code of the product is available under a “Free Open Source Software” (FOSS) license. That means that if necessary that software can be evaluated by independent experts.
With closed, proprietary software tests are only possible after you already bought the product and limited to so called “black box testing”. The source code of that kind of software is usually secret and therefore can neither be evaluated, corrected nor improved.

The free availability of open source products is often at the expense of the developers and is a result of their personal commitment and an often little noticed favor to the user group. Unfortunately in many cases the actual advantages of open source is overseen because of being overshadowed by its “being for free”. The actual big advantage of open source is the possibility and permission to not only use the technology but also to understand, share and improve it (= the 4 freedoms of FOSS). Under that circumstances institutions are able to cooperate with programmers, to finance advances and to fix faults that might exist. With that possibilities in mind open source products are not necessarily without cost. They allow you to take part, to shape it to your needs and to make a contribution for improvement. While an investment in a proprietary product usually solely consists of acquisition costs, an investment in an open source product can be made to initiate adaptations and improvements from which the whole user community can profit.

FFV1's further development of version 3 is an example of how institutions and archivists can collaborate with developers to add improvements to open source products.

What about the patent situation of FFV1?

In the scope of the PREFORMA Project that question was investigated among others by scientific staff of the University of Skövde, Sweden. The result of the research was that there are no known patent claims to the technology used in FFV1. If, contrary to expectations, someone comes forward with a patent claim in the future the access to FFV1 is not endangered. This is due to the fact that software patents are only in effect in a few countries and that the source code of the FFmpeg implementation is freely available. Against that background it does not seem possible that FFV1 support in total can be stopped because of legal intervention. Even if that becomes a reality there will be enough time and possibilities to convert the files to a different format.