Creating Screencasts in Linux



Recording screencasts and post-processing them for publishing on sites like YouTube or as HTML5 videos was a tedious and error-prone task for me up until some months ago: Recording software like recordMyDesktop, istanbul or xvidcap didn’t produce good results, if working at all. Video editors like avidemux, cinelerra, kdenlive or kino were lacking important features, had a cumbersome user interface or crashed in the twinkling of an eye.

Fortunately things changed when I discovered that ffmpeg works great for taking raw screencasts and when kdenlive 0.8.2 was released. Kdenlive had always been a promising application: A solid set of features, more than I probably ever need, arranged in a convenient user interface. Yet I was never able to accomplish even the simplest task with it in earlier versions — it almost certainly crashed somewhere in between. This behavior has changed significantly in recent versions – I’ve produced a bunch of videos with it now without a single crash. And from what you can read in the web, this seems to be a common observation. Good work, kdenlive developers!

In the remainder I’ll describe my workflow for producing screencasts for upload to YouTube. It can easily be adjusted for other sites like, vimeo or HTML5 videos.


Please install ffmpeg – any version should be fine and your distribution surely has packages for it. Also install kdenlive, but take care to get version or later. It’s available in Ubuntu 12.04 Precise (universe) or Debian testing for example.

Recording Raw Screencasts

I’ll assume you’re going to record a screencast of a specific application window. Usually you’re able to resize that and it makes much sense to optimize its size for the end presentation. Best results for YouTube are achieved with an aspect ratio of 16:9. Corresponding video sizes are shown in the following table (second column):

Name 16:9 4:3 Bitrate
1080p (Full HD) 1920×1080 1440×1080 8000 kbps
720p (HD) 1280×720 960×720 5000 kbps
480p 854×480 640×480 2500 kbps
360p 640×360 480×360 1000 kbps

Now change the size of the window to record to your favorite size from the table above. One good way to achieve that is to use KWin (right-click on the window title, Advanced, Special Window Settings, Size & Position). You also need to know/change the position of the window. Again, KWin comes in handy:

Remember (or note down) the values and apply the settings. Afterwards it’s time to start recording the screencast.

ffmpeg -f x11grab -show_region 1 -y -r 25 -s 1280x720 -i :0.0+100,200 -vcodec ffv1 screencast.avi

Let’s review all the parameters briefly.

-f x11grab
Enables screen recording.
-show_region 1
Indicates the recording region on the screen. The indicator itself is not recorded.
The video screencast.avi will be overwritten, if it exists.
-r 25
The video is recorded with a framerate of 25 (frames per second).
-s 1280x720
The size of the video. It should correspond to the size you set via kwin above, and ideally also corresponds to one of the YouTube formats in the table above.
-i :0.0+100,200
100,200 is the x,y position of the top left corner of the region to record. This should correspond to the position you set via kwin above. :0.0 tells ffmpeg which display and which screen to record. Normally you can leave it as :0.0.
-vcodec ffv1
A losless, ffmpeg-builtin video codec is used.

Change the parameters as needed (you probably have to change 1280×720 and 100,200 and can leave the rest as is) and start ffmpeg. It will start recording the screencast immediately. To stop recording, hit Ctrl+C in the shell where ffmpeg is running. The raw screencast will be called screencast.avi and can be viewed with e.g. mplayer.

Possibly you have to repeat this step several times to find optimal settings. If the video stutters, record to a faster drive, use a smaller video size or lower the framerate. Don’t use a framerate lower than 25 though. If the video stutters because your hard drive is too slow and you don’t have a faster one, you can also try to use a different codec than ffv1. Try

ffmpeg -f x11grab -show_region 1 -y -r 25 -s 1280x720 -i :0.0+100,200 -b 8000000 screencast.webm

Post-processing for Publishing

A huge topic on its own, so I don’t really want to start writing much here, but just leave a couple of recommendations:

  • If you recorded to .webm above, you can upload the video directly to YouTube
  • If you recorded to .avi with ffv1 codec or if you want to add some background music, effects, title clip etc, I strongly recommend giving kdenlive a try.
  • If you recorded to .avi with ffv1 codec and don’t want to use kdenlive for some reason, you can convert it using ffmpeg on the command line:
    ffmpeg -i screencast.avi -b 8000000 screencast.webm

    The value for -b should correspond to the bitrate in the table above, here 8000000 = 8000 kbps. Now upload screencast.webm.

  • If you’re looking for some background music, is worth a try.

Wondering why this appears on planet KDE? The answer is simple: I want to see more screencasts here! (GSoC/SoK students, I’m looking at you!) 🙂

QML Layers in Marble

KDE 4.9 Beta 1 is about to be tagged soon and so is Marble 1.4 Beta 1. Judging from the current bug reports and my own tests it is pretty stable already; I’m not aware of any major bugs. Still we’re not running short of things to do: There’s Marble Touch for Harmattan (Nokia N9), the to-arrive Marble Touch for Plasma Active as well as the usual development work currently centered around our four students and their projects (Google Summer of Code and Season of KDE).

One of Marble’s strength has always been that the vast majority of all functionality is contained in its library and shared by the two (with Marble Touch now three) applications that are shipped with the project as well as all other applications that embed the library. Given that Marble Touch is based on QML/Qt Components, this implies to expose parts of the API to QML.

The content presented by Marble consists of several layers stacked on top of each other. Usually this is a base map (based on several texture and vector layers), intermediate layers like search results, a route, postal codes, clouds and finally information boxes. Most of them can be configured: The base map is setup by .dgml files and brings it’s own properties that can further be tweaked through e.g. Marble’s interactive legend. Search and routing have their own control fields. Additionally these layers can be managed via the C++ API (and most parts also from QML).

What about postal codes? They’re part of the so-called online services, plugins that download a certain type of data for the currently visible map region and display them. Besides postal codes these can be Wikipedia articles, photos (from flickr), weather status and forecast, recent earthquakes and more. Each of these services provides limited interactivity in the Desktop version, but the QML interface was missing so far. Yet it is quite interesting to access the online service data from QML for those activities that are tightly coupled to them: Weather, Friends and the currently emerging “Around Me” that provides information about nearby places and events.

Today I extended the existing online service framework to be able to provide a QML delegate — pretty similar to a delegate e.g. in a QML ListView. Once the delegate is set it deactivates the QWidget based rendering for the given service. Instead the provided  QDeclarativeComponent is used as a factory to build and destroy QML item instances as needed as well as updating their screen positions automatically. The C++ data model item retrieved by the online service is set as the context object in the QML context of the QML item such that it can easily access its properties by their name. This approach has several advantages: Item culling, filtering and positioning can be done in the C++ part, which is faster, easier and reuses existing code. At the same time the layout can be done in QML, which usually results in less code and easily allows to add animations. And finally QML is great to allow interaction with the content.

For a proof-of-concept I took the existing Weather activity and replaced its C++ rendering with a QML delegate as you can see in the short screencast below (Youtube, direct .webm here). As expected the QML part is short, just 50 lines for the legend on the left and 60 lines for the delegate that renders the weather status icon and temperatures. Adding interactivity (showing details on selection of a weather station, marking stations as favorite) will be similarly easy.

Not everything works great though. The old z-value problem naturally comes up again with the QML weather items overlapping the information boxes (except for the QML rendered legend). This happens because of the different, independent rendering that does not allow to control the paint order. Unless I find a way around this I’ll probably go for replacing the remaining upper layers (information boxes mainly) with QML equivalents as well. That’d mean that the lower part of the layers was rendered by C++, the upper part by QML. On the one hand this sounds sane given that the lower layers need little interactivity, but are performance critical, while the upper ones are the reverse. On the other hand this would break the fine grained z-value control we currently have.


The QWidget based rendering of online service layers in Marble can now be replaced by custom QML delegates (sok-2012-plasma-active branch).



Approaching the World of Tablets


Last week I packaged Marble Touch 1.3.3 for the Nokia N9/N950 and submitted it to the Ovi store. It’ll appear there in the next days. Compared to 1.3.2 there are the usual bugfixes and smaller improvements, but also new features — most prominently support for bookmarks.

In retrospect, I’m pretty satisfied with the choice to base its development on Qt Components. While I still have a lot of ideas for improving and extending it, the plan for world domination now wants me to shift attention towards a different, yet similar topic: Bringing Marble Touch to Plasma Active. Fortunately the Plasma guys were clever enough to develop the Plasma Components with a very similar API, so the initial port was an easy task for this rainy weekend. Marble Touch in master now supports both Qt Components and Plasma Components. It’s not polished yet, font and icon sizes need to be adjusted and most dialogs don’t play well yet, but the core functionality is all there and works happily. I even tested it on Kubuntu Active in a virtual machine.

One of the reasons I worked on this now is to set a solid base for Utku (you may remember him as the author of Marble’s earthquake and opendesktop plugins as well as the map creation wizard) to join me in his Season of KDE project. Great news! I’m sure we’ll have a nicely polished, end-user ready Marble Touch for Plasma Active at the end of the summer 🙂

With the technical and organizational stuff mostly covered it’s back to brainstorming: What use cases do we want to cover on tablets? Routing and navigation are fundamental ones on smartphones. They’re also important on tablets, yet their larger screen and different usage patterns (couch mode, second screen) enable further use cases. So the second part of our motto — “find your way and explore the world” — becomes more important. I’m thinking of showing more details about places (photos, weather, user content) arranged in a convenient way. Furthermore owncloud integration would be lovely to easily share/synchronize your bookmarks, routes and photos across devices. What would you like to see?


Sisyphus Work

The OpenStreetMap database keeps growing nicely. Missing regions are added, details completed and changes to the environment reflected by the very active mapping community.

When using the data — by opening or using applications like Marble — you want to use the latest data that is available. For Marble, this includes the monav offline routing data and the offline search databases. Until the end of last year these two data types were updated by me running a couple of scripts manually, downloading a few dozen gigabyte of raw data and transforming it to the right formats, then uploading the final data (around 12 GB).

Doing things manually is tedious and time consuming, so I ended up regenerating the data rather infrequently (say 2-3 times a year). That wasn’t quite the frequency I’d like to have, so at the end of last year instead of doing another manual round I invested the time (and more, of course) to automate the process. Sisyphus was born and after solving the usual initial quirks it is now converting fresh OpenStreetMap offline data for Marble 24/7 since the start of this year. Thanks to Geofabrik for providing the .pbf data sources and Ben Cooksley helping to setup the KDE servers as needed.

A full roundtrip (converting all regions worldwide) takes 7-8 days currently, so you have the option of updating your offline data quite often now…

In Marble on the Desktop: Routing tab => Configure => Monav
In Marble on the Nokia N900: Main menu => Routing => Configure => Monav
In Marble on the Nokia N9/N950: Preferences => Offline Data


Marble Touch – Approaching the First Release

Over the weekend I’ve been working on the last features and polishing for the first release of Marble Touch (Marble on the Nokia N9/N950) at the end of the month. Things are coming together nicely; the first release will even have a navigation activity and newstuff integration although I originally planned to leave them out for the 1.3.0 release. The latest additions are pretty neat as they help you customize Marble Touch to your needs easily without having to copy things manually via USB. Just open the Preferences page from the main view as shown in this screenshot:

The installation of additional voice navigation speakers is quite convenient: The list of speakers you can select among presents the locally installed ones and those available via newstuff in one common list. If you select a speaker that is not yet available locally, it will be installed automatically for you.

The same feature will be available in Desktop Marble 1.4. Another nice newstuff feature is the installation of additional map themes you might already know from Marble’s KDE Desktop version. In a similar fashion you can use it in Marble Touch:

The last piece missing in the puzzle is the installation of offline data (offline routing and offline search) via newstuff. I hope to get that implemented in the next days. Additionally I plan to do a bit more polishing of the Navigation activity, which currently looks like this:

It’s pretty much set now and just some remaining quirks need fixes: The blue and gray background colors from the oxygen palette don’t fit too well with the Harmattan theme, the offline mode icon in the toolbar is not exactly a toolbar icon, the measure tool borders have pixel errors and the distance indicator font is a bit unreadable against the map background. At least most of that is easy to fix.

If you know Marble on the N900 you’ll notice some gradual improvements to its navigation mode: Besides supporting both portrait and landscape mode the information shown is grouped logically on the N9/N950, making it easier to read while giving you more information at the same time. The two toolbar icons are handy shortcuts to quickly mute voice navigation and toggle offline mode.

GCI Goodies: Favorite weather stations

Earlier I already wrote about some of the nice tasks accomplished by the GCI students for Marble. We’re near the end of Code-In now and thanks to never sleeping Torsten and the busy GCI students an incredible amount of more than 70 (yes, seventy) Marble tasks have been done. Among them are a couple of enhancements to Marble’s weather plugin, all done by Valery Kharitonov: Weather stations from are now displayed among the existing services, weather station data is refreshed automatically after a configurable interval and last but not least you can mark weather stations as favorite and only display those as illustrated in the screenshot below. So go grab Marble from master and have your holiday weather always at sight 😉

This year the GCI rules were changed a bit and filing new tasks was only possible at selected times. This cut off the following tasks that I’d like to see as further extensions of Marble’s weather plugin:

  • Favorite weather stations should show more information than non-favorite ones: Forecast data with icons and a larger icon for the current state
  • The data retrieval logic needs some enhancements for the new favorite mode
  • The plugin should be touch-friendly such that toggling stations as favorite and switching between selection and favorite mode is also possible in Marble Touch.

Of course working on that is not bound to GCI. Anyone with some programming background can work on it and I’d welcome any patches in that direction. Drop by in #marble on freenode or send a mail to if you’re interested…


GCI Goodies: Public Transport Map Theme

Google Code-In is running and we’re busy mentoring lots of Marble tasks. This year we added many data related tasks: Voice navigation speakers for different languages, OpenStreetMap derived map themes, historic map themes and more. Just like last year the results are pretty awesome and a few of the results are already available for public consumption. Earlier today I uploaded the shiny new Public Transport map theme to our GHNS server. The theme was done by Paul Kocialkowski. It uses the public transport (ÖPNV) map created and maintained by Melchior Moos, who kindly allows us the usage within Marble. The map data itself is CC-BY-SA 2.0.

Do you miss your local bus? Please add it to OpenStreetMap. Contributing is easy, see Öpnvkarte for details.

If you’re using KDE 4.5.1 or later with Marble installed, you can install the public transport map theme easily using the “Download Maps” menu entry in Marble. Older KDE versions before 4.5.1 are not supported right now, though if there is a significant number of people who are stuck with older versions for some reasons I can do a version compatible with older versions as well. Please comment in that case.

How would you like your current position?

We’re currently discussing how to give a good visual indicator to users of Marble Touch where their current GPS position is (once it moves outside the visible region of the map). I created a video that shows two possible approaches: The first one (sticky indicator) shows the indicator on the bottom right of the screen and an arrow to point towards it. The second one (moving indicator) also moves the indicator to the nearest border of the screen. Please take a look at the video comparing both and add your comments.

Here are some things to consider:

The sticky indicator has the advantage of a predictable location. Look at the bottom right corner of the map to see the distance to the current position and in which direction it is. A disadvantage is that the distance is measured to the bottom right corner, which is not always intuitive (measuring to the center can be as confusing though). Likewise it’s confusing two see two position indicators when the current position is inside the view. This could be fixed however by hiding the position indicator when the position is visible.

The moving indicator feels a bit nicer as it is just one element and has a visually somewhat more exciting behavior. This could be annoying as well, however. Additionally I’m missing a good idea how to stick the distance label to it (therefore that one is missing in the second part of the video).

Which version to you like better? Which additional suggestions do you have? I’m interested in your opinion!