FFV1

FFV1 (short for FF Video 1) is a lossless intra-frame video coding format. FFV1 is particularly popular for its performance regarding speed and size, compared to other lossless preservation codecs, such as Motion JPEG 2000.

The encoder and decoder have been part of the free, open-source library libavcodec in the FFmpeg project since June 2003. FFV1 is also included in ffdshow and LAV Filters, which makes the video codec available to Microsoft Windows applications that support system-wide codecs over Video for Windows (VfW) or DirectShow.

FFV1 has been standardized at the IETF under RFC 9043. The European Broadcasting Union (EBU) lists FFV1 under the codec-family index "31" in their combined list of video codec references.

Video archiving

For long-term preservation of digital video sustainable container formats as well as audio/video codecs are necessary. There is no consensus as of 2013 among the archival community as to which file format or codecs should be used for preservation purposes for digital video. The previously proclaimed encodings were Motion JPEG 2000 and uncompressed video.

FFV1 proved to be a viable archival encoding and the U.S. Library of Congress began regarding it as a suitable option for preservation encoding in 2014. Compared to lossless JPEG 2000, FFV1 features comparable compression ratios and lower computing requirements. As of 2014, it is being used by archives, particularly where the collections do not feature extensive broadcast materials and instead consist of oral history and the like.

Since around 2015, the European PREFORMA Project started working on the standardisation of FFV1 through the Internet Engineering Task Force (IETF). It was standardised in August 2021 as RFC 9043. The PERFORMA Project also implemented a conformance checker for FFV1 in the Matroska container. Details of FFV1's standardization plan have been prepared by MediaArea (authors of MediaInfo) as part of their conformance checking tool Media CONCH.

It is also listed as a format option for long-term preservation of moving images on sites of the Library of Congress and the State Records Authority of New South Wales. The Society of American Archivists published a paper in August 2014, suggesting only FFV1 as preservation codec for video.

The Library of Congress identified AVI and Matroska as common container formats for FFV1.

Use as a preservation codec

Within the video archiving domain, interest in FFV1 is increasing. Companies are also picking up FFV1 support. For example, NOA announced support for the FFV1 in their product line in July 2013 and KEM-Studiotechnik released a film-scanner with FFV1 output in November 2013.

In an interview for ''The New York Times Magazine'', Bertram Lyons from the Library of Congress says:

In January 2013, the possible use and adoption of FFV1 as an archiving codec was addressed in the issue of PrestoCentre's ''AV Insider'' magazine:

PACKED - the "Centre of Expertise in Digital Heritage" in Belgium, say in an article about video formats for archiving:

In 2015, the International Federation of Television Archives (FIAT/IFTA) mentioned FFV1 explicitly in their call-for-presentations for their annual World Conference, asking "Is FFV1 the new JPEG2000"?. A workshop titled "FFV1 for Preservation" is also featured.

List of institutions known to use FFV1

;Austria
* Austrian Museum of Modern Art (MuMoK): For their collection of art videos.
* Danube University Krems (Lower Austria/Niederösterreich)
* Filmarchiv Austria (Austrian Film Archive): For their telecined DigiBeta copies of some films.
* (State Museum of Lower Austria)
* Österreichische Mediathek (Austria's national audio/video archive)
;Australia
* Museum Victoria
;Belgium
* , the Flemish Institute for Archives announced in June 2020 that they would start a major operation transcoding and rewrapping their MXF wrapped JPEG2000 files resulting from digitisation projects for the cultural heritage sector material to MKV wrapped FFV1 files. In 2019 they had already announced that MKV-FFV1 would be the mezzanine format of their migration project for DV, DVCAM and DVCPRO cassettes.
;Canada
* City of Vancouver Archives
* Musée d'art contemporain de Montréal
;France
* Cinémathèque Française
;Germany
* SMIDAK Filmproduktion
;Ireland

Irish Film Institute
;Slovakia
* RTVS Slovakia
;Slovenia
* RTV Slovenija
;Switzerland
* AV Preservation by reto.ch
* HTW Chur

Archives de la Ville de Lausanne

;United Arab Emirates
* Sharjah Media Corporation (SMC).
;United Kingdom
* The National Archives (United Kingdom)

The Media Archive for Central England
* BFI National Archive (the UK's national moving image archive)

The Box, Plymouth

;United States
* American Archive of Public Broadcasting
* Library of Congress
* Smithsonian Institution
* City University of New York Television (CUNY TV)
* Duke University Libraries
* Indiana University
* National Library of Medicine (Washington DC)
* New York Public Library
* University of Georgia, Walter J. Brown Media Archives
* University of Notre Dame Archives
* University of Texas Libraries (FFV1 in MKV for DVD preservation)

Development and improvements

The "Österreichische Mediathek" has also developed DVA-Profession a Free Software solution for archive-suitable mass video digitization, mainly using FFV1 as video encoding throughout the whole workflow, without transcoding. Additionally, they have initiated the development of "FFV1.3" (=version 3 of FFV1) together with Michael Niedermayer (FFmpeg), Peter Bubestinger-Steindl and Dave Rice; see #Versions below.

Applications supporting FFV1

Here is a list of applications known to be able to read and/or write FFV1 video files, either natively or by installing codec packages.

Entries marked with "-" means that they generally only support either encoding ''or'' decoding.

The term ''"built-in"'' means that the application can handle FFV1 without the necessity to install additional codec packages.
Applications that come with FFV1 support out of the box, usually use FFmpeg's or Libav's libraries in order to do so.

The list is far from being complete, and will be augmented over time:

Compression details

FFV1 is not strictly an intra-frame format; despite not using inter-frame prediction, it allows the context model to adapt over multiple frames. This can be useful for compression due to the very large size of the context table, but can be disabled to force the encoder to generate a strictly intra-frame bitstream. As the gained compression seems to decrease with later versions of FFV1 (version 2,3), the use of GOP size greater than "1" might disappear in the future.

Prediction process

During progressive scanning of a frame, the difference between a current pixel and its predicted value, judging by neighboring pixels, is sent to the entropy-coding process. The prediction is done as follows:

:

The third value, , is effectively equivalent to applying the "top" predictor to the current and the left sample, followed by applying the left predictor to the prediction residual of the top predictor. This method, also known as the gradient, exploits both horizontal and vertical redundancy. So in simple terms the prediction is the median of the top, left, and gradient prediction methods. For improved performance and simplicity, the edges of the frame are assumed to be zero to avoid special cases. The prediction in encoding and decoding is managed using a ring buffer.

Entropy coding process

The residuals are coded using either Golomb-Rice coding or range coding. Both options use a very large context model. The "small" context model uses contexts based on the neighboring values of , , and . The "large" context model uses contexts based on the same values as before, but also and , where is the pixel two above the current one vertically, and is the pixel two to the left of the current one. In range coding, each "context" actually has 32 sub-contexts used for various portions of coding each residual, resulting in a grand total of 242,016 contexts for the "large" model.

Early experimental versions of FFV1 used the CABAC Arithmetic coder from H.264, but due to the uncertain patent/royalty situation, as well as its slightly worse performance, CABAC was replaced by range coding.

Status

On April 16, 2006, a commit-message by Michael Niedermayer confirmed that the bitstream of FFV1 (version 1) is frozen:

"ffv1 and ffvhuff haven't changed since a long time and no one proposed any
changes within 1 month after my warning so they are officially no longer
experimental and we will guarantee decodability of files encoded with the current ffv1/ffvhuff in the future"

Versions

; Version 1 (FFV1.1)
:The bitstream of version 1 is frozen and has been considered stable for production use since April 2006.
:The remark "experimental" in the source code was overlooked back then and removed in March 2010.
; Version 2 (FFV1.2)
:Version 2 was an intermediate version that was never officially released and should not be used for production purposes.
; Version 3 (FFV1.3):
:The bitstream of version 3 is frozen since August 3, 2013. The final commit marking this version as officially released for production usage was on August 26, 2013.
:FFV1.3 contains improvements and new features such as support for multi-threaded encoding/decoding, error resilience and integrity validation by CRC checksums, storing of display aspect ratio (DAR) and field order. It was tested for over 1 year, and officially released stable for production in August 2013.
:In August 2016, support for 48bit/16bpc (=bits per component) in RGB was added to the reference codec. Before that, 16bpc in FFV1 were only supported in YCbCr and RGB was limited to 14bpc.
:There is still no VFW multithreaded encoder of FFV1.3 for Windows in 2017. FFdshow can encode only an FFV1.1 stream with a single CPU core.
; Version 4 (FFV1.4)
:Improvements beyond FFV1.3 are works in progress and being discussed on the IETF "" mailing list.
:Planned are additional support for color-handling, especially non-linear/logarithmic color spaces.
:The Draft standard is hosted on GitHub and IETF Datatracker.

Documentation

The current authoritative documentation was started in April 2012, and stayed in a very basic state until 2015.
In 2015, as part of the IETF standardization process, the documentation is now improved and reviewed by the working group in close cooperation with Michael Niedermayer.

See also

*FFmpeg
* List of lossless compression video codecs

References

External links

* FFV1 Video Coding Format Versions 0, 1, and 3 (Published 2021)

FFV1 Video Coding Format Version 4
Expired Internet-Draft on IETF Datatracker, last updated 2024-07-23 (latest revision 2024-01-17)

FFV1 Specification development repository
on GitHub
* Format description o
FFV1
an
Matroska File Format with FFV1 video encoding
from Library of Congress

Codec Encoding for LossLess Archiving and Realtime transmission (CELLAR)
Charter on IETF Datatracker
:The goals of the specification effort are defined within the charter of the cellar working group of IETF.


by Moscow State University Graphics & Media Lab (Video Group)

{{DEFAULTSORT:Ffv1
Free video codecs
Computer-related introductions in 2003