Learn FFmpeg - Core Concepts & Main Architecture

#Introduction

After understanding FFmpeg's history and reason for existence in episode 1, in this episode we break open the machine behind its commands. Many people memorize FFmpeg options without understanding its architecture, so every command feels like an unpredictable magic spell. This episode changes that.

First, understand one big sentence: FFmpeg is not one program, but a family of interrelated components — three frontend programs and a set of core libraries. Once you understand this map, all of FFmpeg's options will fall into their places.

#The Three Main Components

When you install FFmpeg, you actually get three binaries working at three different layers:

Think of it like a production studio: ffprobe is the assistant examining the raw material, ffmpeg is the technician processing it, and ffplay is the monitor where you watch the result. All three share the same libraries, so what you learn in one always relates to the others.

Verify all three are on your machine:

ffmpeg -version
ffprobe -version
ffplay -version

#Core Libraries: The Real Engine

Below the three programs above, there are six core libraries compiled into the ffmpeg binary. These are the "fuel" that determines what can and cannot be done:

When you write ffmpeg -i input.mp4 -c:v libx264 output.mkv, it means: libavformat reads the MP4 container (demux), libavcodec decodes the original codec then encodes with libx264, and libavformat again writes the MKV container (mux). One command, three libraries working in turn.

#Pipeline: Demux -> Decode -> Filter -> Encode -> Mux

This is the heart of FFmpeg's architecture — a production line (pipeline) that media passes through from input to output:

Input ---> Demux ---> Decode ---> Filter ---> Encode ---> Mux ---> Output

Those five stages are the universal language of FFmpeg. Let's break them down one by one with a bakery analogy:

The important thing to remember: you can cut the pipeline anywhere. Without a filter (-vf), the filter stage is simply skipped. With -c copy, decoding and encoding don't happen — data is copied raw directly (we cover this in episode 3).

#Streams and Mapping

A media file is a container holding one or more streams: video, audio, subtitle, and data. When opening an input, FFmpeg gives every stream a layered number — the input index, then the stream index:

0:0  video pertama dari input pertama
0:1  audio pertama dari input pertama
0:2  subtitle dari input pertama
1:0  video dari input kedua

This is the language used by the -map option. For now it's enough to understand the pattern; the detailed use of -map will be broken down in the muxing/demuxing episode. The fastest way to see the streams in a file:

ffprobe -show_streams sample.mp4

The ffprobe output contains complete information about each stream: codec, resolution, fps, and audio channels. Practice reading the following commands — H.264 video 640x360 30 fps and AAC stereo audio:

ffprobe -hide_banner -show_streams -select_streams v sample.mp4

ffprobe -hide_banner -show_streams -select_streams a sample.mp4

#Conclusion

In episode 2, you've broken down FFmpeg's anatomy: the roles of ffmpeg, ffprobe, and ffplay, the role of core libraries such as libavcodec and libavformat, the demux-decode-filter-encode-mux pipeline, and the concept of streams and mapping.

Key takeaways:

• Three components: ffmpeg (conversion), ffprobe (inspection), ffplay (playback).
• Six core libraries, with libavcodec, libavformat, libavfilter being the three most decisive.
• The universal pipeline: Demux -> Decode -> Filter -> Encode -> Mux.
• Video, audio, and subtitle streams numbered like 0:0, 0:1, 0:2 — the language of -map.

In the next episode 3, we start typing real commands: basic commands and transcoding — the ffmpeg -i input output syntax, converting MP4 to MKV and WebM formats, the difference between stream copy -c copy and re-encode, and reading metadata through ffprobe. See you in episode 3!