→Codec: not quite FFV1.4
|
Removed parameters. | Use this bot. Report bugs. | Suggested by AManWithNoPlan | Category:CS1 maint: url-status | #UCB_Category 95/2931
|
||
(10 intermediate revisions by 7 users not shown) | |||
Line 26: | Line 26: | ||
}} |
}} |
||
'''FFV1''' (short for '''FF Video 1'''<ref name=ffv1_specs_github/>) is a [[Video compression#Lossless compression|lossless]] [[intra-frame]] [[video coding format |
'''FFV1''' (short for '''FF Video 1'''<ref name=ffv1_specs_github/>) is a [[Video compression#Lossless compression|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.<ref name="ffv1_performance_test1" /><ref name="ffv1_performance_test2" /><ref name="ffv1_noa_graphs1"/> |
||
The encoder and decoder are part of the free, open-source library libavcodec in the project [[FFmpeg]] since June 2003.<ref>{{cite web|url=http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/ffv1.c;h=070e0240a2b1243fba4cbdc20716e36b5022a6e5;hb=HEAD;pg=1|title=Repository history of FFV1's sourcecode in FFMPEG repository|publisher=Michael Niedermayer|access-date=21 October 2010|url-status=dead|archive-url=https://web.archive.org/web/20120323190532/http://git.videolan.org/?p=ffmpeg.git%3Ba%3Dhistory%3Bf%3Dlibavcodec%2Fffv1.c%3Bh%3D070e0240a2b1243fba4cbdc20716e36b5022a6e5%3Bhb%3DHEAD%3Bpg%3D1|archive-date=23 March 2012}}</ref> FFV1 is also included in [[ffdshow]] and [[LAV Filters]],<ref>{{Cite web|url=https://github.com/Nevcairiel/LAVFilters|title=Nevcairiel/LAVFilters|date=June 26, 2021|via=GitHub}}</ref> which makes the video codec available to [[Microsoft Windows]] applications that support system-wide codecs over [[Video for Windows]] (VfW) or [[DirectShow]]. |
The encoder and decoder are part of the free, open-source library libavcodec in the project [[FFmpeg]] since June 2003.<ref>{{cite web|url=http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/ffv1.c;h=070e0240a2b1243fba4cbdc20716e36b5022a6e5;hb=HEAD;pg=1|title=Repository history of FFV1's sourcecode in FFMPEG repository|publisher=Michael Niedermayer|access-date=21 October 2010|url-status=dead|archive-url=https://web.archive.org/web/20120323190532/http://git.videolan.org/?p=ffmpeg.git%3Ba%3Dhistory%3Bf%3Dlibavcodec%2Fffv1.c%3Bh%3D070e0240a2b1243fba4cbdc20716e36b5022a6e5%3Bhb%3DHEAD%3Bpg%3D1|archive-date=23 March 2012}}</ref> FFV1 is also included in [[ffdshow]] and [[LAV Filters]],<ref>{{Cite web|url=https://github.com/Nevcairiel/LAVFilters|title=Nevcairiel/LAVFilters|date=June 26, 2021|via=GitHub}}</ref> which makes the video codec available to [[Microsoft Windows]] applications that support system-wide codecs over [[Video for Windows]] (VfW) or [[DirectShow]]. |
||
Line 36: | Line 36: | ||
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.<ref name="records_nsw-video_preservation_formats">{{cite web|url=http://www.records.nsw.gov.au/recordkeeping/government-recordkeeping-manual/guidance/guidelines/guideline-22/digital-audio-and-video-file-formats-form/formats-and-codecs-for-digital-video-preservation |title=Formats and codecs for digital video preservation (Guideline 22) |date=August 2013 |publisher=NSW State Records |access-date=10 November 2013 |url-status=dead |archive-url=https://web.archive.org/web/20131110105550/http://www.records.nsw.gov.au/recordkeeping/government-recordkeeping-manual/guidance/guidelines/guideline-22/digital-audio-and-video-file-formats-form/formats-and-codecs-for-digital-video-preservation |archive-date=10 November 2013 }}</ref> The previously proclaimed encodings were [[JPEG 2000#Motion JPEG 2000|Motion JPEG 2000]] (lossless)<ref name="mjpeg2k_archive_codec"/> and uncompressed video.<ref name="amia_iasa_2010-wrappers_and_codecs"/> |
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.<ref name="records_nsw-video_preservation_formats">{{cite web|url=http://www.records.nsw.gov.au/recordkeeping/government-recordkeeping-manual/guidance/guidelines/guideline-22/digital-audio-and-video-file-formats-form/formats-and-codecs-for-digital-video-preservation |title=Formats and codecs for digital video preservation (Guideline 22) |date=August 2013 |publisher=NSW State Records |access-date=10 November 2013 |url-status=dead |archive-url=https://web.archive.org/web/20131110105550/http://www.records.nsw.gov.au/recordkeeping/government-recordkeeping-manual/guidance/guidelines/guideline-22/digital-audio-and-video-file-formats-form/formats-and-codecs-for-digital-video-preservation |archive-date=10 November 2013 }}</ref> The previously proclaimed encodings were [[JPEG 2000#Motion JPEG 2000|Motion JPEG 2000]] (lossless)<ref name="mjpeg2k_archive_codec"/> and uncompressed video.<ref name="amia_iasa_2010-wrappers_and_codecs"/> |
||
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.<ref name="ffv1_performance_test1"/><ref name="fadgi_videotape_reformatting"/> Compared to |
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.<ref name="ffv1_performance_test1"/><ref name="fadgi_videotape_reformatting"/> 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.<ref>{{Cite web|url=http://www.digitizationguidelines.gov/about/|title=About - Federal Agencies Digitization Guidelines Initiative|website=www.digitizationguidelines.gov}}</ref><ref name="fadgi_videotape_reformatting2"/> |
||
Since around 2015, the European PREFORMA Project started working on the standardisation of FFV1 through the [[IETF|Internet Engineering Task Force (IETF)]].<ref name="preforma_home"/> It was standardised in August 2021 as <nowiki>RFC 9043</nowiki>.<ref name=":0" /> The PERFORMA Project also implemented a conformance checker for FFV1 in the [[Matroska]] container.<ref name="loc_blog_1"/> Details of FFV1's standardization plan<ref name="standardization_plan_1"/> have been prepared by MediaArea (authors of [[MediaInfo]]) as part of their conformance checking tool "Media CONCH".<ref name="preforma_mediaconch"/> |
Since around 2015, the European PREFORMA Project started working on the standardisation of FFV1 through the [[IETF|Internet Engineering Task Force (IETF)]].<ref name="preforma_home"/> It was standardised in August 2021 as <nowiki>RFC 9043</nowiki>.<ref name=":0" /> The PERFORMA Project also implemented a conformance checker for FFV1 in the [[Matroska]] container.<ref name="loc_blog_1"/> Details of FFV1's standardization plan<ref name="standardization_plan_1"/> have been prepared by MediaArea (authors of [[MediaInfo]]) as part of their conformance checking tool "Media CONCH".<ref name="preforma_mediaconch"/> |
||
Line 107: | Line 107: | ||
* AV Preservation by reto.ch<ref name="ffv1_avpres_reto"/> |
* AV Preservation by reto.ch<ref name="ffv1_avpres_reto"/> |
||
* [[University of Applied Sciences of Eastern Switzerland|HTW Chur]] |
* [[University of Applied Sciences of Eastern Switzerland|HTW Chur]] |
||
* [http://www.lausanne.ch/en/thematiques/culture-et-patrimoine/histoire-et-patrimoine/archives-communales.html Archives de la Ville de Lausanne] |
* [http://www.lausanne.ch/en/thematiques/culture-et-patrimoine/histoire-et-patrimoine/archives-communales.html Archives de la Ville de Lausanne] {{Webarchive|url=https://web.archive.org/web/20170518195928/http://www.lausanne.ch/en/thematiques/culture-et-patrimoine/histoire-et-patrimoine/archives-communales.html |date=2017-05-18 }} |
||
;United Arab Emirates |
;United Arab Emirates |
||
* Sharjah Media Corporation (SMC).<ref name="ffv1_smc"/> |
* Sharjah Media Corporation (SMC).<ref name="ffv1_smc"/> |
||
Line 128: | Line 128: | ||
=== Development and improvements === |
=== 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.<ref>{{Cite web |url=http://dva-profession.mediathek.at/ |title=dva-profession.mediathek.at |access-date=2012-05-10 |archive-url=https://web.archive.org/web/20120525021853/http://www.dva-profession.mediathek.at/ |archive-date=2012-05-25 |url-status=dead }}</ref> Additionally, they have initiated the development of "FFV1.3" (=version 3 of FFV1) together with Michael Niedermayer ([[FFmpeg]]), Peter Bubestinger and Dave Rice; see [[# |
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.<ref>{{Cite web |url=http://dva-profession.mediathek.at/ |title=dva-profession.mediathek.at |access-date=2012-05-10 |archive-url=https://web.archive.org/web/20120525021853/http://www.dva-profession.mediathek.at/ |archive-date=2012-05-25 |url-status=dead }}</ref> 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.<ref name="ffv1.3_release_commit"/> |
||
== Applications supporting FFV1 == |
== Applications supporting FFV1 == |
||
Line 161: | Line 161: | ||
|- |
|- |
||
| [[FFmpeg]] || {{yes}} || {{yes}} || built-in |
| [[FFmpeg]] || {{yes}} || {{yes}} || built-in |
||
|- |
|||
| [[HandBrake]] || {{yes}} || {{yes}} || built-in |
|||
|- |
|- |
||
| [[Harris Broadcast Velocity]] || {{yes}} || {{yes}} || [[Video for Windows]]<ref name="codec_pack-ffdshow_tryouts"/> |
| [[Harris Broadcast Velocity]] || {{yes}} || {{yes}} || [[Video for Windows]]<ref name="codec_pack-ffdshow_tryouts"/> |
||
Line 166: | Line 168: | ||
| [[kdenlive]] || {{yes}} || {{yes}} || built-in |
| [[kdenlive]] || {{yes}} || {{yes}} || built-in |
||
|- |
|- |
||
| KEM Scan ([[motion picture film scanner]])<ref name="kem_scan" /><ref>{{cite web |url=http://kem-studiotechnik.de/produkte/kemscan.html |title=KEM Scan |publisher=KEM Studiotechnik GmbH |access-date=2015-04-30}}</ref> || {{yes}} || - || built-in |
| KEM Scan ([[motion picture film scanner]])<ref name="kem_scan" /><ref>{{cite web |url=http://kem-studiotechnik.de/produkte/kemscan.html |title=KEM Scan |publisher=KEM Studiotechnik GmbH |access-date=2015-04-30 |archive-date=2016-04-24 |archive-url=https://web.archive.org/web/20160424085916/http://kem-studiotechnik.de/produkte/kemscan.html |url-status=dead }}</ref> || {{yes}} || - || built-in |
||
|- |
|- |
||
| [[LAV Filters]]<ref name="codec_pack-lavfilters"/> || {{yes}} || {{yes}} || built-in |
| [[LAV Filters]]<ref name="codec_pack-lavfilters"/> || {{yes}} || {{yes}} || built-in |
||
Line 198: | Line 200: | ||
=== Prediction process === |
=== 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: |
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: |
||
: |
:{{math|1=''prediction'' = Median(''Top'', ''Left'', ''Top'' + ''Left'' - ''TopLeft'')}} |
||
⚫ |
The third value, |
||
⚫ | The third value, {{math|1=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]].<ref>{{cite web|url=http://www.ffmpeg.org/~michael/ffv1.html|title=FFV1 Video Codec Specification|author=Michael Niedermayer|date=2013-09-05|access-date=2015-03-18|publisher=[[FFmpeg]]}}</ref> |
||
=== Entropy coding process === |
=== Entropy coding process === |
||
The residuals are coded using either |
The residuals are coded using either [[Rice coding|Golomb-Rice coding]]<ref>{{Cite web |title=FFV1 Specification, Golomb Rice Mode |url=https://github.com/FFmpeg/FFV1/blob/faa41034566964af9ff748738c9d3a26989b4363/ffv1.md#golomb-rice-mode |access-date=2024-06-06 |website=FFmpeg GitHub}}</ref>or[[range coding]]. Both options use a very large context model. The "small" context model uses {{math|1=(11×11×11+1)/2=666}} contexts based on the neighboring values of {{math|1=(''Left'' − ''TopLeft'')}}, {{math|1=(TopLeft-Top)}}, and {{math|1=(''Top'' − ''TopRight'')}}. The "large" context model uses {{math|1=(11×11×5×5×5+1)/2=7563}} contexts based on the same values as before, but also {{math|1=(''TopTop'' − ''Top'')}} and {{math|1=(''LeftLeft'' − ''Left'')}}, where {{math|''TopTop''}} is the pixel two above the current one vertically, and {{math|''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 |
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.<ref>{{Cite web |title=FFV1 Specification, Range Coding Mode |url=https://github.com/FFmpeg/FFV1/blob/faa41034566964af9ff748738c9d3a26989b4363/ffv1.md#range-coding-mode |access-date=2024-06-06 |website=FFmpeg GitHub}}</ref> |
||
== Status == |
== Status == |
||
On April 16, 2006, a commit-message by Michael Niedermayer confirmed that the bitstream of FFV1 (version 1) is frozen:<ref name="ffv1_bitstream_frozen"/> |
On April 16, 2006, a commit-message by Michael Niedermayer confirmed that the bitstream of FFV1 (version 1) is frozen:<ref name="ffv1_bitstream_frozen"/> |
||
<blockquote> |
|||
{{quotation | |
|||
"ffv1 and ffvhuff haven't changed since a long time and no one proposed any |
"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 |
changes within 1 month after my warning so they are officially no longer |
||
experimental and we will guarantee decodability of files encoded with |
experimental and we will guarantee decodability of files encoded with the current ffv1/ffvhuff in the future" |
||
</blockquote> |
|||
the current ffv1/ffvhuff in the future"}} |
|||
=== |
=== Versions === |
||
; Version 1 (FFV1.1) |
; Version 1 (FFV1.1) |
||
:The bitstream of version 1 is frozen and has been considered stable for production use since April 2006.<ref name="ffv1_bitstream_frozen"/> |
:The bitstream of version 1 is frozen and has been considered stable for production use since April 2006.<ref name="ffv1_bitstream_frozen"/> |
||
Line 223: | Line 227: | ||
:The bitstream of version 3 is frozen since August 3, 2013.<ref name="ffv1.3_bitstream_frozen"/> The final commit marking this version as officially released for production usage was on August 26, 2013.<ref name="ffv1.3_release_commit"/> |
:The bitstream of version 3 is frozen since August 3, 2013.<ref name="ffv1.3_bitstream_frozen"/> The final commit marking this version as officially released for production usage was on August 26, 2013.<ref name="ffv1.3_release_commit"/> |
||
: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,<ref name="ffv1_performance_test3"/> and officially released stable for production in August 2013.<ref name="ffv1.3_release_commit"/> |
: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,<ref name="ffv1_performance_test3"/> and officially released stable for production in August 2013.<ref name="ffv1.3_release_commit"/> |
||
:In August 2016, support for [[Color depth#Deep color (30-bit)|48bit/16bpc (=bits per component)]] in [[RGB color model|RGB]] was added.<ref name="ffv1_rgb48_commit"/> Before that, 16bpc in FFV1 were only supported in [[YCbCr]] and RGB was limited to 14bpc. |
:In August 2016, support for [[Color depth#Deep color (30-bit)|48bit/16bpc (=bits per component)]] in [[RGB color model|RGB]] was added to the reference codec.<ref name="ffv1_rgb48_commit"/> 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. |
: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) |
; Version 4 (FFV1.4) |
||
:Improvements beyond FFV1.3 are works in progress and being discussed on the IETF "CELLAR" mailing list.<ref name="ffv1_version_4_cellar"/> |
:Improvements beyond FFV1.3 are works in progress and being discussed on the IETF "CELLAR" mailing list.<ref name="ffv1_version_4_cellar"/> |
||
:Planned are additional support for color-handling, especially non-linear/logarithmic [[color spaces]]. |
:Planned are additional support for color-handling, especially non-linear/logarithmic [[color spaces]]. |
||
:The Draft standard is hosted on GitHub.<ref name="ffv1_specs_github"/> |
|||
== Documentation == |
== Documentation == |
||
Line 444: | Line 449: | ||
</ref> |
</ref> |
||
⚫ | <ref name="preforma_mediaconch">{{cite web |url=http://www.preforma-project.eu/mediaconch.html |title=CONformance CHecking for audiovisual files (CONCH) |access-date=2015-09-24 |archive-date=2015-09-24 |archive-url=https://web.archive.org/web/20150924081129/http://www.preforma-project.eu/mediaconch.html |url-status=dead }}</ref> |
||
<ref name="preforma_mediaconch"> |
|||
⚫ | {{cite web |url=http://www.preforma-project.eu/mediaconch.html |title=CONformance CHecking for audiovisual files (CONCH) |access-date=2015-09-24}} |
||
</ref> |
|||
<ref name="ffv1_smidak"> |
<ref name="ffv1_smidak"> |
||
Line 510: | Line 513: | ||
{{DEFAULTSORT:Ffv1}} |
{{DEFAULTSORT:Ffv1}} |
||
[[Category:Free video codecs]] |
[[Category:Free video codecs]] |
||
[[Category:Computer-related introductions in 2003]] |
Internet media type |
video/FFV1
|
---|---|
Developed by |
|
Initial release | 9 June 2003; 21 years ago (2003-06-09) |
Latest release |
Version 3 (FFV1.3) |
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]
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]
It is also listed as a format option for long-term preservation of moving images on sites of the U.S. Library of Congress',[12][19] State Records NSW[9] and others. The Society of American Archivists has published a paper in August 2014, suggesting only FFV1 as preservation codec for video.[20]
The Digital Preservation project at the U.S. Library of Congress identified AVI and Matroska as common container formats for FFV1.[21][22]
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 an interview for The New York Times magazine about "Tips on Archiving Family History",[29] Bertram Lyons from the U.S. Library of Congress says:
"[...] for video, there are many choices when it comes to codecs (the way the bits are encoded/decoded to represent the visual data, e.g., ffv1, H.264, Apple ProRes) [...]"
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]
"FFV1 has many beneficial technical features [...], but adoption rates are relatively low compared with alternatives, for example JPEG2000. [...] But holding back too long only serves to self-perpetuate the status of FFV1.
The adoption by Archivematica and the Austrian Mediathek with their active promotion of FFV1 along with others may start to break this vicious circle. This could lead to a virtuous circle of wider take-up, to shared development, to incorporation into commercial products and a host of other benefits for the community."
PACKED - the "Centre of Expertise in Digital Heritage" in Belgium, say in an article about video formats for archiving:[32]
"When removing the proprietary codecs from this list, only a few are left. [...] This basically leaves heritage institutions that want to use a lossless codec, with only two options: Jpeg2000 and FFV1."
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"?.[33] A workshop titled "FFV1 for Preservation" is also featured.[34]
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]
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:
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] |
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.
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]
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×11×11+1)/2=666 contexts based on the neighboring values of (Left − TopLeft), (TopLeft-Top), and (Top − TopRight). The "large" context model uses (11×11×5×5×5+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]
On April 16, 2006, a commit-message by Michael Niedermayer confirmed that the bitstream of FFV1 (version 1) is frozen:[69]
"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"
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]
| |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Video compression |
| ||||||||||||||
Audio compression |
| ||||||||||||||
Image compression |
| ||||||||||||||
Containers |
| ||||||||||||||
Collaborations |
| ||||||||||||||
Methods |
| ||||||||||||||
Lists |
| ||||||||||||||
See Compression methods for techniques and Compression software for codecs |
Data compression software
| |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Archivers with compression (comparison) |
| ||||||||||||
Non-archiving compressors |
| ||||||||||||
Audio compression (comparison) |
| ||||||||||||
Video compression (comparison) |
| ||||||||||||
|