Command for Recording Your Desktop
I don’t want to play with fancy UIs or manipulate a capture while demonstrating something; that’s what post-processing is for. However, I do want something that will remove all the work of getting a desktop recorded.
I have a dual-monitor setup; both monitors are set to 1080p, and the left one is a little larger than the right one. This is, therefore, my chosen monitor for recording my demonstrations. I’ve tried a number of programs to record desktop, but each seemed to be limited, mainly to what UI elements allowed.
On the other hand, the command line tool avconv can do everything those other tools can do, and much more, especially when it comes to video settings. Of course, I only need a certain collection of options; I don’t need everything under the sun.
Before I explain further, let’s get the command out of the way, shall we?
avconv -f x11grab -s hd1080 -r 30 -i 0:0 recording-filename.mov
The avconv command is part of libav, a fork of the FFMPEG software, and is used to convert video and audio from one format to another. However, there’s nothing that says that “one format” can’t be the desktop, and that is what “x11grab” is; the desktop format. Of course, in order to use this, we need to force the program to use it, so that’s the reason for the “-f” switch. To find out what formats are available in your system, type “avconv -formats”.
Theoretically, I can add another -f switch to import Jack audio, thereby recording what I’m saying as well, but I prefer to do audio recording later, once the video recording is complete, so I have room to add commentary and insert visual aids in post, as well as chop up the clip to remove slow elements, and mistakes made in the process of completing the demonstration.
The “-s” switch sets the size of the recording area. Now, I want the entire left monitor to be the recording device; this removes the need to keep windows in a specific space. Since I have a 1080p resolution on the monitor, I use the “hd1080″ size. The available sizes are in the manual page for avconv (“man avconv”), and include “vga” (640×480), “svga” (800×600), “xga” (1024×768), “uxga” (1600×1200), “hd480″ (852×480), “hd720″ (1280×720), and “hd1080″ (1920×1024).
The “-r” switch is the frame rate. Since I intend to produce videos at 30 frames per second, it helps to ensure my recordings are similarly paced. The higher the framerate, the smoother the animation; lower values are fine for simple screen recording demonstrations, but for higher-speed processing, such as “Let’s Play” recordings, you might want to use at least 25 fps.
The “-i” switch tells the avconv program the name of the input file. In this case, however, we give it the DISPLAY name of the X server, which is 0:0, rather than a filename. Because the format was set to “x11grab”, this setting works.
Finally, we give the software the filename to save to.
One thing I want to mention: if you’re doing a screencast, you may want to make the initial recording in Quicktime format; this seems to be the best, since there are none of the artifacts you get with MPEG and AVI recording, and is much better-compressed than lossless formats like HuffyUV.
In Archlinux avconv is in the package “libav” (0.8.3) right now, which replaces the complete FFMPEG package. avconv is not in ffmpeg here.
I stand corrected; apparently, LibAV has branched off away from FFMPEG.
Now, if you don’t mind, I’ll be over there, attempting a pedvorectomy.
Any hints if x11grab is not available on my system?
Try the following command at a command line:
“avconv -formats | grep x11″
Now, if you have the x11grab format in your copy of libav, then the following line should appear:
“D x11grab X11grab”
The “D” simply means that libav can read (decode) the format.
That is what I meant in the beginning. x11 is not in the avconv formats list.
This might be a distribution issue; check to see if you have the latest version of your Linux distribution and the latest version of libav. Which distribution of Linux are you using?
That helped me start my first screencast. Thanks. Btw can you elaborate more about various video formats and encoding options. Which is better in which situation. I will mostly upload my screencasts on youtube.
For the purpose of desktop screencasting, the other major lossy formats seem to cause visual artifacts throughout the process of recording, so I will just stick with the suggestion of using Quicktime specifically for this part of the process. For video games and “Let’s Play” style videos, you can probably get away with others.
As for options, it’s always a balance between file size and video quality; the higher the rate, the higher the filesize. The higher the video resolution, the higher the filesize.
Why is filesize important? In a word: Buffering. The smaller the file, the faster it will load in a streaming app, such as YouTube. So you want to have the smallest posssible filesize at the highest possible quality for your final YouTube video.
Now, if you’re doing a tutorial of a GUI application, you can probably get away with a low frame rate, because GUI components are event-driven (as opposed to “realtime”) applications. However, if you’re doing a “Let’s Play” type video, or working with something that uses realtime components (multimedia editing tools) you probably want higher framerate.
To give you a reference, 24 frames per second is a standard feature-film framerate, 25 is a PAL/SECAM TV framerate, 30 (or 29.95) is an NTSC TV framerate. Personal video cameras tend to have even higher framerates.
On the other hand, if you’re doing that “Let’s Play,” you can get away with a lower resolution easier than you can with a desktop tutorial, because the latter tends to require that fonts on the screen are legible to the viewer, while the former likely doesn’t depend on text, but visuals.
One more thing. It is recommended you use the settings that will be used in the final project; any modification in size can result in aliasing, which can reduce the quality of the video.
Thanks ones again for giving an insight into the matter. I am going to do demonsatration of some scientific softwares (eg: autodock, gromacs etc.). I guess I will need about 24-30 fps. Since few visualization software (eg: VMD) are somewhat graphically demanding.
Further, I want to know how can I get audio output from my microphone. I tried “-f jack” but that doesn’t seem to work for me. It gives this output.
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
exec of JACK server (command = “/usr/bin/jackd”) failed: No such file or directory
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
[jack @ 0x9797c80] Unable to register as a JACK client :0.0: Input/output error
Jack is a server; according to the error messages, it seems to not be running, and the server executable (jackd) is not found. This could mean that you don’t have Jack installed on the system, or you’re using a solely DBUS version of Jack, in which case, you need to start it before trying the command.
Hey, so um, how do I get audio of what’s going on, on my PC? As in, desktop audio? Sound from my PC? I don’t want to record my microphone, I want to record audio of the game I’m recording. Ubuntu doesn’t seem to include this as an option by default.
To record audio straight in Linux (such as in the case of a “Let’s Play”), you would simply need to include more -f and -i switches. So, with the above command, it would become something like this: “avconv -f x11grab -s hd1080 -r 30 -i 0:0 -f alsa -i hw:(system hardware device) -f jack -i DesktopRecording recording-filename.mov”.
In this setup, we include an alsa device (it has to be named, the default will fail if your default alsa device is a dmix device) to record the desktop audio (including any game audio), and we also have a link to Jack (called “DesktopRecording” in this example) so you can include your microphone input.
Keep in mind, however, that the result will need editing badly; the audio and video will not be synchronized. The key to fixing this is to make sure you have a synchronization event on your screen which matches an isolated sound. This can be as simple as sending a chat message which will usually make some kind of sound effect.
I hope this helps!
I’ve been experimenting with avconv and ffmpeg, and find that ffmpeg seems to use slightly more resource (lags other software more), but avconv records the audio several seconds out of sync with the video (something I don’t see with ffmpeg).