FFmpeg filter graph by Ciro Santilli 40 Updated 2025-07-16
Filter graphs are a thing of great beauty. What an amazingly obscure domain-specific language, but which can produce striking results with very little!!!
ffplay -autoexit -nodisp -f lavfi -i '
sine=frequency=500[a];
sine=frequency=1000[b];
[a][b]amerge, atrim=end=2
'
which creates a graph:
                              +--------+
[sine=frequency=500]--->[a]-->|        |
                              | amerge |-->[atrim]-->[output]
[sine=frequency=1000]-->[b]-->|        |
                              +--------+
and plays 500 Hz on the left channel and 1000 Hz on the right channel for 2 seconds.
So we see the following syntax patterns:
  • sine, amerge and atrim are filters
  • sine=frequency=500: the first = says "araguments follow"
    • frequency=500 sets the frequency argument of the sine filter
    • for multiple arguments the syntax is to separate arguments with colons e.g. sine=frequency=500:duration=2
  • ;: separates statements
  • [a], [b]: sets the name of an edge
  • ,: creates unnamed edge between filters that have one input and one output
A list of all filters can be obtained ith:
ffmpeg -filters
and parameters for a single filter can be obtained with:
ffmpeg --help filter=sine
Related question: stackoverflow.com/questions/69251087/in-ffmpeg-command-line-how-to-show-all-filter-settings-and-their-parameters-bef
TODO dump graph to ASCII art? trac.ffmpeg.org/wiki/FilteringGuide#Visualizingfilters mentions a -dumpgraph option, but haven't managed to use it yet.
Bibliography:
Computer programming by Ciro Santilli 40 Updated 2025-07-16
Programming is hard. To Ciro Santilli, it's almost masochistic.
What makes Ciro especially mad when programming is not the hard things.
It is the things that should be easy, but aren't, and which take up a lot of your programming time.
Especially when you are already a few levels of "simple problems" down from your original goal, and another one of them shows up.
This is basically the cause of Hofstadter's law.
But of course, it is because it is hard that it feels amazing when you achieve your goal.
Putting a complex and useful program together is like composing a symphony, or reaching the summit of a hard rock climbing proble.
Programming can be an art form. There can be great beauty in code and what it does. It is a shame that this is hard to see from within the walls of most companies, where you are stuck doing a small specific task as fast as possible.
.data is section 1:
00000080  01 00 00 00 01 00 00 00  03 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 02 00 00 00 00 00 00  |................|
000000a0  0d 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  04 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  • 80 4: sh_type = 01 00 00 00: SHT_PROGBITS: the section content is not specified by ELF, only by how the program interprets it. Normal since a .data section.
  • 80 8: sh_flags = 03 7x 00: SHF_WRITE and SHF_ALLOC: www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#sh_flags, as required from a .data section
  • 90 0: sh_addr = 8x 00: TODO: standard says:
    If the section will appear in the memory image of a process, this member gives the address at which the section's first byte should reside. Otherwise, the member contains 0.
    but I don't understand it very well yet.
  • 90 8: sh_offset = 00 02 00 00 00 00 00 00 = 0x200: number of bytes from the start of the program to the first byte in this section
  • a0 0: sh_size = 0d 00 00 00 00 00 00 00
    If we take 0xD bytes starting at sh_offset 200, we see:
    00000200  48 65 6c 6c 6f 20 77 6f  72 6c 64 21 0a 00        |Hello world!..  |
    AHA! So our "Hello world!" string is in the data section like we told it to be on the NASM.
    Once we graduate from hd, we will look this up like:
    readelf -x .data hello_world.o
    which outputs:
    Hex dump of section '.data':
      0x00000000 48656c6c 6f20776f 726c6421 0a       Hello world!.
    NASM sets decent properties for that section because it treats .data magically: www.nasm.us/doc/nasmdoc7.html#section-7.9.2
    Also note that this was a bad section choice: a good C compiler would put the string in .rodata instead, because it is read-only and it would allow for further OS optimizations.
    • a0 8: sh_link and sh_info = 8x 0: do not apply to this section type. www.sco.com/developers/gabi/2003-12-17/ch4.sheader.html#special_sections
    • b0 0: sh_addralign = 04 = TODO: why is this alignment necessary? Is it only for sh_addr, or also for symbols inside sh_addr?
    • b0 8: sh_entsize = 00 = the section does not contain a table. If != 0, it means that the section contains a table of fixed size entries. In this file, we see from the readelf output that this is the case for the .symtab and .rela.text sections.
Eli Benderski by Ciro Santilli 40 Updated 2025-07-16
Amazing systems programming tutorials. Whenever you Google a hard topic, his blog comes up.
Also has many great contributions on Stack Overflow: stackoverflow.com/users/8206/eli-bendersky
As of 2016, Eli worked at Google (reference). TODO before that, I had found his earlier info previously but lost it.
Eli focuses mostly on compiler toolchains.
If we didn't have GUIs, terminal multiplexers would be our desktop environments. E.g. they handle stuff like:
  • window switching
  • copy pasting across windows
  • screen locking
  • clock on the status bar (same one that holds tabs)
It is a thing of beauty.
GNU screen by Ciro Santilli 40 Updated 2025-07-16
Most important things to know:

Pinned article: Introduction to the OurBigBook Project

Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
We have two killer features:
  1. topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculus
    Articles of different users are sorted by upvote within each article page. This feature is a bit like:
    • a Wikipedia where each user can have their own version of each article
    • a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
    This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
    Figure 1.
    Screenshot of the "Derivative" topic page
    . View it live at: ourbigbook.com/go/topic/derivative
  2. local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:
    This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
    Figure 2.
    You can publish local OurBigBook lightweight markup files to either https://OurBigBook.com or as a static website
    .
    Figure 3.
    Visual Studio Code extension installation
    .
    Figure 4.
    Visual Studio Code extension tree navigation
    .
    Figure 5.
    Web editor
    . You can also edit articles on the Web editor without installing anything locally.
    Video 3.
    Edit locally and publish demo
    . Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.
    Video 4.
    OurBigBook Visual Studio Code extension editing and navigation demo
    . Source.
  3. https://raw.githubusercontent.com/ourbigbook/ourbigbook-media/master/feature/x/hilbert-space-arrow.png
  4. Infinitely deep tables of contents:
    Figure 6.
    Dynamic article tree with infinitely deep table of contents
    .
    Descendant pages can also show up as toplevel e.g.: ourbigbook.com/cirosantilli/chordate-subclade
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact