|Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact|
|Full name||FF Video Codec 1, Version 0, 1, and 3|
FFV1 is a lossless intra-frame video codec from the FFmpeg project. The specification for FFV1 versions 0, 1 and 3 was published by IETF as RFC 9043: FFV1 Video Coding Format Versions 0, 1, and 3 in August 2021. (There is no version 2. See Notes for more information.)
The design of FFV1 considers the storage of image characteristics, data fixity, and the optimized use of encoding time and storage requirements. FFV1 is designed to support a wide range of lossless video applications such as long-term audiovisual preservation, scientific imaging, screen recording, and other video encoding scenarios that seek to avoid the generational loss of lossy video encodings.
Note: This brief update in November 2021 primarily provides an update on the publication of RFC 9043 by IETF. A more complete update will be done in early 2022.
|Production phase||Middle state, used for storage or archiving|
|Relationship to other formats|
|Has later version||FFV1 version 4. Not described at this time. Specification still in development at IETF|
|Used by||AVI_FFV1, AVI File Format with FFV1 video encoding|
|Used by||Matroska_FFV1, Matroska File Format with FFV1 video encoding|
|LC experience or existing holdings||As of this brief update in November 2021, the Motion Picture, Broadcasting and Recorded Sound Division (MBRS) has ingested several hundred ffv1/mkv files. These files were received from CUNY-TV through the American Archive of Public Broadcasting and the Library will receive many more of these files through the AAPB in the coming months. This page will be more fully updated in 2022 to reflect the expanded adoption and specification developments.|
|LC preference||FFV1 codec in the Matroska container is an 'acceptable' format in the Recommended Formats Statement for Video -- File-based but only for content without closed captions and/or timecode information. While captions are supported in Matroska, FFmpeg functionality is limited (and does not, for example, support Timed Text Markup Language or TTML).|
Internet Engineering Task Force (IETF) published RFC 9043: FFV1 Video Coding Format Versions 0, 1, and 3 in August 2021. Since 2018, the work-in-progress specification for FFV1 has been published as a sequence of Internet Drafts (which must be updated every six months by IETF policy), available on the Internet Engineering Task Force (IETF) FFV1 Video Coding Format Version 0, 1, and 3 datatracker. The FFV1 Video Codec Specification site from Michael Niedermayer has an undated legacy version from pre-IETF work. See history section of the Notes below which also reports on the CELLAR IETF standardization project launched in 2015.
Published as RFC 9043: FFV1 Video Coding Format Versions 0, 1, and 3 in August 2021. The FFV1 Video Codec Specification site from Michael Niedermayer has an undated legacy version from pre-IETF work.
FFmpeg's FFV1 GitHub repository serves as the drafting source of the FFV1 specification. According to the README, "The FFV1 specification was initially written in lyx. In July 2015 the formatting of the specification was transitioned to Markdown to be used with xml2rfc version 2. In August 2019 the formatting was transitioned to target xml2rfc version 3."
Increasing adoption in heritage repositories, especially now that RFC 9043 is published. But the success of the No Time to Wait (NTTW) series of symposiums starting 2016 and initially sponsored as part of the European PREFORMA (PREservation FORMAts for culture information/e-archives) project played a large part in the rapid spread of adoption in recent years. Very early adopters include the Austrian Mediathek using FFV1 wrapped in AVI for their preservation masters and The City of Vancouver Archives chose FFV1 wrapped in the Matroska container, as discussed briefly on the archives' blog. Significant influencers for FFV1 adoption include high profile institutions including The New York Public Library's AMI (Audio Moving Image) Preservation Labs which uses FFV1 version 3 in Matroska for both digitized motion picture film and video. and Indiana University Media Digitization and Preservation Initiative (MDPI) and the influential white paper published in March 2017 Encoding and Wrapper Decisions and Implementation for Video Preservation Master Files. Author Mike Casey summarized some of the advantages of FFV1 including "roughly 65% less data than a comparable file using the v210 codec" because "FFV1 uses variable bit rate encoding so the size of the resulting file varies according to the nature of the program content." At scale, this can result in a huge savings in storage cost and processing time. A selection of additional FFV1 users include the British Film Institute, the Smithsonian Institution Archives, Duke University Libraries, and Stanford Libraries among many others.
In 2020, the Library of Congress added Matroska and FFV1 as an "acceptable" format for file-based video content without closed captions and/or timecode information.
The IASA-TC 06 Guidelines for the Preservation of Video Recordings recommends Matroska and FFV1 for a number of different "classes" of video content including digitized analogue video recordings (class 1), digital videotapes with encodings that are “out of reach” or inappropriate for long-term retention (class 2), and digital videotapes with encodings that can be extracted “as data" (class 3). FFV1 in Matroska is also used as a preservation format for digitized motion picture film as an alternative to Digital Moving-Picture Exchange (DPX). Reto Kromer and Kieran O’Leary led this work with a presentation at NTTW in 2016 (see video of presentation) with Kromer later following up in his 2017 paper Matroska and FFV1: One File Format for Film and Video Archiving?: "The Matroska container and the FFV1 video codec are good choices for single-image-based content when making archive masters. Often, a resolution of 2K, or sometimes 4K, an RGB colour space, the 4:4:4 chroma sampling and a bit-depth of 16 bit per colour channel are canonical choices. For stream-based content, the Matroska container and the FFV1 video codec are also good choices for the archive master. A resolution of HD (with pillar-boxing of letter-boxing if required), in general, the Y′CBCR colour space, the 4:2:2 subsampling and a bit-depth of 10 bit are usually considered best practice." See slides from O'Leary and Kromer's talk on "Using Matroska and FFV1 for DPX Preservation" from The Reel Thing XXXVIII in Hollywood, California, 18–20 August 2016. This is echoed by Caroline Gil and Peter Oleksik in their talk Assessing the preservation of DPX image sequences with MoMA. Many NTTW presentations advocate for the use of FFV1 in Matroska with some notable ones including O'Leary's Migrating ProRes/MOV to FFV1/MKV from 2019, Peter Bubestinger-Steindl's Presets for FFV1 and MKV: Choosing the right parameters for the job (2019), Genevieve Havemeyer-King and Ben Turkus from NYPL MKV and Mass Digitization: What We've Learned Since Giving Uncompressed Video the Boot (video from 2017; presentation starts at about 5:17:00).
Media players that support FFV1 include VLC (VideoLAN client) and for encoders, the open source FFmpeg is the primary resource. MediaConch is an implementation checker, policy checker, reporter, and fixer for FFV1 (as well as Matroska and LPCM.
|Licensing and patents||
RFC 9043 is covered by IETF copyright statements as defined in BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents. Draft versions of the specification in GitHub carry a Creative Commons Attribution 4.0 International (CC by 4.0) license. The legacy 2003-2012 versions of the specification at the FFmpeg site carried a copyright attribution to Michael Niedermayer and a declaration that "this text can be used under the GNU Free Documentation License or GNU General Public License."
|Transparency||Depends upon algorithms and tools to read; will require sophistication to build tools.|
|Self-documentation||Section 4 of the specification indicates that the types of technical metadata required to read and play the file are provided in frame headers. Additional metadata, if any, would be carried by the wrapper format. Comments welcome|
|Technical protection considerations||Not provided by the bitstream encoding. Technical protections, if any, would be provided by the wrapper format.|
|Clarity (high image resolution)||Lossless compression that retains all of the video picture information presented to the encoder. Comments Welcome|
|Internet Media Type||video/FFV1
||As defined in RFC 9043 and IANA Media Type list|
|Pronom PUID||See note.||PRONOM has no corresponding entry as of November 2021.|
|Wikidata Title ID||Q579857
||See https://www.wikidata.org/wiki/Q579857. Note that Wikidata does not specify versions.|
The Wikipedia FFmpeg article, consulted May 7, 2012, reports that the FFmpeg project "was started by Fabrice Bellard (using the pseudonym "Gerard Lantau") and has been maintained by Michael Niedermayer since 2004. . . . The name of the project comes from the MPEG video standards group, together with 'FF' for 'fast forward.'" Niedermayer's Web page states that an FFV1 encoder and decoder have been part of the FFmpeg library since 2003. Incidentally, the section of the specification devoted to frame header metadata includes the tag "version" with possible values of "0" or "1."
The "V" in FFV1 stands for "Video Codec," not "version." According to RFC 9043, the version release timeline is as follows: