FFcast helps the user interactively select a screen region and hands over the geometry to an external command, such as FFmpeg, for screen recording.
FFcast 1.0 is rewritten from scratch, and incompatible with the 0.x series.
A common problem with many command line screencast tools is that there’s no easy way to specify the screen region the user wants to record. Such tools require the target region geometry to be specified in numbers. Due to the limitations of the human eye and brain, we can’t usually translate a region on screen into numbers instantly or precisely. This is where we need some graphic interaction. This is where FFcast comes in.
FFcast prompts the user to interactively select a screen region and instantly knows the geometry of it. Then, FFcast replaces the placeholders in the screencast command line with the geometry parameters and executes it.
The placeholders are implemented as basic format strings. The format strings
%Y are replaced with the width, height,
left-, top- right- and bottom-offset of the selected region, respectively;
%d is replaced with the
DISPLAY environment variable. A literal
be escaped as
%% where necessary.
The following is a basic FFmpeg command line using this syntax:
ffcast [...] % ffmpeg -f x11grab -s %wx%h -i %d+%x,%y -vcodec libx264 cast.mkv
There’s an alternative, convenient syntax which supports a limited set of
recognized screencast commands. It uses
-- as the placeholder for the
predefined command-specific, geometry-related parameters.
ffmpeg is one of
the recognized commands; the command line above can be equivalently specified
in this syntax as follows:
ffcast [...] ffmpeg -- -vcodec libx264 cast.mkv
-l option lists all recognized commands for this syntax.
xdpyinfo - for the -x option
xrectsel - for the -s option (included)
xwininfo - for the -w option
Git repo: git://github.com/lolilolicon/FFcast2.git
Examples are always most helpful to get you started.
Start fullscreen capture. In this simplest form, where no region-selecting
argument is passed, FFcast selects the root window and passes its geometry to
q to end recording. The output file is named
You will be asked to select a region using mouse, then FFmpeg starts recording the selected region.
ffcast -vvs ffmpeg -r 25 -- -f alsa -i hw:0 -vcodec libx264 cast.mkv
Debug is turned on by
-vv. You will see in the debug output the FFmpeg
command line that’s called. Notice that
-- from above is replaced with the
x11grab input options, and other options are unchanged- That’s indeed what
You will be asked to first select a window by mouse click, and then a screen
region by mouse. The recorded region is the region selections combined by
union. Indeed, you can pass any number of
-s. This can in
particular be very helpful for recording multi-window applications, such as
xrectsel, respects the
variable. The above records the whole screen of display
:1. This is useful
when you run a nested X server with
Xephyr and want to record stuff inside
ffcast -w recordmydesktop -- -o cast.ogv
An example of using an alternative recording command,
You will be asked to select a window, and then rmd is called to record it.
The magic, again, is FFcast injects the
-height options into the rmd command line, replacing the first occurrence of
-- can also be omitted, since FFcast by default injects the
geometry options right after the screencast command. Use
ffcast -l to get a
list of supported screencast commands.
ffcast -w % echo %wx%h+%x+%y
This uses the format string syntax. Any arbitrary command can be used in this
syntax. The command will print the geometry of the selected region, similar
but not equivalent to the
-p option; they are different in that the geometry
parameters passed to
echo are sanitized to be divisible by 2, which is not
done with the
The following talks about the convenient
Many of the options are removed, and the code is considerably simplified and more readable. But the most significant change is that now the user can pass any valid argument to FFmpeg- FFcast will never touch FFmpeg’s options other than the x11grab input ones (which is the point of FFcast). The implication of this is that, for example, you can easily pass audio input options to get audio recording- a feature widely expected yet hard to implement/maintain.
The reasoning is that FFcast should not know anything about FFmpeg except for what it must know. In other words, I will not maintain the FFmpeg’s crap, it’s the user’s responsibility to keep up with whatever FFmpeg changes. In other words, FFcast doesn’t hold the user’s hands but gives him/her all the control. Whatever works for you ;). The part FFcast does touch, however, is the x11grab input options- currently something like this:
-f x11grab -s 600x400 -i :0.0+100+100
Users switching from 0.x can safely remove the old config file, now that no config file is used by FFcast.
Also changed is the
xrectsel program. It now supports several format
strings. They are
the source code for details.
Originally, Michal Witkowski (Neuro) posted
“x264 Lossless Screencast Script” at ArchLinux forums. I then went on and
heavily modified and extended the script, and finally released FFcast 0.x.
The idea behind Neuro’s script was to parse the
xwininfo output and pass it
to FFmpeg, so you can easily record a window by simply clicking it. I liked
it, and naturally linked the behavior with the screenshot application
I wanted to find a way to select an arbitrary screen region for capture.
I went on to look at the scrot source code, as well as post a topic
asking for help. HashBox was very kind to post his code and even clean it up
for me- I finally combined what I got from scrot and HashBox’s code and put
xrectsel.c. All was looking good to me.
But obviously I was misguided to think it’s a good idea to take control of all
the irrelevant FFmpeg options and added even more (like
-t). And then
people came to me and complained that FFcast didn’t do sound recording.
I at first still thought I should implement it, but then found that we simply
couldn’t- with all the sound systems out there, there’s no easy way to
determine the sound input device in the first place. I could have added some
options in the config file and whatnot, but I knew I was on the wrong track,
so I did nothing.
After a long time, a thread at ArchLinux forums reminded me of FFcast and the painful fact that it sucked. I then sat down, opened the script, and didn’t read much before I started to write prototype code for FFcast 1.0. The next day, FFcast2 (i.e., FFcast 1.0) was announced at ArchLinux forums.