FFV1: Difference between revisions

Latest revision as of 22:45, 11 June 2024

FFV1
Internet media type	video/FFV1
Developed by	Michael Niedermayer IETF
Initial release	9 June 2003; 21 years ago (2003-06-09)
Latest release	Version 3 (FFV1.3) 3 August 2013; 10 years ago (2013-08-03)
Type of format	Video coding format
Contained by	AVI, MKV, MOV, NUT, etc.
Standard	RFC 9043 Version 4 (draft)
Open format?	Yes
Website	Specification development repository

FFV1 (short for FF Video 1^[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 M-JPEG2000.^[2]^[3]^[4]

The encoder and decoder are part of the free, open-source library libavcodec in the project FFmpeg since June 2003.^[5] FFV1 is also included in ffdshow and LAV Filters,^[6] 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.^[7] The European Broadcasting Union (EBU) lists FFV1 under the codec-family index "31" in their combined list of video codec references.^[8]

Video archiving[edit]

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.^[9] The previously proclaimed encodings were Motion JPEG 2000 (lossless)^[10] and uncompressed video.^[11]

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.^[2]^[12] 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.^[13]^[14]

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

Use as a preservation codec[edit]

Within the video archiving domain, the interest in FFV1 is increasing, as can be seen in a thread on the AMIA-L mailing list,^[23] the PrestoCentre Forum^[24] or the Archivematica mailing list.^[25]^[26] Companies are also picking up FFV1 support. For example, NOA (formerly "NOA Audio Solutions"), announced support for the FFV1 in their product line in July 2013^[27] and KEM-Studiotechnik released a film-scanner with FFV1 output in November 2013.^[28]

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

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

List of institutions known to use FFV1[edit]

Development and improvements[edit]

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.^[51] 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.^[52]

Applications supporting FFV1[edit]

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.

Application	Encoding	Decoding	Method
Adobe Premiere	Yes	Yes	DirectShow^[53]^[54]
Archivematica^[55]	Yes	Yes	built-in
AVID	Unknown	Yes	Their transcoder can handle FFV1
Avidemux	Yes	Yes	built-in
Davinci Resolve^[56]	Yes	Yes	built-in
Blender	Yes^[57]	Yes	built-in
DVA-Profession^[58]	Yes	Yes	built-in
ffdshow-tryouts	Yes	Yes	built-in
FFmpeg	Yes	Yes	built-in
HandBrake	Yes	Yes	built-in
Harris Broadcast Velocity	Yes	Yes	Video for Windows^[53]
kdenlive	Yes	Yes	built-in
KEM Scan (motion picture film scanner)^[28]^[59]	Yes	-	built-in
LAV Filters^[54]	Yes	Yes	built-in
MediaInfo	-	Yes	built-in
Media Lovin' Toolkit^[60]	Yes	Yes	built-in
Media Player Classic	-	Yes	built-in
MPlayer/MEncoder	Yes	Yes	built-in
NOA MediaButler^[61]	Yes	Yes	built-in
QUADRIGA Video^[62]	Yes^[63]	Unknown	Unknown
Shotcut^[64]	Yes	Yes	built-in
Sorenson Squeeze	Unknown	Yes	built-in
VirtualDub	Yes	Yes	Video for Windows^[53]
VLC media player	No	Yes	built-in
Windows Media Player	Unknown	Yes	DirectShow^[53]^[54]

Compression details[edit]

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^[65] with later versions of FFV1 (version 2,3), the use of GOP size greater than "1" might disappear in the future.

Prediction process[edit]

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,

Top + Left - TopLeft

, 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.^[66]

Entropy coding process[edit]

The residuals are coded using either Golomb-Rice coding^[67]orrange coding. Both options use a very large context model. The "small" context model uses

(11\times11\times11+1)/2=666

contexts based on the neighboring values of

(Left - TopLeft)

(TopLeft-Top)

, and

(Top - TopRight)

. The "large" context model uses

(11\times11\times5\times5\times5+1)/2=7563

contexts based on the same values as before, but also

(TopTop - Top)

and

(LeftLeft - Left)

, where

TopTop

is the pixel two above the current one vertically, and

LeftLeft

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.^[68]

Status[edit]

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

Versions[edit]

Documentation[edit]

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

Contents