Blog Tags: 

Screencast production: Lessons learned from the making of my first screencasting

Introduction

The following post summarizes the lessons I learned from my first serious Linux screencasting attempt, which was also my first foray into the world of open source audio video editing.

The first thing you need to know about screencast production, is that like pretty much anything worth doing, doing at a high level of quality is harder than it looks.

This is especially true if you are using only free tools. One of the main problems I faced is that audio video editing has relatively weak free software coverage. That isn't for lack of free software in this area. It's just that most of it is incomplete, extremely buggy crap.

My theory is that the reason for this sorry state of affairs is that video editing is a rather specialized difficult field with high barriers to entry that doesn't really appeal to a lot of hackers for some reason.

Fortunately, I did manage to find enough software that was good enough to get the job done.

My first screencast

Starting from the end, the result of my work was a 10MB (275 kbps) 1024x768 streaming video running about 5 minutes, encoded with H.264 and MP3. This public copy was generated in turn from a 1GB master encoded with lossless codecs FFV1 and WAV, which was in turn generated from a 4GB workprint.

Getting it short and maximizing the information density was a major challenge and increases the amount of work dramatically.

This kind of production can be a massively labor intensive process.

Behind every second published is about 200 seconds of work, and this is after you climb the learning curve. In other words, 1 minute of video can equal about 3 hours of work. Of course, if you're willing to compromise on quality you can skip most of the effort but unless you have some sort of innate genius for this stuff the result will probably suck.

Major challenges

  • Keeping it short: most screencasts should avoid going over 5 minutes. Short attention spans are the norm these days.

  • Acting: When you are "shooting" a screencast you are usually acting out a script. I'm guessing this still isn't remotely as hard as "real acting" where you have to remember your lines and express emotion but getting even simple acting right can still be surprisingly difficult. At least it was for me.

    Again, this is more difficult if your goal is to execute a complex series of actions fluidly and with no obvious mistakes. It's sort of dance in that respect.

    Narrating is also difficult, especially with non-professional equipment. You have to write a clear expressive script, perform it in a friendly conversational tone, and pronounce all of the words right.

    Frankly it would have been impossible for me to do both at the level of quality I wanted at the same time, in realtime, but it's still a challenge even when you do the narration separately.

  • Unreliable tools: I experiencing serious failures (frequent crashes, corrupt output files) in EVERY tool I used.

    • xvidcap can crash unpredictably during capture. Even when it doesn't crash capture may be corrupt.
    • audacity crashes during editing, especially if you open too many editing windows. It has a crash recovery feature but sometimes incorrectly delete parts of your audio when it "recovers".
    • avidemux can go haywire and executes your edits incorrectly.

Walkthrough of the screencasting process

1) Setup

Install software: You first have to setup your toolset (audacity, xvidcap, ffmpeg, avidemux).

Create screencasting environment: I didn't want the screencast to show all the peculiarities of my work environment (e.g., filesystem contents, virtualbox machines, browser bookmarks and extensions, etc.) so I started fresh by creating a new demo user just for that.

2) Rehearsal

This is where you walk through the various things you would like to show while thinking about what you want to communicate.

Tips:

  • Try to logically segment the action into easily defined scenes
  • Write an outline of the script

3) Shoot video

You shoot the video at the highest possible quality. Flash Video Screen is lossless but the captured frame rate is poor. MP4 at the highest quality settings has a slightly lower picture quality but the frame rate is much better.

You're not trying to get things perfect and with the correct timing because that's very difficult.

Instead you want to shoot in a way that allows you to redo bad parts and cut out mistakes later in editing without having to start over.

The trick is to remember the approximate mouse position at the beginning of a scene (e.g., middle of the screen) and if you want to start over just bring the mouse back to that location and redo it.

Pausing: Pause as much as you want if it helps you think things through. That can be easily edited out and it seems to work better then trying to rush through everything.

xvidcap complicates things with it's tendency to crash unpredictably.

To get around this every so often I make note of the mouse position, stop capture, and click on the next button to start recapture in a new file (e.g., take-0002.avi instead of take-0001). I then return the mouse to the original position and when I stitch the files together I will edit out the connecting tissue so it looks like one smooth seamless video.

4) Convert captured video to workprints

To edit the video in avidemux you'll want to use ffmpeg to convert the raw footage into a fast, lossless format with no key-frames such as FF HuffYuv (ffvhuff):

		ffmpeg -i path/to/file.avi -vcodec ffvhuff hugefile.avi

This allows you to edit with frame precision and save as many times as you want without loosing any video quality in the process.

The trade off is disk space, and at a 114Mbps bitrate (14MB/s) you'll need lots of it. 1 minute equals 860MB.

5) Edit the workprint

In a nutshell you use avidemux to:

  1. stitch the pieces together to create the illusion of one seamless video.
  2. cut out the bad parts / retakes but don't cut out pauses yet, they'll be useful during audio/video synchronization.

A big gotcha is that Avidemux doesn't provide an Undo and is easy to make serious mistakes in so you'll want to save frequently. Avidemux allows you to save your edits in a "project" file (basically a script that records your actions) but sometimes this doesn't seem to work very well so you will want to save your progress by actually saving your edits into a new video which will take a while but is still much faster with FFVHUFF than with other formats (e.g., especially in "Copy" mode).

6) Script "narration"

This is the part where you play back a section of the video, pause it and then write down notes on useful things you would want to say. Rinse, repeat. Then you translate your notes into a script that doesn't sound too contrived.

At the beginning you may want to introduce yourself and provide a short overview of what you are going to show, to prime the expectations of your viewers, motivate them to see the entire video and make it easier for them to follow you.

Of course, there are many ways to narrate a screencast. The natural tendency is to grunt your way through it while thinking out loud, but I think it's best to make the most of the audio channel to add:

  • audio titles: a spoken summary of what you are doing or going to do. Of course, the user has eyes so you don't have to replicate the information, but it does help to set the context up and help him interpret what they are seeing.
  • provide useful commentary and insights that you think would help users "get it".

7) Record narration

Naturally, you'll want to start with a sound test. Especially if you're using amateurish equipment.

For best results, don't try to do this while watching the video, and forget about timing issues altogether. Just focus on reading the narration script in a natural, friendly tone.

Tips:

  • Don't start over: If you make a mistake, or don't like how something sounds don't worry about it, just pause and continue and redo it. It's easy to edit out the mis-steps later.

  • Speak in a consistent tone and volume unless you want the listener to start noticing the characteristics of your voice, and usually you just want them processing what your saying without any distractions.

  • Pause and breathe:

    This may sound trivial but if you forget to breathe your voice won't sound as good and you will eventually run out of breath.

    Also, audio is easier to edit when there are pauses between sections because you can identify that in the graph of the waveform.

  • Try to do it in one take.

    Especially if you're using unprofessional equipment.

    I use headphones and every time I took them off and put them back on the positioning of the microphone was a bit different and my voice sounded different.

    Also at different times you'll likely be in a different mood and this too can effect how your voice sounds.

    BTW, I discovered this a bit late and so I think it's possible to make out the different sections in the video.

8) Video/audio syncing

How long it takes: doing this right is a significant amount of work. Once you get the hang of it, expect this to take 20-30 minutes per minute of synchronized video.

Order: you start at the beginning of the audio/video, and work your way gradually through the soundtrack and video track until you reach the end. Doing it in a different order can screw up your synchronization and you'll have to redo it or at least check that it still works.

Editing primitives: I managed to do all of my synchronization done using only two basic primitives - removing and inserting pauses in the audio and video, in a way that synchronizes key audio landmarks (e.g., the start and end of an audio section or an important part in the middle) to what is happening at same time in the video.

In both Avidemux and Audacity this is easily accomplished, though it is somewhat easier in Audacity because the timeline of audio is a bit easier to visualize (I.e., you can see where a section begins and ends without having to play through it).

Most of the time I just took count of the common timeline counters (e.g., number of seconds since video/audio began) to do this but if you want to actually see and hear the result in progress you can export the soundtrack into wav (takes a couple of seconds) and then tell avidemux to load the track from an external file.

I didn't do that very often though and in some cases it shows but usually I didn't need to.

9) Audio cleanup

Played with a lot of options (including the Audacity CleanSpeech chain). Noticed that heavy processing tends to diminish the quality of the speech so that some parts can become difficult to understand.

In the end, I cleaned up the sound using only two basic Audacity filters:

  1. Noise removal
  2. Amplification

10) Encoding

Use Avidemux to encode as configuring of all the codec options is much easier. By contrast with ffmpeg I always got very high bitrates at a lower quality.

Encoded the master video in lossless FFV1 and WAV codecs. That comes out to 1GB (4:1 compression ratio).

Encoded the published video in H264 and MP3. Note that you will pay for narrower bitrates with a longer encoding time.

H264 configuration options:

  • motion estimation

    • partition decision - 6B (very high)
    • method - uneven multi-hexagon
  • partition & frames

    • check all partition macroblocks and b-frame options
    • b-frame direct mode - auto
  • bitrate

    • depends highly on the nature of the content (e.g., cartoons / screencasts achieve much smaller bitrates for the same quality settings)

    • alternatives methods:

      1. single pass - QQ (average):

        20 is very good 30 is aggressive (no noticeable artifacts)

      2. twopass - average bitrate (e.g., note that this is more of a recommendation than a hard setting. I think the first pass analyzes the variable bit rate for various parts and second pass sets the QQ to line up with your expectations)

Note that the final encoding is very CPU intensive. On my system, utilizing 2 cores the encoding with these settings is 20 fps.

11) Uploading

Blip.tv lets you upload pre-encoded video files directly, bypassing their transcoder. You'll need to repackage the AVI into an FLV file. At the time of writing, Avidemux didn't support H264 in FLV so you'll need to save as an AVI and then use ffmpeg to repackage the stream into an FLV:

		ffmpeg -i path/to/file.avi -vcodec copy file.flv

Comments

OnePressTech's picture

I got to the end of your excellent tutorial (kudos) and then went to look at....hey where's the video!

:-)

 

Cheers,

Tim (Managing Director - OnePressTech)

Liraz Siri's picture

Hi Tim. I started looking into this for a BitKey Kickstarter video, but that turned out to be premature for several reasons. So I've deferred the video, but decided to publish the blog post anyway. :)

Liraz Siri's picture

FWIW, I used pretty much the same technique 5 years ago to create our first screencast:

https://www.youtube.com/watch?v=g-xXHD051eg

Does my voice really sound like that? Sigh. We were all so young back then...

Eric (tssgery)'s picture

I made the switch to Linux for my personal and professional desktop about 10 years ago and haven't looked back, except for one need....   screencasting.

I worked as part of the CTO office for a large software company for a couple of years and was frequently recording little clips to demonstrate features or technology... but could never get it working from Linux as the tools were just too immature to do the recording and editing. As a result, I have to have a windows desktop that I use once a month for about 2 hours.

If anyone has suggestions for a toolchain other than audacity, xvidcap, and avidemux... PLEASE let me know :)

 

 

Liraz Siri's picture

Editing video with free software is not what I would call by any stretch easy. For what it's worth newer versions of Gnome support built in screencasting capability, though to edit you would still need a video editor. I was secretly hoping someone out there would enlighten me on an option I had missed. Something equivalent to the video version of Gimp. I was desperate enough to try video editing on my Android tablet.

Dan Dennedy's picture

I use TurnKey Linux for hosting my open source software projects that makes video tools for Linux (and now more). Both Kdenlive and Shotcut use ffmpeg to record the screen and offer editing tools. I am lead dev of the engine for both of those (MLT) and lead dev of Shotcut. I think Kdenlive is launching ffmpeg command line tool for recording, and that can be a little brittle based on your versions, ffmpeg vs. avconv, changes in command line options, etc. Then, for editing, Kdenlive can have a fairly steep learning curve, but not as bad as some other tools of its caliber. Shotcut is simpler (but also more limited), uses ffmpeg lib API for capture, and provides controlled up-to-date binary builds so there should be less brittleness. I use Shotcut to make the Shotcut video tutorials (dogfooding). There is a caveat on usability here: Shotcut is based on the simple usage pattern of open/view it, then do something with it. Seems reasonable, doesn't it? Well, same goes for screen recording. First, you open the screen (File > Open Other > Screen), then you record it (Encode > Preset > Capture). I use the lossless/HuffYUV preset. Both tools let you choose a file format. I hear another tool people use for recording is Kazam, but it is not an editor.

Liraz Siri's picture

Hi Dan,

Thanks for recommending I give these projects a try. I'll definitely be doing that for my next video editing project. Nice to see that open source / free software making strides whenever I'm not looking. :)

Cheers, Liraz

Christian Linhart's picture

Hi Eric,

I understand your frustration. If you use tools for your work, then these tools should just work, so you can concentrate at the things that you really want to do.

If commercial alternatives are OK for you, you can try DemoRecorder ( demorecorder.com ) for screen recording under Linux.

It uses a mature recording technology, even if the GUI looks outdated. And you get support and bugfixing service if needed.

Hope this helps,

Chris

P.S.: I am the author of DemoRecorder.

Liraz Siri's picture

Hi Chris,

I'm curious, how did you run into my blog post? By chance or do you use a service that notifies you of relevant new posts (e.g., ala google alert). I'm thinking of experimenting with something like that myself, to be in the loop when people mention TurnKey.

Cheers, Liraz

Christian Linhart's picture

Hi Liraz,

I used blogsearch.google.com to search for "linux screen recorder" or something similar for getting an idea what people currently think about screenrecording under Linux, and what are their wishes and frustrations. My goal was to get ideas where to focus development and marketing on. I got the idea for this kind of research from Perry Marshall's 80/20 book.

You can get ongoing notifications like these with google alerts.

Many years ago I have set up alerts for keywords like these on Google Alerts and I was more active in blogs and forums. ( I have stopped this at a time where I had serious time constraints so I could not continue that. )

So yes, I can recommend using Google Alerts for what you want to accomplish.

Cheers, Chris

Liraz Siri's picture

I'll take another look at Google Alerts. If I react to incoming alerts impulsively it will probably be too distracting. Instead I think I'll try setting up a mail filter that files the alerts away and then batch going over them every once in a while. Batching is great. I picked that up when I read High Output Management by Andrew Grove (Intel President)

Vernessa Taylor's picture

Hi Liraz,

You laid out your process neatly. Like Tim, I was looking for the video at the end. I could almost feel your fatigue as well as joy at a job well done. LOL

My first foray into screencasting on Linux for real was a lot like yours: painful. 

A few years back (maybe 5) my toolchain was a combo of a commercial video capture product, PowerPoint and some open source tools (Avidemux, FFMPEG) to polish it off.  It was too long by today's standards (9min instead of 5min) and didn't have any audio.

(It was a screencast on a feature of the Magnify.net platform. The Support folk over there were impressed with it and used it in their actual helpdesk/tutorials for their own customers. That made me feel like it was well worth the many hours that went into developing it, even though I didn't create it for them!)

Lately, I've used some of the SaaS screen recording options (Screencast-o-Matic, Screenr, etc.) but was ready to bring this back in-house. After quite a bit of research, I was cautiously happy to find a distro dedicated to all things audio and video: AV Linux. Its got some neat, well-maintained audio tools and video tools -- the lineup of tools has increased and those out there are really maturing.

Right now, AV Linux distro fills a gap; I'm giving it a whirl. Kdenlive, mentioned by developer Dan Dennedy above, is one of the tools included. And I've installed ShotCut just today :) (Small world.)

Website for AVLinux – bandshed.net/AVLinux.html

Wishing you success on your next "foray."

Felix Wolfsteller's picture

Just for the "records" :) I use recordmydesktop (to be concrete, the gtk-variant gtk-recordmydesktop - Ubuntu) and are quite happy with it. Its simple and reliable. Of course the editing has to be done seperately. Thanks for the article.

Elanthendral's picture

Thanks for sharing the details and explanations..I want more information from your side..I Am working in Erp Development Companies In Indiashould you need for any other clarification please call in this number.044-6565 6523.

Pages

Add new comment