FFmpeg: The Incredible Technology Behind Video on the Internet | Lex Fridman Podcast #496
FFmpeg and VLC form the invisible open-source backbone powering nearly all internet video, built on extreme technical craft, reverse engineering, and a volunteer ethos that rejects monetization and backdoors.
Key takeaways
10 points- 1FFmpeg powers the majority of internet video encoding, decoding, and streaming.
- 2VLC plays virtually any file on any platform without ads or tracking.
- 3Handwritten assembly remains essential for real-time performance on diverse hardware.
- 4Open-source projects accept contributions solely on code merit.
- 5Security researchers often overstate risk in obscure or obsolete codecs.
- 6Forks can strengthen projects by forcing architectural improvements.
- 7Archivists rely on FFmpeg and FFV1 for long-term cultural preservation.
- 8AV1 already carries 30-50% of major streaming traffic.
- 9VLC compiles on offline machines to prevent supply-chain attacks.
- 10Kyber targets 4 ms glass-to-glass latency for machine control.
Summary
FFmpeg and VLC are the open-source engines behind almost all video on the internet, from YouTube and Netflix to Mars rovers, sustained by volunteer developers who prioritize robustness and freedom over profit.
Core Technology
- FFmpeg supplies the low-level libraries for decoding, encoding, muxing, and filtering used by nearly every video application and service (0:00-12:02).
- Video playback flows through demuxing, decoding, and rendering; codecs exploit spatial/temporal redundancy and human perception via YUV to reach 100-200x compression (12:05-36:14).
Open Source Model
- Projects accept code purely on merit; contributors range from teenagers to factory workers, with harsh but effective reviews modeled on Linus Torvalds (48:22-1:00:25).
- VLC rejected multi-million-dollar ad and toolbar deals to stay ad-free and independent (1:00:28-1:12:31).
Technical Craft
- Handwritten assembly (over 100k lines) and projects like dav1d deliver 10-62x speedups; FATE tests across every compiler and architecture (2:00:52-2:25:01).
- Reverse engineering of proprietary codecs by Kostya Shishkov and others preserved compatibility for obscure formats (1:43:46-2:00:50).
Challenges and Future
- Security researchers and AI-generated reports create noise; forks like Libav ultimately strengthened FFmpeg (2:37:09-2:49:11).
- FFV1 and Kyber extend the stack into lossless archiving and ultra-low-latency machine control (3:49:42-4:18:09).
Deep read
Executive Summary
FFmpeg and VLC are the invisible engine of the internet’s video. This Lex Fridman Podcast with Jean-Baptiste Kempf and Kieran Kunhya dives deep into the craft, culture, and mechanics behind the software that decodes, encodes, and streams video for billions of users. The conversation covers the life-cycle of video data—from network address to byte stream, through containers and codecs, to pixels on a screen—while unpacking the immense engineering effort, open-source governance, and community-driven resilience that sustains FFmpeg and VLC. The episode also illuminates the human side of open source: the personal sacrifice, the drama and humor of communities, the ethical stances around licensing, and the audacious technical feats (handwritten assembly for AV1 decoders, proactive testing regimes like FATE, and pioneering low-latency workflows). It ends with a look at future horizons—AV1/AV2, archival codecs, XR/3D content, and ultra-low-latency robotics via Kyber—while underscoring the enduring value of open-source in enabling access, innovation, and preservation of multimedia heritage.
Key themes include the ecosystem’s architectural humility (containers vs codecs; demuxers vs decoders); the tension between performance and maintainability (hand-written assembly versus compiler optimizations); the social contract of licenses and the hard realities of contributor burnout; and the aspirational vision of a future where incredibly complex, edge-case media tech remains accessible to all through open collaboration.
Major Topic
The Incredible Technology Behind Video on the Internet
- This episode features Jean-Baptiste Kempf (lead developer of VLC, VideoLAN) and Kieran Kunhya (FFmpeg contributor, codec engineer) discussing the open-source backbone of video on the internet, the craft of low-level engineering, and the spirit of communities that sustain FFmpeg and VLC.
- Lex Fridman frames FFmpeg and VLC as foundational, open-source infrastructure that powers virtually all video platforms (YouTube, Netflix, Chrome, etc.) and highlights the sheer scale (billions of devices, trillions of decodings) and the people behind it.
- The conversation emphasizes that modern civilization relies on extremely complex yet well-maintained software, often built by volunteers, with open-source licenses shaping collaboration, business models, and governance.
"FFmpeg is probably one of the biggest CPU users in the world. Everything we've just said in the past couple of minutes, every sentence is someone's lifetime's work." (Transcript excerpt)
Guests and Mission
- JB Kempf: President of VideoLAN, lead developer behind VLC; advocate for open-source, ad-free VLC, and a steward of the VLC/FFmpeg ecosystem.
- Kieran Kunhya: Longtime FFmpeg contributor, codec engineer; maintains the @FFmpeg X/Twitter presence; emphasizes real-world, hands-on engineering, reverse engineering, and the culture of open source.
- Lex expresses admiration for people who contribute to foundational software rather than pursuing fame or money; highlights the invisible infrastructure that supports billions of users.
"The legend goes VLC can open everything... the cone is iconic; the cone is a symbol of the archival mission of video codecs and open-source infrastructure." (Transcript excerpt)
Weirdest Things VLC Opens
- JB and Kieran recount unusual tests and use cases that VLC has been pushed to handle:
- Recording VHS via capture cards; VLC can control some camcorders directly. - DVD Audio support addition; handling odd/rare codecs and even a Star Wars game sequence with exact bit-for-bit replication. - A VideoLAN conference challenge to create the weirdest file that VLC could still play (MKV with changing resolutions/aspect ratios; animated subtitles; a valid ZIP that also contains a valid MP3, etc.). - The cone icon’s symbolism and long-standing identity across India, China, etc.
- These anecdotes illustrate the robustness and flexibility of VLC’s architecture and the community’s willingness to push edge cases to the limit.
"We had a competition to make the weirdest and most horrible file ever... and it worked; VLC opened all of them." (Transcript excerpt)
How Video Playback Works: The High-Level Pipeline
- The core question: when you press play, what happens from file/stream to pixels and sound?
- High-level stages described:
- Addressing: Resolve a URL or path to a stream of bytes (HTTP, file, DVD). - Demuxing/Container: The mux/demux step splits the stream into tracks (video, audio, subtitles) and handles container formats (MP4, MKV, AVI, MOV, Matroska, etc.). - Codec Detection and Hardware Acceleration: VLC/FFmpeg probe capabilities to decide whether a given video can be decoded on GPU hardware or requires software decoding; note that ~45% of files are not GPU-decodable, due to vendor variations and format specifics. - Deentropy/Entropy Coding: The bitstream is dequantized and entropy-decoded (e.g., Huffman/arith coding) to recover the underlying data. - Intra/Inter Prediction and Residuals: Intra prediction happens on spatial blocks (I-frames); residuals are stored in the frequency domain and then transformed back to the spatial domain after inverse transforms. - Color and Perception: Video uses YUV color space to align with human vision; chroma subsampling reduces color detail which humans are less sensitive to; many transforms are implemented in the frequency domain (Discrete Cosine Transform-like operations) to achieve compression. - Bit-Depth/Compression Power: Compression aggressively removes redundant information (spatial and temporal) to achieve 100x–200x reductions; this requires enormous compute and carefully chosen trade-offs for human perceptual quality. - Display/Output: The decoded frames are sent to the GPU/display, while audio is sent to the audio pipeline.
- Important concepts:
- Containers vs Codecs: Container (e.g., MP4, MKV, MOV) holds tracks; codecs (e.g., H.264, AV1) encode/decode the actual media streams. Containers multiplex multiple streams; codecs compress the data. - Real-world variability: File extensions (.MP4) are not reliable indicators of content; FFmpeg/VLC probe actual content to determine the proper demuxer and decoder. - Practical reality: A huge portion of streaming quality depends on rate-distortion optimization, psychovisual (perceptual) quality metrics, and hardware constraints.
"The stream needs to be cut up by what’s known as the container, the demultiplexer or demux... There can be variants of a given codec; different GPU vendors have different capabilities; these need to be detected." (Transcript excerpt)
Containers, Codecs, and the Demux Challenge
- Containers vs codecs:
- Container: package format that holds streams, metadata, and timing information (e.g., MP4, MKV, MOV, AVI, Matroska). - Codec: algorithm to encode/decode a stream (e.g., H.264/AVC, AV1, HEVC/H.265, VP9).
- Real-world nuance:
- The same video file might be labeled MP4 while containing a non-MP4-compatible stream; VLC/FFmpeg probe and attempt multiple demuxers to find a compatible path. - VLC’s long-standing philosophy: minimize format assumptions and maximize robustness against broken files; the system is designed to keep playing even when inputs are damaged, reflecting security/robustness considerations.
- The open-source ecosystem’s “video everything” scope is driven by the need to support endless variants across devices and networks.
"In reality, a file may say .MP4, but it may be something completely different; we discard the file format and probe content in real time." (Transcript excerpt)
What is a Video Codec? How Compression Works (Part 1)
- Core idea: video has substantial redundancy in both space (within a frame) and time (across frames). A codec removes this redundancy, often requiring heavy compute to achieve high compression, because the decompression step must be efficient for playback.
- Key aspects:
- Color space: traditional RGB is replaced by YUV to align with human visual sensitivity; luminance (brightness) is prioritized over chrominance (color) detail. - Transform domain: frequency-domain transforms (e.g., discrete cosine transforms) enable separation of important visual components from less important data, enabling aggressive quantization and bitrate control. - Temporal compression: relies on inter-prediction across frames (I-frames, P-frames, B-frames); I-frames are complete frames, P-frames predict from past frames, B-frames can depend on past and future frames. - Quantization and rate control: quantization reduces precision to save bits; the encoder-prioritizes perceptually important details (psychovisual rate distortion) to maximize perceived quality per bit. - Encoder vs decoder complexity: modern codecs trade encoding complexity for decoding efficiency; the encoder can be much heavier than the decoder.
- The conversation emphasizes that in video, compression is not like general ZIP-like compression; hiding perceptual quality through advanced psycho-visual models is essential.
"Compression is degrading the signal to match human perception; and we use Fourier-like transforms and quantization to do so. Thirty percent better compression often comes at orders of magnitude more CPU power; decoding is designed to be fast, encoding can be heavier." (Transcript excerpt)
What is FFmpeg? The Core Idea and Where It Sits
- FFmpeg is a collection of low-level multimedia libraries and tools that enable encoding/decoding (libavcodec), container I/O (libavformat), filtering (libavfilter), and probes (ffprobe).
- It provides a pipeline to process multimedia across platforms and devices; it’s used as a library by VLC, browsers, smart TVs, and other software components.
- The command-line tool FFmpeg is legendary for its expressiveness and breadth; it’s effectively a Turing-complete DSL for multimedia processing (filters, codecs, demuxers, muxers, scaling, overlays, timing, etc.).
- FFprobe and checkasm are critical tools: ffprobe for metadata inspection; checkasm is a project that tests and checks the correctness of codecs across multiple architectures; it helps catch miscompilations and hardware-specific issues.
- The mission behind FFmpeg and VLC is to democratize media tech: from grandma’s old home videos to mega-corporate pipelines, the same stack runs across the board; this is the “level playing field” of video tech.
"FFmpeg is the low-level libraries for codecs, so compressions and decompression, muxers and demuxers, and filters... the core is this, and then you have several tools which allow you to create a type of pipeline to process any type of video files." (Transcript excerpt)
The Open-Source Ethos: Why Keep VLC Ad-Free and Why Re-licensing Is Hard
- The two core pillars JB emphasizes: high-quality code and a generous, non-extractive economics model. VLC has famously refused ads and large buyouts; the decision is framed as a moral stance aligned with open-source values.
- Licensing topics are central: GPL vs LGPL, and the strategic decision to move VLC’s core (libVLC) from GPL to LGPL to enable integration into proprietary products (like games) without forcing source release of the entire product.
- The licensing decision process is deeply human: re-licensing from GPL to LGPL means contacting hundreds of contributors (JB recounts hundreds of contributors; some cases involve contributors who are not alive), and it’s a social contract in which community consent matters as much as legal formalities.
- The conversation also discusses the complexity of modern licensing ecosystems: GPL, LGPL, MPL, BSD, MIT, AGPL; public-domain questions; and how different jurisdictions (France vs US) interact with software patents and licensing philosophies.
- JB highlights that re-licensing can be necessary to enable external product usage and monetization without forcing open-sourcing of downstream products; the conversation frames licensing as a living social contract that evolves with community needs and platform realities.
"The license is a social contract in terms of Rousseau; the community does not agree on much beside the license... We moved the core libVLC from GPL to LGPL to enable integration into third-party apps; that would not have been possible under GPL." (Transcript excerpt)
The Linus Torvalds Archetype and the Maintainer Ethos
- Linus Torvalds is invoked as the archetype for a meritocratic, ruthless-but-just code-review culture; the point is to keep high standards because the VLC/FFmpeg core is small (five to ten core maintainers) relative to the vast dependency graph and user footprint.
- The emphasis is on maintainability, readability, and the ability to sustain through burnout: the core team can be small, but their work is the backbone for thousands of contributors and millions of users.
- The conversation voices a pragmatic approach to maintaining quality: you need to be tough on patches that do not meet the standards; but you also need to recognize the personal, human side of contributors—often introverted, from diverse backgrounds.
- JB notes the importance of a supportive culture in which patches are judged by code quality, not by who submitted them; a key theme is to separate persona from code quality.
"The core community of VLC is five people; the core of FFmpeg is ten to fifteen... We are the ones who maintain your code." (Transcript excerpt)
Ad-Free VLC: The Decision to Turn Down Millions
- JB recounts the famous anecdotes about turning down millions of dollars to keep VLC ad-free; the rationale is moral: aligning with open-source ethos, not compromising the project for revenue.
- The rationale also includes practical concerns: commercial licensing would require legal and operational overhead, potential greenwashing, and the risk that downstream forks and vendor lock-in would degrade the project’s mission.
- JB’s story illuminates the tension between a sustainable business model and maintaining freedom from embedded content strategies that could compromise user trust.
"I refused dozens of millions... because I thought it was not moral... VLC’s story is about maintaining the ethos of open source and independence." (Transcript excerpt)
FFmpeg and Google: The Security-Reporting Debacle and Its Aftermath
- The dialogue turns to a controversial incident where Google used AI to generate security reports on FFmpeg; volunteers faced a flood of AI-generated patches and bug reports; Google publicly showcased AI’s capabilities, while FFmpeg/VideoLAN had to grapple with patch quality, patch volume, and the sustainability burden on volunteer maintainers.
- The conversation contrasts attacker/defender dynamics: Google’s resources vs. volunteers; the tension between responsible disclosure, patching cadence, and the risk of burnout from relentless security reporting.
- The X (Twitter) fiasco: a public dispute over a major company (Microsoft Teams) involving bug trackers, unsupported patching, and the broader issue of how big companies interact with open-source maintainers who rely on volunteer labor.
- The overall takeaway is that OSPOs and major tech firms need to work with communities in constructive, funded, patch-oriented ways to avoid creating unsustainable burdens on volunteer maintainers.
"The Google AI reports were high-volume, high-priority; maintainers can be overwhelmed; the right response is patches and collaboration, not over-claiming and fear-mongering." (Transcript excerpt)
FFmpeg, Libav, and the Open-Source Ecosystem: Forks, Mergers, and Burnout
- A historical note: FFmpeg and Libav experienced a split around governance and development processes; Libav lineage contributed to FFmpeg and then merged back; forks illustrate both the tensions and the resilience of open-source ecosystems.
- Burnout is identified as a central risk to core maintainers; the conversation emphasizes support, sustainable workload distribution, and the need for institutional backup to prevent single points of failure.
- The archiving community (FFV1, archiving codecs) is described as essential for long-term preservation; archivers fund development and testbeds for lossless codecs and archival-grade workflows; their work intersects with FFmpeg’s long-tail distribution needs.
"Forks are a part of open source; burnout is a real problem; the archiving community funds FFV1 and helps preserve the world’s multimedia heritage." (Transcript excerpt)
The Binary Star System: VLC and FFmpeg Are Not Competitors
- The relationship between VLC and FFmpeg is described as a binary star system: they depend on each other and co-evolve; many FFmpeg contributors also contribute to VLC and vice versa; the ecosystem gains from mutual reinforcement.
- x264 is highlighted as a pivotal VideoLAN project that amplified FFmpeg’s adoption; VLC contributed to broader decoding support by providing robust, widely-tested codecs and infrastructure; the integration of components across projects creates a virtuous cycle.
- The discussion includes: common dependencies (libavcodec, libavformat, libavfilter; x264; dav1d), and the reality that many systems rely on a mix of libraries that originate in VideoLAN projects.
"VLC is to FFmpeg as Android is to Linux: they depend on each other but coexist; a binary star system." (Transcript excerpt)
The Historical Eras and Key Figures of FFmpeg
- Fabrice Bellard: creator of FFmpeg’s foundational concept.
- Michael Niedermayer: key figure in the 2000-era FFmpeg (support for DivX/Xvid and MPEG-4 Part 2 variants); contributed to FFmpeg’s early strength.
- Kostya Shishkov: reverse-engineering expert who tackled GoToMeeting and CineForm; known for “binary blob” reverse engineering and for GoToMeeting 4/5/2–4 era work; JB and Kieran describe Kostya’s approach as visionary and hands-on.
- Loren Merritt: bold propeller of x264; assembly-centric optimization that propelled fast decoding/encoding in real time.
- The late-2000s–2010s era: collaboration across many players, including iOS/ARM variants, and the era of highly optimized hand-written assembly for AV1 (dav1d) with tens/hundreds of thousands of lines of assembly.
- The open-source community is a panoramic mosaic of contributors across ages, backgrounds, and skill levels; the culture emphasizes mastery, craft, and a shared mission to democratize multimedia.
"FFmpeg’s Dav1d decoders: tens/hundreds of thousands of lines of handwritten assembly; 79.9% assembly, 19.6% C, 0.5% other—every cycle matters." (Transcript excerpt)
The Role of Assembly and Low-Level Optimization
- The speakers emphasize that video processing sits at the intersection of software and hardware: every CPU instruction matters when decoding 100s of millions/hundreds of millions of frames per second.
- Assembly language and hand-tuned SIMD (Single Instruction, Multiple Data) code can yield dramatic speedups over high-level C, challenging the conventional wisdom that modern compilers can do all the optimization automatically. The examples include 62x speedups cited for specific AV1/dav1d code paths.
- The philosophy: hardware-wisdom at the edge scales; the team often writes custom assembly for various architectures (x86, x86_64, ARM64, RISC-V) with runtime CPU feature detection to select the best path.
- The discussion on assembling and calling conventions highlights the complexity of cross-ABI compatibility; some projects even implement their own calling conventions inside a library to reduce overhead.
- The practical upshot: for mass-market video, the best results are achieved not by generic languages alone but by a tuned stack that rides as close to the hardware as possible.
"The idea is: every cycle matters. Dav1d has about 240,000 lines of handwritten assembly; 100,000 lines for all codecs; this is the art of optimization at scale." (Transcript excerpt)
Rust, Go, and the Language Debate in FFmpeg/VLC World
- The panelists discuss Rust as a memory-safe alternative to C for certain components; there is broad interest in using Rust for new modules but concerns about interoperation with existing, highly optimized assembly/C portions (
- Rust shines when starting new projects; interoperability with existing C/assembly can be non-trivial and may undermine security goals when used improperly. - The risk: rewriting core components in Rust can cause ABI and interoperability issues with hand-optimized assembly; the project must preserve high-performance, low-level guarantees.
- The consensus is nuanced: Rust is valuable for new modules with strong security requirements, but the cost of refactoring large, well-optimized codebases (like FFmpeg’s assembly-heavy paths) is high; the community generally prefers incremental, secure integrations rather than wholesale rewrites.
- The broader takeaway: the FFmpeg/VLC ecosystems value performance and safety, but changes come with heavy maintenance and compatibility costs.
"Rust is valuable for memory safety in new modules, but rewriting core paths—especially those with handwritten assembly—can break performance and ABI expectations." (Transcript excerpt)
The GoToMeeting Reverse Engineering Tale and Sample-Based Learning
- Kostya Shishkov’s GoToMeeting reverse-engineering work remains a vivid example of edge-case codec work; the conversation provides a window into how reverse engineering a blob (20–30 MB) requires dumping YUV data, using disassemblers, and reconstructing the piecewise logic (entropy coding, DCT/IDCT paths, motion compensation).
- The process is described as an archaeologist’s hunt: you work with samples, infer structures, check bit-exactness, and exploit patterns (DCT, entropy coding) to reconstruct decoders.
- CineForm is another example; the patch-based approach involved getting a sample with certain properties (e.g., flat blocks) to anchor reverse-engineering efforts and gradually reconstruct the pipeline.
"Reverse engineering a blob is like archaeology: you start with samples, infer the structure bit by bit, and discover an entire codec’s workflow by looking at the machine code and the data it outputs." (Transcript excerpt)
FFmpeg Testing, FATE, and the Importance of Validation
- FFmpeg Automated Testing Environment (FATE) is the backbone of cross-architecture validation; thousands of configurations exist due to OS variants (Windows, macOS, Linux, BSD), compilers (GCC, Clang, MSVC), architectures (x86, ARM, PowerPC, DEC Alpha), and diverse toolchains.
- The testers run on a matrix of configurations with memory-sensitive checks; miscompilations can cause subtle, cascading differences in frame rendering; FATE logs reveal which configurations pass/fail and help identify regressions.
- The ethos: testing is a community-driven, ongoing effort; coverage across architectures, compilers, and platforms is critical to ensuring FFmpeg’s portability and correctness.
"FFmpeg Automated Testing Environment—FATE—has hundreds of configurations; miscompilations can cause cascading errors; the scale is insane." (Transcript excerpt)
The Beauty and Danger of Assembly: Lessons, Lessons, Lessons
- The modules discuss the beauty and artistry of assembly: the craft of hand-tuning critical loops; the concept of SIMD for video processing; the micro-optimizations that yield real-time performance on billions of devices.
- The speakers share a reverence for the art form (assembly) while acknowledging the risks: maintaining readability, portability, and safety; ensuring that bespoke assembly remains compatible across CPU generations.
- Guests highlight the continuing value of learning assembly, not as a relic but as a powerful tool for performance-critical paths like AV1/dav1d, x264, and other codecs.
- They also point to the educative potential of the assembly ecosystem, through resources like asm-lessons and community-driven training to pass the craft to new generations of developers.
"Assembly is the art of pushing hardware to the limit; it’s necessary because high-level compilers cannot always extract the maximum performance; we’re talking 62x speedups on certain paths." (Transcript excerpt)
The Rust Debate, New Language Ideas, and the Future of Code Reuse
- The conversation weighs the pros/cons of Rust: memory safety, readability, and modern tooling vs. the practicality of existing, optimized C/assembly paths; the risk of fragmentation and ABI incompatibilities when mixing languages.
- The general stance: use Rust for new, self-contained components where it makes sense; preserve critical hot paths in C/assembly; avoid full rewrites that break performance assumptions.
- The broader implication: the FFmpeg/VLC ecosystems demonstrate how language choices interface with performance, openness, and long-term sustainability in large, mission-critical software.
"Rust rewrites are tempting but risky in a codebase with tens/hundreds of thousands of lines of optimized assembly; new modules in Rust are okay, but don’t rewrite core paths." (Transcript excerpt)
The Patents and AV1/AV2 World: Patents, Licensing, and Royalty-Free Paths
- The codecs landscape has shifted from licensing-heavy standards (H.264/HEVC) to royalty-free or less-patented avenues (AV1/AV2). The Alliance for Open Media (AOM) leads AV1/AV2 development; licensing risks and patent pools (MPEG LA, HEVC Advance) shape the economics of traditional codecs.
- AV1/AV2 promise substantial bitrate reductions (roughly 30%–40% over H.264/HEVC in typical scenarios) with heavy computational loads and encoder complexity; modern hardware and software paths attempt to balance server-side encoding cost against client-side decoding power and bandwidth.
- FFmpeg and VLC keep a neutral stance on licensing; the community emphasizes patent awareness, open formats, and royalty-free standards; AV2 aims to maintain royalty-free openness while delivering practical performance improvements.
"AV1/AV2 deliver 30% better compression; the encoder is extremely compute-intensive; hardware and cloud services must balance encode time vs. distribution costs." (Transcript excerpt)
The CIA, Backdoors, and the Open Source Security Ethos
- The conversation touches on real-world security concerns and a few infamous anecdotes: alleged backdoors in VLC (CIA Vault 7) and other security allegations. The keynote stance is transparency and community governance; VLC is designed to be offline and independent of external telemetry, protecting users’ privacy.
- The team emphasizes the risk of backdoors and the need for secure development practices: validating builds, offline compilation, multiple sign-offs, and community oversight.
- The broader narrative emphasizes that open-source ecosystems are not immune to security concerns but can be resilient when the community remains vigilant and openly discusses potential vulnerabilities.
"The CIA Vault 7 incident highlighted how a purported VLC backdoor could appear in a targeted way; the official response emphasized public-source verification and secure build processes to counter threats." (Transcript excerpt)
Video Archiving, Preservation, and the Long-Term Vision
- The archiving community (including FFV1 and other archival codecs) collaborates with FFmpeg to preserve multimedia for future generations; their priorities include lossless compression, long-term readability, and evolvability (bitstream compatibility, future-proofing).
- The idea is to secure a thousand-year archive of media that can still be decoded as hardware evolves; the community stresses the ethical and cultural imperative of preserving video heritage in formats and codecs that remain accessible to future generations.
"Archiving is critical; FFV1 and archival codecs help preserve multimedia for the long term; the aim is to preserve human culture as a readable archive for future centuries." (Transcript excerpt)
The Future of FFmpeg, VLC, and the Open-Source Multimedia Ecosystem
- The conversation closes with visions of where multimedia tech might go in the next years/decades: tighter integration with XR/VR, 3D/volumetric content, brain-computer interface (BCI) workflows, and future streaming paradigms.
- There is a recurring theme: the ecosystem will continue to push for openness, accessibility, and cross-platform compatibility; the goal is to empower individuals around the world to create, share, and preserve media with minimal friction.
- Kyber, a new venture by one of the speakers, targets ultra-low latency control for robotics and remote operation; it uses QUIC (a UDP-based protocol) for low-latency streaming and control, with a dual licensing model (AGPL/commercial) to balance openness with sustainability.
- The speakers emphasize the social impact: open-source multimedia empowers individuals, educators, and small teams to achieve enormous feats with minimal gatekeeping; it’s about mastery and craft as much as about the technology.
"Future of FFmpeg and VLC includes AR/VR streaming; 4 ms glass-to-glass latency is a grail for real-time robotics; the ecosystem will expand to new media forms and interfaces, including brain-computer interfaces." (Transcript excerpt)
Resources Mentioned
- FFmpeg: https://ffmpeg.org/
- VideoLAN (VLC): https://www.videolan.org/
- FFmpeg on X / Twitter: https://x.com/FFmpeg
- VideoLAN on X: https://x.com/videolan
- Jean-Baptiste Kempf: https://jbkempf.com/
- Jean-Baptiste’s LinkedIn: https://www.linkedin.com/in/jbkempf/
- Jean-Baptiste’s GitHub: https://github.com/jbkempf
- Kieran Kunhya / X: https://x.com/kierank_
- Kieran’s LinkedIn: https://bit.ly/3OORhmC
- Kieran’s GitHub: https://github.com/kierank
- Sponsors: Larridin, Blitzy, BetterHelp, Fin, LMNT, Perplexity (links in episode description)
- FFprobe, libavcodec, libavformat, libavfilter (FFmpeg libraries)
- x264, dav1d, libdvdcss/libdvdnav/libdvdpsi, libspatialaudio, checkasm
- AV1/AV2, Alliance for Open Media, MPEG LA, HEVC Advance, VP9
- ProRes, MOV, MP4, AVI, Matroska (container formats)
- Aegisub (subtitle tool)
- CineForm (codec) and GoToMeeting’s reverse-engineering stories
- FATE (FFmpeg Automated Testing Environment)
- RISC-V, ARM64, AVX/XOP SIMD and other SIMD instructions
- Open-source licenses: MIT, BSD, Apache, LGPL, GPL, AGPL, MPL
- Archival codec FFV1; New Domesday Book (UK archival project)
- Kyber project (ultra-low-latency control) and QUIC
Notable Quotes (verbatim excerpts)
- "FFmpeg is probably one of the biggest CPU users in the world. Everything we’ve just said in the past couple of minutes, every sentence is someone’s lifetime’s work." — [00:02:17]
- "The cone logo is iconic; the cone is the identity of VLC. It’s better than a typical play button; people google ‘cone player.’" — [00:05:35]
- "Talk is cheap, send patches." — [01:36:46]
- "FFmpeg, nothing is beyond our reach." — [04:13:53]
- "Teenagers have written more assembly in FFmpeg than Google engineers." — [01:24:40]
- "Dav1d: 30,000 lines of C, 240,000 lines of handwritten Assembly; every cycle matters." — [02:46:??]
- "The world is a museum of passion projects." — [02:12:??]
Summary Visualizable Notes (Diagrams/Visuals to Recreate)
- A layered pipeline diagram:
- Input (file/URL) -> Demuxer (container parser) -> Codec dec/enc (Video + Audio + Subtitle) -> Intra/Inter prediction and Transform (DCT/IDCT, quantization) -> Color space conversion (RGB <-> YUV) -> Upsampling/Downsampling -> GPUs vs CPU path (checking GPU decodability) -> Display outputs (frame buffer) and Audio outputs.
- A wiki-like map of the FFmpeg/VLC ecosystem:
- Central nodes: FFmpeg libraries (libavcodec, libavformat, libavfilter, libswscale, libdict, etc.), FFprobe; External libraries (x264, dav1d, libvpx, libopus, etc.); VLC core; VideoLAN infrastructure; archivers and archival codecs (FFV1). - Interconnections: sample-based contributions, assembly optimizations, checkasm tests, and cross-project collaboration.
- A licensing decision flowchart:
- GPL vs LGPL decisions based on downstream usage; license compatibility constraints; re-licensing steps across hundreds of contributors; the effect on commercial integration.
Glossary and Definitions (First Appearance in Plain Language)
- Container: A file format that holds multiple streams (video, audio, subtitles) and their timing data; examples include MP4, MKV, MOV.
- Codec: The algorithm used to compress or decompress media data; examples include H.264/AVC, AV1, H.265/HEVC.
- Demuxer/Muxer: The components that demultiplex (split) or multiplex (combine) streams and metadata in a container.
- I-frame / P-frame / B-frame: Types of video frames used in inter-frame compression; IFrames are complete images, P-frames predict from past frames, B-frames predict from both past and future frames.
- GOP (Group of Pictures): A group of frames with a defined sequence structure; determines how often I-frames appear.
- YUV vs RGB: Color spaces used in video; Y (luminance) carries brightness, U/V carry color information; YUV is more aligned with human vision and more efficient for compression.
- DCT / IDCT: Discrete Cosine Transform and its inverse; used to convert image data into frequency components for compression.
- SIMD: Single Instruction, Multiple Data; a CPU feature allowing one operation to process many data points simultaneously; essential for fast video processing.
- FATE: FFmpeg Automated Testing Environment; a large-scale, distributed testing framework to validate FFmpeg across platforms and configurations.
- AV1 / AV2: Royalty-free video codecs developed by the Alliance for Open Media for better compression than older standards; AV2 is the successor to AV1.
- AGPL / LGPL / GPL / MIT / BSD / MPL: Different open-source licenses with varying constraints on distribution and modification; LGPL allows linking into proprietary software under certain conditions; GPL is stricter about derivative work.
- DRM / Backdoors: Security concepts about protecting content and preventing unauthorized access; backdoors refer to covert access points in software.
- ARCHIVING / FFV1: efforts to preserve video data for long-term readability and lossless reproduction; important for cultural heritage and historical records.
- QUIC: A modern UDP-based transport protocol designed for low-latency, secure web communications; central to Kyber’s low-latency approach.
Mental Models and Frameworks
- Binary Star System (FFmpeg and VLC): Two core open-source projects orbiting around shared goals; mutual dependency and collaboration create a resilient ecosystem where changes in one project ripple across the other.
- Open Source License as Social Contract: Licensing choices reflect a community’s priorities about openness, business viability, and downstream usage; re-licensing is a moral and logistical negotiation involving hundreds of contributors.
- Psychovisual Rate-Distortion: The idea that compression should optimize for human perception; sometimes more bits spent on perceptually important details yields better subjective quality than raw mathematical PSNR gains.
- Assembly as an Optimization Art: Handwritten assembly and SIMD are described as essential tools for squeezing out maximum performance in high-stakes, real-time media processing; compilers alone cannot always achieve these gains.
- FATE as Quality Assurance Culture: A distributed, volunteer-driven testing regime across platforms and compilers; ensures FFmpeg’s portability and correctness in the wild.
- Archival-First Mindset: Preservationists and archivists influence codec choices toward lossless or highly stable formats to maximize longevity and readability of media.
- Licensing Strategy as Growth Strategy: Moving from GPL to LGPL can unlock usage in commercial products; licensing decisions are intimately tied to ecosystem health and business models.
- Learn-by-Doing Education in Open Source: The discipline promotes learning through hands-on work (assembly, codec tinkering, platform-specific optimization) rather than purely theoretical study.
Notable People and Roles Mentioned
- Fabrice Bellard: Original conceptual figure behind FFmpeg.
- Michael Niedermayer: Lead FFmpeg developer during the DivX/Xvid era; contributed to diverse codec support.
- Kostya Shishkov: Ukrainian reverse-engineering maestro; contributed essential GoToMeeting and CineForm work.
- Loren Merritt: Key figure behind x264; known for extensive assembly-level optimization.
- Henrik Gramner: Noted authority on Intel x86 assembly (especially in Nordic region).
- Martin Storsjö: Noted for ARM assembly work (Neon) across platforms.
- Dave Rice: Leader in the archiving community; FFV1 and preservation workflows.
The Open-Source Ethos: Why It Works
- Open source thrives on passion and a shared mission: to empower billions of users with robust, accessible technology; it is not solely financially driven, and the community sustains it through volunteer effort, governance practices, and a culture of excellence.
- The conversation emphasizes that good governance, thoughtful licensing, robust testing, and a culture of respect for code quality are what enable these projects to endure, scale, and remain relevant across generations of hardware and use cases.
Takeaways from the Episode
- FFmpeg and VLC are not abstractions but deeply engineered ecosystems where every cycle and every line of code matters; the scale is mind-boggling and humbling.
- The relationship between VLC and FFmpeg is symbiotic; neither can be effectively separated from the other’s success.
- The open-source license and governance models (GPL/LGPL/MPL) are not just legal artifacts; they shape collaboration, business models, and the ability for proprietary software to responsibly integrate open components.
- The world’s video infrastructure relies on people who do not work for big salaries but show up, learn, and ship; the ethos carries both joy and risk (burnout, online drama, etc.).
- The future of multimedia is a tapestry of advances in codecs (AV1/AV2/AVC/VVC), archiving, VR/AR, 3D audio, and even brain-computer interfaces; the infrastructure—FFmpeg, VLC, and allied projects—will continue to evolve to meet those challenges.
Final Note
- The hosts close with a tribute to Linus Torvalds and the larger ecosystem of open source: a reminder that the software we rely on daily is built by people who are driven by curiosity and a love for creating, not by incentives to maximize short-term profit. The end product—FFmpeg and VLC—exists because a community of engineers persisted, collaborated, and refused to quit when work was hard.
"Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program." — Linus Torvalds (closing quote referenced)
Action Items
- Follow FFmpeg and VideoLAN on X (Twitter) to stay updated on developments and community efforts.
- Donate to FFmpeg and VideoLAN to support ongoing maintenance and archival work (FFmpeg/VideoLAN open-source contributions).
- For developers: learn fundamentals of containers, codecs, and demuxers; study assembly basics and SIMD to contribute to performance-critical paths.
- If you manage media infrastructure: consider adopting AV1/AV2 where feasible to reduce licensing friction and improve future-proofing.
- Parents, educators, and students: engage with the archiving community (FFV1, preservation pipelines) to learn about long-term digital heritage and how codecs preserve culture.
- If you’re building products with FFmpeg/VLC: consider LGPL licensing to allow easier integration into proprietary apps without forcing full source-release of the host product; evaluate license implications for your stack.
- For hobbyists: explore FFmpeg’s CLI as a language for multimedia workflows (filters, overlays, transitions) and experiment with sample pipelines to build a deeper intuition for codecs and containers.
- Contribute to open-source security responsibly: advocate for patches, proper disclosure, and funded security collaboration rather than overwhelming volunteer maintainers with generic AI-generated bug reports.
Mental Models
Glossary
- Container
- A file format that holds multiple streams (video, audio, subtitles) and their timing data (e.g., MP4, MKV, MOV).
- Demuxer
- A component that separates the multiplexed tracks in a container so the decoder can process video, audio, and subtitles separately.
- Muxer
- The counterpart to demuxer; combines multiple streams into a single container for storage or transmission.
- Codec
- A coder-decoder; the algorithm used to compress and decompress media (e.g., H.264, AV1).
- I-frame
- An Intra-coded frame; a complete image frame used as a reference for following frames.
- P-frame
- A predictive frame; encodes only the changes from previous frames.
- B-frame
- A bi-predictive frame; can depend on both past and future frames.
- GOP
- Group of Pictures; the sequence structure that defines how often I-frames appear.
- YUV
- Color space separating luminance (Y) from chrominance (U, V) for more efficient compression.
- DCT/IDCT
- Discrete Cosine Transform and its inverse; used to convert spatial data into frequency components for compression.
- SIMD
- Single Instruction, Multiple Data; a CPU feature enabling parallel processing of multiple data points with one instruction.
- FATE
- FFmpeg Automated Testing Environment; a large-scale, distributed testing system for FFmpeg.
- AV1/AV2
- Open, royalty-free codecs developed by the Alliance for Open Media; AV2 is the successor to AV1 with further efficiency gains.
- GPL/LGPL/MPL/MIT/BSD
- Open-source licenses with varying constraints on usage, modification, and distribution.
- FFV1
- A lossless archival codec designed for long-term preservation of video data.
- QUIC
- A modern transport protocol based on UDP designed for low-latency, secure communications; used in Kyber’s approach to real-time streaming for robotics.
Notable Quotes
“FFmpeg is probably one of the biggest CPU users in the world. Everything we've just said in the past couple of minutes, every sentence is someone's lifetime's work.”
“The cone logo is iconic; the cone is the identity of VLC. It's better than a typical play button.”
“Talk is cheap, send patches.”
“FFmpeg, nothing is beyond our reach.”
“Teenagers have written more assembly in FFmpeg than Google engineers.”
“"The world is a museum of passion projects."”
“"Many things in the world only happen because an awesome person decides to do it. This is the case with VLC." - Tim Sweeney (referenced in context)”
“FFmpeg runs on Mars; it is a multi-planetary open-source library.”
Topics
More from Lex Fridman Podcast
See all




