Architecture of fmedia

fmedia >> Articles >> Architecture of fmedia
by Simon Zolin, Apr 14 2018

This article explains several key aspects of fmedia architecture.



Representation of the code structure at high-level:

This is a simplified diagram that shows several fmedia modules, their dependencies on third-party libraries and software interfaces that connect them to each other. I chose not to include all modules here because this will overwhelm the picture. Instead, I focus on several distinct modules and key aspects. Everything else works exactly the same way.

fmedia is built from 4 source code repositories (fmedia, ff, ff-3pt, ffos) and also has many dependencies on third-party libraries. Splitting by separate repositories is better because "ff" libraries can be reused by any other application, thus leaving "fmedia" the only repository that contains application-specific details and business logic.

ff-3pt repo

ff-3pt repository contains APIs, patches and build scripts for several useful third-party libraries that implement complex algorithms, such as audio processing and data compression. Originally, these libraries have different APIs that are sometimes inconvenient to use, and sometimes they lack support for asynchronous I/O. The APIs, that are shown on the diagram as red boxes, solve these problems as they are compiled into the libraries. This approach allows to throw away the unneeded code during compilation process making the binaries a little bit smaller. But in some cases, to get the job done, the original code must be modified: that's what patches in this repository are for. So, to sum things up: the original code of third-party libraries + additional patches + new compiled-in APIs = smaller binary modules that are easier to use.

ff-3pt repository provides an easy access to third-party libraries via clean API:

ffos repo

FFOS library allows to write cross-platform code for Linux, FreeBSD, macOS and Windows. It contains lightweight interfaces and wrappers around low level system functions, such as memory allocations, file and socket I/O, etc. With FFOS, the code is written once but can compile on any platform: much effort was applied to unify POSIX API and Win32 API into one API which is both simple and efficient. FFOS layer is very thin, and the resulting code produced by C compiler is optimized as if native OS userspace interfaces were used directly ( on UNIX, kernel32.dll on Windows). In other words, FFOS is so fast that the only way to make it faster is by using direct syscall() (i.e. not using libc at all).

FFOS is a fast and independent library for writing cross-platform code:

ff repo

FF library contains functions for a very large set of technologies, from the fast C arrays to parsers of multimedia containers and file archives. Its purpose is to provide an application with an easy-to-use API to work with a given technology. On the diagram, there are interfaces to work with:

FF is based upon FFOS, so its code runs on any platform. There is much more functionality in FF than what's described here, the complete list of features is in README file:

fmedia repo

This is the project repository -, it contains the code of all modules and the supporting files. The list of modules to load and their settings are read from fmedia.conf file at fmedia startup. After the modules are loaded, fmedia executable passes the commands from command-line to core module to start playback, recording or conversion. The core module creates a track and starts the processing. All modules interact with each other through interfaces described in fmedia.h ( file:

On the diagram, the green boxes are the modules binary files:

Configuration and Portability

Another thing that's worth mentioning here is fmedia configuration file, mainly fmedia.conf. This is what it looks like:

mod_conf "#globcmd.globcmd" {
    pipe_name fmedia

mod_conf "" {
    buffer_size 64k
    buffers 3
    # align 4k

    # use direct I/O
    direct_io true

Full version is here:

mod_conf is a keyword that adds a new module with settings. Module names starting with '#' prefix are compiled into Unless the module is in this configuration file, it won't be loaded and can't be used at runtime. And because of this it's possible to re-package fmedia in any way: you can delete all codec modules and remove them from fmedia.conf and you'll have a very small and portable package that you can use for recording into .wav format, for example. Also, this is the one more reason why fmedia uses codecs built by ff-3pt and doesn't use default codecs that are installed with the UNIX OS: it would not be portable. Now fmedia package can be copied anywhere and it's ready to run - this is very convenient!


I hope I explained and showed enough details for a high level overview of fmedia's architecture. If you still have questions, just email me.

Copyright © 2015 Simon Zolin