Screencasts in Ubuntu, part 1: recordmydesktop

[ Thursday, 29 May 2008, Marcin Seredyński ]


It is said that a picture is worth a thousand words, but no one has ever thought about how much an animation could be worth :) If you really want to examine it yourself, you can try to work with screencasts. Recording them in Ubuntu is really simple. However, making a technically advanced screencast can be quite demanding.

By: Marcin Seredyński

Personally for recording purposes I use recordmydesktop, which is very comfortable in use, performs well and has a graphical frontend which makes the configuration process a breeze. To install it with the graphical frontend, just type:

sudo apt-get install recordmydesktop gtk-recordmydesktop

gtk-recordMyDesktop should appear in the Sound & Video menu after the installation. In the main window of the program we can change the image and sound quality and also, we have access to advanced configurations.

gtk-recordMyDesktop

By default, the program will record the content of the whole screen (or of all the screens), but there is a possibility of recording only a selected fragment of the screen. There are two ways to choose this area: by clicking on the window we want to record (Select Window and after that we select the window), and by choosing the area with our mouse pointer on the preview. More precisely, you need to press the right mouse button while the pointer is on the icon in the notification area, next click Select Area On Screen to select the area directly on the screen. When you are ready to record, click Record, or click on the program icon in the notification area.

By default, the program works in two modes (phases):
- in the first one it records uncompressed frames which are simple screenshots, and saves them in the work folder
- in the second one it encodes and compresses the frames of the animation into the ogg/theora-vorbis format

recordMyDesktop-encoder

The split of this process into two modes guarantees the best use of computer memory during the recording. As a result, the recording will be less corrupted and will have less verves caused by omitted frames, compared to a situation when the operating system would “simply”compress the file during the recording (Encode On The Fly). The default settings have their pros and cons obviously, the highest quality of recording is an advantage, but the high memory use of this process is vice (it is all about the recording of the uncompressed frames on the hard drive). The “smoothness” of the screencast is mostly influenced by the first phase of the recording, and its “quality” by the second.

The program has a possibility of recording sound additionally to the presentation with the use of ALSA or OSS. In order to record sound, we have to be sure that the box near the sound quality bar in the main window of gtk-recordMyDesktop is checked. The advanced options of sound recording are available in the Sound bookmark of the advanced configuration window.

Of course, all of the frontend possibilities are accessible from the command line – recordmydesktop. The frontend however offers an easy way to choose the area of the recording (we choose a window or automatically record the whole screen). If we really want to use the command line, the xwininfo command will give us the work area identification and parameters. The addition of the windows frame to the recording needs can be added by using -frame option. Then after writing this command we chose the window we want to record.

Hints and tips, or how you can compile it:

- The best localisation for the work folder is a partition on a fast drive.
-If we don’t want to show our extra desktop effects, it’s better to turn them off for the recording. This will permit the optimization of recordmydesktop by switching on the Full shots at every frame option. [1]
- The reduction of the quantity of recorded frames per second (Frames Per Second) decreases the risk of omitting one of them. Normally, for screencast, 15 frames per second are sufficient. [2]
- The Encode On The Fly option can be helpful only in case of a slow or small hard drive and a fast CPU. In this situation, the recommended settings are 100% for image and sound, because of the higher compression (lower quality in the end) on the CPU.
-Turning on the option Zero Compression will increase the CPU charge during the recording, but it will reduce the necessary disk space for work files. You can see if you can do this on your PC only by testing.
-The decrease of the quantity of bites per pixel from 24 to 16 will decrease the quantity of data by 1/3, but it will strongly diminish the color quality.
-If you define a place and size of the recorded area, you will permit a decrease of the data necessary to be processed, so you increase the smoothness of the recording. Attention: a once defined area won’t “move” with the window, unless …
-“The golden mean” can be a choice of a recorded area with an simultaneous choice of the Follow Mouse option. When this option is checked, the recorded area will follow the cursor. The cursor will always be in the center of this area.
- To see more clearly which area is recorded at the given time, it is good to turn on the Outline Capture Area On Screen option.
-The use of the Quick Subsampling option will strongly increase the speed of the program, but the losses of quality will be very distinct on screens containing clear and sharp signs, ex. in the terminal or in text editors.
- To reduce the loss of quality during the transcoding of the recording for example through YouTube, it is the best to record a window of the same size as the media-player size (for YouTube it is 320×240 pixels)
- In general, I recommend to record at 100% quality, so afterwards you dispose the best material possible for further processing.
-To record the content of open windows drawed by glx (ex. games, screensavers or windows drawn by compiz) it is necessary to check the Full shots at every frame option.

When you start the program from the command line, you will have access to more precise information about the recording itself:

ms@topaz:~$ recordmydesktop -width 800 -height 600 -fps 60 \\
-o screencast.ogg
Initial recording window is set to:
X:0   Y:0    Width:800    Height:600
Adjusted recording window is set to:
X:0   Y:0    Width:800    Height:608
Your window manager appears to be compiz

Detected 3d compositing window manager.
Reverting to full screen capture at every frame.
To disable this check run with --no-wm-check
(though that is not advised, since it will probably produce faulty results).

Initializing...
Buffer size adjusted to 4096 from 4096 frames.
Opened PCM device hw:0,0
Recording on device hw:0,0 is set to:
1 channels at 22050Hz
Capturing!
Saved 417 frames in a total of 420 requests
Shutting down.....
Encoding started!
This may take several minutes.
Pressing Ctrl-C will cancel the procedure (resuming will not
be possible, but any portion of the video, which is already
encoded won't be deleted).
Please wait...
[98%]
Encoding finished!
Wait a moment please...

Done.
Written 12482454 bytes
(12413303 of which were video data and 69151 audio data)

Cleanning up cache...
Done!!!
Goodbye!
  1. If you use compiz or another program “of this type”, recordmydesktop does not have the possibility to “guess”, wheter the screen should take changes, for example while moving windows, or while moving their inside content. Technically speaking,the windows are drawn only in glx and they don’t generate Damage events (informations about the drawn area of the screen). In this case, the program takes screenshots of the whole screen, which means quite a lot of data to process. For example, one frame of a 1280×1024 resolution with a 24-bit depth of colour needs 3,75 mb of disk space. To record with this resolution with a speed of 20 frames per second we need a hard disk capable of writing data with a speed of 75 mb/s. With a 16-bit depth, the requirements drop to 50MB/s. When the system will not be able to do so, it will omit some of the frames. RAID-0 can help us, but this can be risky ;)
  2. With at least 15 frames per second (Hz), the human eye isn’t disrupted by the smoothness of the animation. We can compare: cinema 24 Hz, PAL television (Europe) = 25 Hz + interlace, NTSC television (North America) = 29.97 + interlace, computer games = normally 60-75 Hz or more. You can learn what is interlace from wikipedia.

Some very detailed documentation is available.

As always, feel free to comment my article, because your opinios are necessary, so I can include these remarks in upcoming part/s. Sooner or later, I’m planing to write something about ffmpeg and the possibilities of transcoding that it offers.

Original article in Polish: Screencasty w Ubuntu, cz. 1. The contents of the original article and this translation is licensed under CC BY-SA 3.0.

About the Author

Marcin Seredyński

I consider myself a nerd. I use Vista for my day-to-day job, but it's not that exciting as hacking open source systems in the nights. I'm a fan of free software movement and an avid user of Ubuntu. I' (more...)

New AdTaily ads!

Are you a film buff?

film buffs community, movie recommendations and reviews

RSS: Comments

You can follow the comments to this article through a special channel RSS 2.0 .

Related articles: Ubuntu

 more »

PolishLinux Top Content


Become our fan on Facebook!

PolishLinux.org on Facebook

Follow PolishLinux on Twitter!

Follow polishlinux on Twitter

Google Ads