FFV1 for Archival: The Lossless Codec That Libraries and Archives Picked

What FFV1 Is

FFV1 is a free, open-source, lossless intraframe video codec. It's been the subject of standardization through IETF (RFC 9043) and used by major archives, libraries, and preservation institutions for digital video preservation.

The Library of Congress, BBC, FIAF (International Federation of Film Archives), and dozens of national libraries use FFV1 for archiving their video holdings. The codec produces files with bit-perfect reconstruction (no quality loss) at significantly smaller sizes than ProRes or DNxHR uncompressed alternatives.

This post covers FFV1's specific archival use case, the encoding workflow, the trade-offs vs ProRes/DNxHR, and the tooling for archival institutions. For broader codec context, see Apple ProRes Windows Workflow.

Why FFV1 for Archival

Archival institutions need:

1. Lossless compression: bit-perfect preservation
2. Royalty-free: no patent licensing risk over decades
3. Open source: implementation can be re-built if commercial vendor disappears
4. Documented standard: future archivists can understand the format
5. Smaller files than uncompressed: storage scales matter at archive scale

ProRes and DNxHR are lossless or near-lossless but proprietary. Apple and Avid could theoretically deprecate them. FFV1 is RFC-documented, can be implemented from scratch, and is included in FFmpeg (open source).

*ProRes 4444 XQ is mathematically lossless when input is 12-bit or below.

For library archives, FFV1's openness and documentation make it the only practical long-term lossless choice.

File Size Comparison

For 1 hour of 4K30 source content:

FFV1 is roughly 30% smaller than uncompressed. Comparable to ProRes 4444 in compression ratio but mathematically lossless and open.

For comparison context, see Apple ProRes Windows Workflow.

FFV1 Encoding

FFV1 is encoded via FFmpeg:

# Standard archival quality
ffmpeg -i source.mov \
  -c:v ffv1 -level 3 -coder 1 \
  -context 1 -g 1 -slices 24 -slicecrc 1 \
  -c:a flac \
  output.mkv

Parameters:

• -level 3: FFV1 version 3 (the standardized version)
• -coder 1: Range coder (better compression than Golomb)
• -context 1: Large context (better compression)
• -g 1: GOP size 1 (intra-only, archival default)
• -slices 24: Multi-threaded encoding via slices
• -slicecrc 1: Per-slice CRC for error detection (archival critical)
• -c:a flac: FLAC for lossless audio

FFV1 is typically wrapped in MKV (Matroska) container; the open-source FFV1 + open-source MKV is a clean preservation pairing.

Container Choice

For most archival workflows: MKV. AVI is acceptable but increasingly outdated. MXF is the broadcast equivalent.

For container choice, see MKV vs MP4 Container and MXF Format.

Archival Workflow

A typical archival workflow:

1. Source ingestion: original analog tape or digital RAW
2. Initial transfer: capture at full quality (DPX or uncompressed)
3. FFV1 archival master: one-time encode of the archival copy
4. Service copy generation: H.264 MP4 for researcher access
5. Long-term storage: FFV1 master to LTO tape and/or cloud archive
6. Periodic verification: SHA256 checksum on the master, periodic re-verification

For batch processing of an archive, see Batch Processing Files Guide.

Verification and Integrity

FFV1's -slicecrc 1 flag is critical for archival. Each slice has a CRC checksum. If a tape sector or disk block corrupts, you can detect which specific slice (essentially which 1/24 of each frame) was affected.

# Verify integrity
ffmpeg -i archive.mkv -c copy -f null - 2>&1 | grep -i error

If errors exist, FFmpeg reports them. Slice-level error reporting helps locate corruption.

For library-grade archive workflows, periodic verification (every 1-3 years) is standard. CRC failures trigger restoration from backup.

Audio Preservation

For lossless audio in archival files:

For most archives: FLAC inside MKV. Lossless and open.

For audio archival context, see AIFF vs WAV.

Tool Support

FFV1 is implemented in:

• FFmpeg: primary encoder/decoder
• VLC: playback
• DaVinci Resolve: import only (no encode in 2026)
• Avid Media Composer: import only
• Premiere Pro: limited
• MediaInfo: metadata reading

For most production NLEs: import is supported, encode is not. Use FFmpeg for FFV1 encoding.

For preservation institutions running custom software (Bagger, BIA, MediaConch), FFV1 is the de facto archival format.

Tape Storage (LTO)

LTO (Linear Tape Open) is the preservation industry's primary long-term storage:

Tape costs roughly $0.02-0.04/GB. For a 1 PB archive: $20,000-40,000 in tape vs hundreds of thousands for cloud at scale.

FFV1 archives on tape: typically a master + verification copy on different tape generations and locations. Geographic distribution prevents single-disaster loss.

Cloud Archival

For cloud archives:

• AWS Glacier Deep Archive: $0.001/GB/month
• Azure Archive Storage: $0.001/GB/month
• Google Cloud Archive: $0.0012/GB/month
• Backblaze B2: $0.005/GB/month (instant access)

For 100 TB FFV1 archive: ~$100/month at Glacier rates. Significant savings vs traditional storage at archival timescales.

Common Issues

Encoding very slow: FFV1 with high context settings is computationally heavy. Adjust -slices 24 to match CPU cores.

File not playing in some players: FFV1 support varies. VLC and FFmpeg-based players work. Older Windows Media Player won't.

Larger than expected: source material complexity affects compression. Highly random content (film grain, encoded compression artifacts) compresses less than smooth content.

Audio drift in long files: rare but happens. Use -vsync cfr flag for constant frame rate enforcement.

Cloud upload timeouts: large FFV1 files may exceed individual upload limits. Use multipart uploads or compress further with secondary lossless layer.

Frequently Asked Questions

Why FFV1 instead of HEVC lossless?

HEVC has patent royalty risk. For multi-decade archives, royalty-free formats are safer. FFV1 is documented in IETF RFC 9043, with multiple independent implementations possible.

Is FFV1 supported on macOS?

Via FFmpeg or VLC. Apple doesn't natively decode FFV1, so iMovie and Final Cut Pro require a transcode for editing. For archival use case (write once, read rarely), this is fine.

Can I encode FFV1 in real-time?

Software-only. Real-time encoding works on modern CPUs for HD content. 4K real-time may exceed CPU capability; encode offline.

What's the difference between FFV1 levels?

Level 1: original FFV1. Level 3: standardized version with multi-threading and slices. Always use Level 3 (or higher) for production work.

Should I keep both FFV1 and ProRes?

For archives doing active VFX or creative editing: keep both. ProRes for active work, FFV1 for archive. For pure preservation: FFV1 alone.

How long will FFV1 be readable?

The standard is in IETF (RFC 9043). Decoder source code is open. As long as someone can compile FFmpeg or write a new decoder from the spec: indefinitely. The risk is having no compatible computer; the format itself is preserved.

Related Reading

• Apple ProRes Windows Workflow
• MKV vs MP4 Container
• AIFF vs WAV for Archival

Bottom Line

For digital video archival in 2026: FFV1 in MKV with FLAC audio is the open-source preservation standard. Encode with FFmpeg using -level 3 -coder 1 -context 1 -slicecrc 1. Store on LTO tape and/or cloud archive (Glacier, Azure Archive). Keep ProRes or DNxHR alongside if active editing is expected. Our video converter hub handles MP4 service-copy generation from FFV1 master.