FFV1: a long journey

 

 

 

It did not appear from nowhere

 

Jérôme Martinez

No Time to Wait 10, October 2026

FFV1

Lossless, intra-only video compression format

Open source, patent free

Adopted by many archives

Frames are divided into slices, with checksums

FFV1 compression

Example: 1 second of 10-bit HD film at 24 fps, on a 6-core (12-thread) Skylake-X CPU:

  • 24 DPX files (or an uncompressed ZIP/TAR): 189 MB
  • 1 compressed ZIP file: 175 MB, in 10 seconds
  • 1 LZMA2 file: 154 MB, in 30 seconds
  • 1 FFV1/MKV file with 64 slices: 105 MB, in 0.8 seconds

FFV1 commits per year

15'03 12'04 7'05 9'06 4'07 8'08 16'09 40'10 23'11 114'12 64'13 13'14 52'15 30'16 16'17 14'18 7'19 8'20 17'21 31'22 13'23 71'24 155'25 130'26

hobby / maintenancearchives' requests (v3)PREFORMASovereign Tech Fund, GPU, v4

869 non-merge commits touching FFV1 files in FFmpeg, ~55 authors (Michael Niedermayer: 366, Lynne: 203)

The early beginning (2003)

Michael Niedermayer (FFmpeg) wanted a better lossless compressor

"our very simple lossless intra only codec, compresses much better then huffyuv"

First commit in 2003

Built for his own needs:
8-bit only, no slices, SD content, single-core CPUs

A quiet period (2004-2009)

April 2006: the 8-bit format (version 0) is declared stable

The encoder no longer requires -strict experimental: "we will gurantee decodeability of files encoded with the currenzt ffv1 in the future"

April 2009: version 1, more than 8 bits per component (YUV)

... but still flagged experimental

Only a few commits per year

Österreichische Mediathek / Peter B.

2010: the Österreichische Mediathek wants to digitize its video collection

It needs to reduce storage costs

But without losing content to lossy compression!

Off-the-shelf products exist, but they are expensive black boxes

(MXF/JPEG 2000 files that could not be opened without the vendor's system)

"Experimental"?

2010: Peter B. reads the source code. Its header still says:

FF Video Codec 1 (an experimental lossless codec)

... although the 8-bit format had been stable since 2006

He asks on the FFmpeg mailing list. Michael's answer: he simply forgot to remove the word

22 March 2010: the word "experimental" is removed from the header, and the warning for more than 8 bits is dropped

Why not put this money into open source?

The money that would have bought a product goes to developers instead:

  • DVA-Profession workflow (instead of a SAMMA Solo)
  • FFV1 improvements, paid to Michael Niedermayer directly

Herman Lewetz: "We took our money and we asked the developer Michael Niedermayer directly."

Peter B.: the multithreading work was so cheap that "it embarrasses me to tell you how much it cost us"

Archives' wishlist → FFV1 v3

AMIA 2010: Herman Lewetz meets Dave Rice (CUNY TV). Wishlist: 10-bit, multithreading, CRCs

Oct 2010"FFV1 v2" (never marked stable): slices, global header (extradata)
May 201110-bit 4:2:0 and 4:2:2
Apr 2012"FFV1 v3": per-slice CRCs, slice headers, slice sizes
Aug 20129 to 14-bit RGB
Aug 2013Version 3 is no longer experimental (FFmpeg 2.1)

On a multi-core computer, 4 slices make encoding about 3 times faster

Slower than expected

Version 3 has been stable since 2013...

... but the encoder default stayed version 1 (no CRC)

 

"Use version 3 by default (CRCs by default)":

  • written in December 2019
  • committed in April 2025 (FFmpeg 8.0)

 

Archivists: always use -level 3 (and -slicecrc 1) explicitly

"But it is not a standard"

Quotes from archivists about FFV1 not being standardized

FIAT/IFTA World Conference, Vienna, October 2015, "FFV1 for Preservation" workshop

FFV1 standardization

Mainly sponsored by the PREFORMA project (2015-2017)

 

Review of the reference (FFmpeg) encoder and decoder

Review and improvement of the existing FFV1 spec draft

(written by Michael in LyX, on GitHub since 2012, converted to Markdown in 2015)

A conformance checker (MediaConch)

The IETF CELLAR working group, chartered in November 2015

FFV1 standardization

A slow process

Many people involved, little time

Most of the work done in people's spare time

Spec repository: 559 commits. Dave Rice ~290, Jérôme Martinez 140, Michael Niedermayer 95, Reto Kromer 13, Peter B. 11...

 

The IETF (the standards body) was very supportive
(thank you!)

FFV1 standardization

... but a very useful one!

Bugs found while reviewing the code

Corner cases clarified

e.g. slice tiling corner cases (ticket 5548): only fixed in version 4, in 2024

Derek Buitenhuis wrote an FFV1 decoder "for fun" (great: an independent look at the spec)

FFV1 standardization

FFV1 has been a standard since 2021 (IETF RFC 9043)

RFC 9043 extract

A big gap between the end of the main funding (2017) and the standard (August 2021)!

Reference encoder/decoder: more bit depths

For Y(A), YUV(A) and RGB(A)

  • 2016: 12-bit YUV and gray, 16-bit RGB
  • 2018: RGB48 no longer experimental, RGBA64, 10/12/16-bit RGBA
  • 2023: 14-bit RGBA and gray, 12-bit YUVA

Adoption

Very early adopters: Österreichische Mediathek (in AVI), City of Vancouver Archives, CUNY TV

BFI National Archive: 3 PB of DPX scans to FFV1/MKV with RAWcooked (since 2019)

Many others: NYPL, Indiana University, Smithsonian Institution Archives, Irish Film Institute, WGBH...

December 2023: Library of Congress moves FFV1/Matroska from "Acceptable" to "Preferred"

FFV1 present: GPU support

Vulkan encoder and decoder by Lynne, in FFmpeg 8.0 (August 2025)

  • Encoder (2024): versions 3 and 4, all pixel formats; real-time 1080p60 screen capture on modest GPUs
  • Decoder (2025): 4K RGB screen recording at 400 fps on an RTX 6000 Ada, vs ~100 fps on a 24-thread Alder Lake CPU
  • 2026: float and Bayer on the GPU too (FFmpeg 9.0, August 2026)

 

GPUs love many slices: up to 1024 slices now (32x32)

GPU: slow progress, then a big step

0 4 8 12 16fps Jul 2025 Jan 2026 Jul 2026 Oct 2026 FFmpeg 8.0 8.1 9.0 CPU: ~3 fps July 2025: decoding 6.8 fps FFmpeg 8.1 (March 2026): decoding 7.5 fps 14 September 2026: decoding 7.7 fps 27 September 2026: decoding 15.2 fps July 2025: encoding 5.8 fps FFmpeg 8.1 (March 2026): encoding 6.4 fps 14 September 2026: encoding 6.8 fps 27 September 2026: encoding 14.2 fps Decoding: 15.2 fps Encoding: 14.2 fps GPU encoding: 5.8 fps GPU decoding: 6.8 fps 14 months: about +15% 2 weeks: x2

6464x4852 16-bit RGB film scan, RTX 5070 Ti (GPU) vs Core i7-13700K (CPU), MediaArea benchmarks

Many small steps for 14 months, then a rewrite of the range coder with GPU subgroups (September 2026, not in FFmpeg 9)

GPU: it paid off everywhere

6K 16-bit film scan, GPU vs CPU of the same computer

  • RTX 3050 (entry level): GPU encoding was no faster than the CPU; now 3x faster
  • Apple M4: GPU encoding was 45% slower than the CPU; now 15% faster
  • RTX 3090: decoding 5.5x faster than the CPU

 

Next bottleneck: storage

Context models: which pixels?

TT TL T TR LL L X
Differences usedContexts
-context 0L−TL, TL−T, T−TR
11 levels (8-bit) or 9 levels		666 / 365
-context 1same + LL−L, TT−T
(5 levels each)		7563 / 5063
-context 2L−TL, TL−T only
5 levels each		13

The prediction is always the same: median of L, T and L+T−TL

The context only chooses which adaptive probabilities code the residual (32 bytes of state per context)

Many slices: a new problem

Every slice starts with fresh probability states

More slices = less data per slice to adapt

September 2026: a new, minimal context model (-context 2), not in FFmpeg 9

6464x4852 16-bit RGB film scan, 1024 slices, per frame:

  • -context 1: 100.79 MB
  • -context 0: 90.29 MB
  • -context 2: 87.99 MB (and 832 bytes of state per slice instead of 23 KB)

Stored in the extradata like the existing tables: existing decoders need no change

Not in FFmpeg 9: bug fixes too

Vulkan decoder fixes from August-September 2026:

  • version 4.8+ RGB streams from the CPU encoder: garbled output
  • pre-version 4 streams, non-keyframes: "intermittently decoded to garbage, with the slice CRCs still passing"

FFV1 near future: version 4

Already in FFmpeg 9.0 (August 2026), but still flagged experimental (-level 4 -strict experimental):

  • Floating point: 16-bit and 32-bit
  • Bayer (RGGB, 16-bit)
  • Raw slices, per-slice color transform coefficients

Partly funded by the Sovereign Tech Fund (2024-2026)

Next steps: freeze the bitstream, finish the IETF specification

Version 4 current goals

Bayer✓ in FFmpeg (RGGB 16-bit only), spec PR still open
Better compression / speed~ color transform search, -context 2, GPU
Limit worst-case size✓ raw slices
Arbitrary color spaces✗ multispectral PR, work in progress since 2019
Floating point✓ in FFmpeg; spec: first text in 2025, update pending

"Anything that finds no volunteers will be pushed to v5"

FFV1 further future

Not implemented yet:

  • Other Bayer patterns and bit depths
  • Raw storage of the lower bits
  • More than 4 channels (multispectral, infrared)
  • Inter prediction, other color transforms...

FFV1 in one slide

2003First commit in FFmpeg by Michael Niedermayer
2006The 8-bit format (version 0) is declared stable
2009Version 1: more than 8 bits per component (experimental until 2010)
2010The Österreichische Mediathek and CUNY TV adopt it, then ask for features
2012-2013Version 3: slices and CRCs. Stable in August 2013
2015-2017PREFORMA: spec review, conformance checker (MediaConch), IETF CELLAR
2021RFC 9043 (versions 0, 1 and 3)
2023Library of Congress: FFV1/Matroska becomes a "Preferred" format
2025FFmpeg 8.0: GPU (Vulkan) support, version 3 becomes the default
2026FFmpeg 9.0: version 4 with float and Bayer, still experimental. GPU speed x2 (after 9.0)

It did not appear from nowhere

  • One developer's hobby (2003)
  • Archives paying for the features they need (2010-2013)
  • An EU project paying for the spec and the checker (2015-2017)
  • Volunteers finishing the standard (2017-2021)
  • A public fund, the Sovereign Tech Fund, paying for some features (2024-2026)
  • RAWcooked sponsors participating in GPU support (2025-2026)

Each step needed money and someone's time

"Allocate continuous resources (time or money)" (Peter B., NTTW3, 2018)

Stay in touch

MediaArea: https://mediaarea.net, @MediaArea_net

RAWcooked: https://MediaArea.net/RAWcooked

Jérôme Martinez: jerome@mediaarea.net

Slides: https://MediaArea.net/Events

License (except images): CC BY

Sources