Friday, 1 August 2008

Making Good Screen-casts - How To?

I am gradually making some screen-casts for echo tutorials and I wonder what is the best way to make them. There is a lot of options and one needs to choose... What I've done so far is available on my Fedora People page.

First thing to choose is the application that will do the actual screencast. From rough investigation I discovered these three that are available in fedora/livna:
  • instanbul - easy to use, however almost non-existant configuration, output compressed terribly much, which makes the video small but ugly
  • xvidcap - configuration options are pretty good, you can customize the output as much as you want, however tend to freeze during captioning, also does not support encoding to theora
  • gtk-recordMyDesktop - seems to support output only to ogv/theora/vorbis, not very well handled area selection, adds skeleton track to the output, usage not very intuitive
So after some thinking I dismissed instanbul, as the output does not have the desired quality (and I cannot do anything about that) and xvidcap due to frequent freezes (before that I managed to record one 3 min long screencast though). That leaves gtk-recordMyDesktop.

Next, we need to decide about the content - will we add commentary? If yes, will it be spoken or via subtitles? Subtitles are very good for translating, you just use the original one and use e.g. subtitleeditor (in fedora repos) to make a translation without changing the subtitles timing/styling. Also it's good for deaf people. On the other hand, you need to show the subtitles somewhere, which might render the part of screen on which they are shown unreadable. You can minimize the costs by using styled subs (e.g. ASS/SSA) to position the subtitles, but you'll then need special programs that can handle the styling (e.g. mplayer with -ass option).

Audio has the drawback that it can be hard to understand, for the person doing the screencast harder to create (not all of us are good English speakers), also it's harder to make a translation. So I guess subtitles are overally a better choice.

Now what format choose for video? If I had a choice, I'd go with MPEG-4/AVC (H264) which is excelent format with probably the best quality to compression ratio (and is pretty much used for most of HDTV content). It has however a drawback of being patent encumbered which renders it not an option for videos targeted on all Fedora users (even though you can play it in Fedora if you install additional codec packages from livna, but that's not an official Fedora repository). Software patents also put out of the game most of the other codecs, which leaves Theora. It has pretty good quality to compression ratio and is already the output of the gtk-recordMyDesktop, so if you are content with the compression, you don't need to recompress/re-encode the video.

Lastly we need to choose a container format. In opensource world the best choices are probably OGG/OGM/MKV (listed in no order). I don't know if OGG can handle subtitle tracks and OGM seems to be rather hack of OGG to better support videos. It's not much widely used either. On the contrary Matroska Video (mkv) is designed to be portable, fast, open, ... It can contain almost anything which renders it almost ideal container for shipping videos (it can contain multiple video, audio, subtitle tracks, fonts, various other files..., and yet it's generally very fast). It also comes with handy tools that makes adding new subtitle or audio track to existing video a piece of cake [mkvmerge(-gui)].

So what's my choice? It's obvious from the previous text:
  • gtk-recordMyDesktop
  • Theora
  • ASS/SSA subtitles
  • Matroska Video (mkv)
  • (optionally Vorbis audio)
What do you think? Do I have even better choices?

8 comments:

JonRob said...

We've been using Istanbul and Theora with audio for Fedora TV, but your post is insightful and will cause me to do some further thinking :)

Although the quality from Istanbul is limited, even if I view in full screen what is happening is clearly understandable, but perhaps the needs of the art team are for higher definition.

Please keep posting your progress, and consider sharing these videos in Fedora TV? fedorahosted.org/fedoratv to share a video with us.

Martin said...

Not necessarilly, but it's always more convenient if you can read the text in video easily, compared to slight difficulties when recorded via istanbul. But I can imagine cases where the quality might be even more important than that (like tutorials for using gimp filters, etc.).

I'll submit the videos for Fedora TV when they are in good-enough shape. I am also considering using chapters to divide the video into sections (AFAIK both OGM and MKV support chapters, though the ones in matroska are much more robust)...

Also, once I handle the creation process, I plan to write a tutorial to record the steps I'll use for the creation (from the initial recording, to the final output, maybe also with a short notice about how to get it into Fedora TV).

jldugger said...

https://wiki.ubuntu.com/ScreencastTeam/RecordingScreencasts has some good guidelines and advice, down to concrete tools. If you haven't read it, it might be handy.

One neat suggestion is a VM for consistency. I don't, but I also don't contribute Tutorials to the Screencast team. I find it incredibly hard to actually speak on queue to a recording with no human interaction, and that's probably why so many Linux podcasts are two person teams.

The wiki page is Ubuntu specific, but it's also CC-by-sa so you know, liberate as necessary.

jldugger said...

Corey Burger is telling me now that our wiki is "public domain". The invitation to liberate still applies ;)

Martin said...

jldugger, thanks for the tip, I'll check it out :-)

Paul W. Frields said...

Some of the istanbul options, like the video framerate, are only exposed in GConf. You can install the gconf-editor package to get at them, or use gconftool-2 at the prompt. (More of these need to be exposed, I agree!)

nicu said...
This comment has been removed by the author.
nicu said...

@paul: it is not about the frame rate but compress ration, which isn't exposed anywhere.