ScreencastTeam

Differences between revisions 3 and 5 (spanning 2 versions)
Revision 3 as of 2007-01-05 12:49:14
Size: 3507
Editor: 84-45-197-14
Comment:
Revision 5 as of 2007-01-08 09:33:48
Size: 9469
Editor: 84-45-197-14
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
{{{
Note: This team is not yet ready - the team pages have not all been written yet. Please check back in a few days.
= Screencasting how-to =

== Introduction ==

This is how I make screencasts. They come out fairly well. There are of course other ways to make them, this is just the way that I have found is best. You can see some examples of the screencasts I have made with this procedure at http://doc.ubuntu.com/screencasts .

All this was done on an Intel Core 2 Duo PC with 2GB of RAM, running Ubuntu Edgy (6.10) or Feisty (7.04). It is of course possible to do this on a lower spec machine but there may be difficulties on very low spec machines.

The basic procedure (which is covered in more detail below) is as follows:-

=== Dry run ===

 * Start a virtual machine running the operating system and application which is to be demonstrated
 * Go through the software to be demonstrated

=== Live recording ===

 * Start a virtual machine running the operating system and application which is to be demonstrated

{{{ Note: If the demo requires the installation of additional packages then to save time it can be preferable to setup the necessary repositories, download the necessary packages without installing them, then remove the repositories to put the system back to an post-install state. This of course assumes that you want to show how to enable repositories and install software within the screencast. To download packages and not install them use apt-get with the -d option:- apt-get -d packagename1 packagename2 ...
Line 7: Line 25:
= Introduction =
## Describe:
## the teams's purpose and community role
## the team tasks and work
## who might be interested in joining/getting involved with the team
 * Start a recording application to capture the contents of the virtual machine window - with no audio narration recorded
 * Watch the screencast to ensure all is ok
 * Add a 'intro', 'outro' slides to the start and end of the screencast
 * Open an audio recording application and record a narration whilst watching the screencast again
 * Check the audio recording for defects
 * Post-process the audio to clean it up and ensure it's the right duration for the video
 * Combine the audio and video together
 * Check the combined audio/video for errors/glitches/sync problems
 * Encode/compress video to other formats
 * Encode/compress audio to other formats
 * Upload video and audio to hosting provider
 * Upload video to Google
Line 13: Line 38:
This new team aims to produce screencasts for integration with the Ubuntu Documentation. Screencasts are short video clips which demonstrate visually how to do a specific task. The Ubuntu Screencast Team is a part of the [:DocumentationTeam:Ubuntu Documentation Team] The reason for recording a virtual machine rather than the current desktop is to ensure the screencast is showing what a user would see. Most developers (or even experienced users) have additional software installed (such as the video recording application), have customised their desktop, or are running a version of Ubuntu (such as the current development version) which users might be less likely to use.
Line 15: Line 40:
= Contact =
## List the contact information of the team: Mailing-list, IRC channel and Web Forum as they may apply. Provide a link to the Launchpad page as a Team Member list if applicable. Consider how people will get in touch with you based on the contact information you supply.
It also allows for a "gold" build to be kept in a disk image which can be re-used after a screencast is recorded. This means each screencast starts from the same basic starting point of a fresh (new) installation of Ubuntu. If screencasts are made which assume levels of knowledge or that certain software is already installed then it's possible users will get lost or give up when they see that the screencast doesn't match what they see.
Line 18: Line 42:
 * See ["DocumentationTeam/Contact"] for how to contact the team.
 * To see a list of team members or to apply to join the team, visit our [https://launchpad.net/people/ubuntu-screencasts/ launchpad page].
== Preparation ==
Line 21: Line 44:
= Projects =
## List currently the team's current projects and tasks as well as status and contact persons for each one. Make it easy for new people to know who to ask and where to go to get involved with a specific project.
Preparation is the key. Getting the environment setup takes a while, but is worth doing it well because it means the time taken to create each screencast is lower.
Line 24: Line 46:
 * The screencasts which have already been published can be found at [http://doc.ubuntu.com/screencasts the Ubuntu screencast website].
 * A list of new projects can be found at ["/Requests"] - browse through current requests and submit your own on that page.
=== Planning a screencast ===
Line 27: Line 48:
= How to Contribute =
## Describe easy ways to contribute to the team. These should look a lot like the bulleted points on the ContributeToUbuntu wiki page. Link to more detailed subpages as necessary.
==== Subject matter ====
Line 30: Line 50:
If you would like to help out with making screencasts, you're in the right place! Pretty much anything is fair game for demonstrating using this method. Some things are tricky, but can be worked around, and these are detailed under "Technical Limitations" below.
Line 32: Line 52:
This is the procedure for submitting a new screencast:
 1. Visit the ["/Requests"] page and write a specification for your planned screencast. If possible, consult with the DocumentationTeam about which screencasts most need attention.
 1. [:DocumentationTeam/Contact:Contact the Documentation Team] and discuss your specification.
 1. After some discussion, you can go ahead and record the screencast. A guide to contributing can be found at ["/RecordingScreencasts"] (''TODO'').
 1. When you've finished the screencast, upload it to [http://video.google.com Google Video] or [http://www.youtube.com/ YouTube] and let the team know.
 1. The team will then review the screencast and give you feedback. If we are happy with it then we will upload it to the [http://doc.ubuntu.com/screencasts screencast website]!
It can be beneficial to run through the whole screencast without
Line 39: Line 54:
= Launchpad Membership Policy =
## Describe your Launchpad team membership policy here.
==== Technical Limitations ====
Line 42: Line 56:
Anyone can submit a screencast project and make a video for the approval of the team (see above). Our [https://launchpad.net/~ubuntu-screencasts Launchpad team] is made up of the team members who can approve videos. When you've successfully submitted a few videos, you are likely to be invited to join this team! The following might be issues when recording using the method described here:-
Line 44: Line 58:
= Meetings =
## Link to Meeting Agendas and old meeting summaries here.
 * Binary video driver installations - QEMU emulates a simple Cirrus Logic or VESA display, so it's not possible to show it running an ATI/NVidia video driver.
  * This could be overcome by using VNC to control a remote machine which does have an ATI/NVidia chipset rather than using a virtual machine.
 * Showing reboots or switching to the console - the QEMU window changes resolution when the video mode changes - which happens when you restart the virtual machine or switch to a virtual console. If you are recording the window and this happens then your video will capture either:-
  * Only a portion of the window - if it has increased in resolution (e.g. during the switch from console to x output in the vm)
  * The console and its window decorations (on the host) - if it has decreased resolution (e.g. during switch from x to virtual console in the vm)
 * Some slow computers will not be able to run an entire host, a virtual machine and the recording software together and will likely end up dropping frames during the recording.
 * Text in a terminal may be difficult to read - especially so when rendered using low bandwidth and highly compressed video. It may be preferable to record console text and scale the video size up using tools such as avidemux. Alternatively for a terminal inside a graphical environment the usual scaling features of the desktop environment might be used - for example in GNOME the text in a terminal can be scaled up with [CTRL]+[+] and [CTRL]+[-].
Line 47: Line 66:
No meetings are currently scheduled. === Tools needed ===
Line 49: Line 68:
----
'''Sub-pages :''' [[Navigation(children,1)]]
----
I have based this how-to around the tools listed below. It is possible to find other drop-in replacements for some of these - for example using vmware instead of QEMU, but this combination worked well for me.
Line 53: Line 70:
----
CategoryUbuntuTeams
 * One (or more) of (kqemu & QEMU), (kvm & QEMU [if your CPU has VT instructions]), VMWare, Parallels or Xen.
  * This guide suggestions qemu
 * xvidcap (record the session - video only, audio dubbed on later)
 * audacity (record the audio)
 * openoffice.org (for titles)
 * avidemux (for combining video and audio together and re-encoding to some other formats)
 * ffmpeg2theora (convert to ogg/vorbis/theora)
 * oggenc (make an ogg/vorbis version of the audio track)

.. and all their dependents

==== kqemu & QEMU ====

Install qemu package from universe repository.

{{{ sudo apt-get install qemu
}}}

kqemu is a closed-source kernel based accelerator designed for QEMU. Its author is the main developer behind QEMU itself.

https://help.ubuntu.com/community/KQEmu

==== kvm & QEMU ====

kvm is a kernel based virtual machine. It includes a kernel module and a modified QEMU package. It utilises the VT instructions in modern CPUs to accelerate emulation.

Feisty has kvm in the 2.6.20 kernel.

Other releases need to compile kvm manually from http://kvm.sf.net/ using http://kvm.sourceforge.net/howto.html as a guide.

{{{ Note: From this point on it is assumed that you have either chosen kqemu or kvm or neither and have the necessary kernel module loaded when running QEMU. Alternatively you may use a different virtualisation system such as VMWare, Parallels or Xen, but the use of those tools is documented elsewhere and is beyond the scope of this document.
}}}

==== xvidcap ====

Downloadable .deb from http://xvidcap.sf.net/.

{{{ wget http://kent.dl.sourceforge.net/sourceforge/xvidcap/xvidcap_1.1.4p1_i386.deb
sudo dpkg -i xvidcap_1.1.4p1_i386.deb
}}}

==== OpenOffice.org ====

Should already be installed.

==== avidemux ====

Install avidemux package from multiverse repository.

{{{ sudo apt-get install avidemux
}}}

==== ffmpeg2theora ====

Install ffmpeg2theora package from universe repository.

{{{ sudo apt-get install ffmpeg2theora
}}}

==== oggenc ====

Install vorbis-tools from the main repository.

{{{ sudo apt-get install vorbis-tools
}}}

=== Setting up the environment ===

==== Download ISO(s) or Obtain CDs ====

Get ISO images of the versions you want to screencast.

==== Create a virtual disk ====

{{{ qemu-img create -f qcow dappervm.qcow 10G
}}}

"10GB should be enough" - yes, quote me on that in 10 years :)

==== Boot up and install into VM ====

Use more memory (-m) if you have it available.

{{{ qemu -hda dappervm.qcow -cdrom dapper.iso -m 256 -boot d -net nic -net user -soundhw all
}}}

Follow the usual procedure for installing. When prompted for a user, create a generic username which will be used during the screencasts.

==== Boot up installed VM ====

{{{ qemu -hda dappervm.qcow -m 256 -net nic -net user -soundhw all
}}}

Add all necessary updates but do not make any further changes, so that this becomes a "golden" image.
Backup the image.

==== Test recording software ====

 * Start the vm

The environment variables set below will casue a WAV file to be created which holds all the audio output made by QEMU. This can be mixed later with the narration.

{{{ export QEMU_AUDIO_DRV=wav
export QEMU_WAV_PATH=$HOME/capture.wav
qemu -hda dapperbase.qcow -m 256 -net nic -net user -soundhw all
}}}

 * Start the video recording application.

{{{ xvidcap</xvidcap>
}}}

http://gallery.popey.com/gallery/screenshots/Screenshot_XVidCap

 * Select the window to record

 * Start recording yourself doing some stuff

Note the colour bar in xvidcap shows whether you are hitting your fps target - red is bad, green is good.

 * Stop recording.

 * Test playback of the resultant video in various players for smooth playback.

=== Record a screencast ===

Screencasting how-to

Introduction

This is how I make screencasts. They come out fairly well. There are of course other ways to make them, this is just the way that I have found is best. You can see some examples of the screencasts I have made with this procedure at http://doc.ubuntu.com/screencasts .

All this was done on an Intel Core 2 Duo PC with 2GB of RAM, running Ubuntu Edgy (6.10) or Feisty (7.04). It is of course possible to do this on a lower spec machine but there may be difficulties on very low spec machines.

The basic procedure (which is covered in more detail below) is as follows:-

Dry run

  • Start a virtual machine running the operating system and application which is to be demonstrated
  • Go through the software to be demonstrated

Live recording

  • Start a virtual machine running the operating system and application which is to be demonstrated

{{{ Note: If the demo requires the installation of additional packages then to save time it can be preferable to setup the necessary repositories, download the necessary packages without installing them, then remove the repositories to put the system back to an post-install state. This of course assumes that you want to show how to enable repositories and install software within the screencast. To download packages and not install them use apt-get with the -d option:- apt-get -d packagename1 packagename2 ... }}}

  • Start a recording application to capture the contents of the virtual machine window - with no audio narration recorded
  • Watch the screencast to ensure all is ok
  • Add a 'intro', 'outro' slides to the start and end of the screencast
  • Open an audio recording application and record a narration whilst watching the screencast again
  • Check the audio recording for defects
  • Post-process the audio to clean it up and ensure it's the right duration for the video
  • Combine the audio and video together
  • Check the combined audio/video for errors/glitches/sync problems
  • Encode/compress video to other formats
  • Encode/compress audio to other formats
  • Upload video and audio to hosting provider
  • Upload video to Google

The reason for recording a virtual machine rather than the current desktop is to ensure the screencast is showing what a user would see. Most developers (or even experienced users) have additional software installed (such as the video recording application), have customised their desktop, or are running a version of Ubuntu (such as the current development version) which users might be less likely to use.

It also allows for a "gold" build to be kept in a disk image which can be re-used after a screencast is recorded. This means each screencast starts from the same basic starting point of a fresh (new) installation of Ubuntu. If screencasts are made which assume levels of knowledge or that certain software is already installed then it's possible users will get lost or give up when they see that the screencast doesn't match what they see.

Preparation

Preparation is the key. Getting the environment setup takes a while, but is worth doing it well because it means the time taken to create each screencast is lower.

Planning a screencast

Subject matter

Pretty much anything is fair game for demonstrating using this method. Some things are tricky, but can be worked around, and these are detailed under "Technical Limitations" below.

It can be beneficial to run through the whole screencast without

Technical Limitations

The following might be issues when recording using the method described here:-

  • Binary video driver installations - QEMU emulates a simple Cirrus Logic or VESA display, so it's not possible to show it running an ATI/NVidia video driver.
    • This could be overcome by using VNC to control a remote machine which does have an ATI/NVidia chipset rather than using a virtual machine.
  • Showing reboots or switching to the console - the QEMU window changes resolution when the video mode changes - which happens when you restart the virtual machine or switch to a virtual console. If you are recording the window and this happens then your video will capture either:-
    • Only a portion of the window - if it has increased in resolution (e.g. during the switch from console to x output in the vm)
    • The console and its window decorations (on the host) - if it has decreased resolution (e.g. during switch from x to virtual console in the vm)
  • Some slow computers will not be able to run an entire host, a virtual machine and the recording software together and will likely end up dropping frames during the recording.
  • Text in a terminal may be difficult to read - especially so when rendered using low bandwidth and highly compressed video. It may be preferable to record console text and scale the video size up using tools such as avidemux. Alternatively for a terminal inside a graphical environment the usual scaling features of the desktop environment might be used - for example in GNOME the text in a terminal can be scaled up with [CTRL]+[+] and [CTRL]+[-].

Tools needed

I have based this how-to around the tools listed below. It is possible to find other drop-in replacements for some of these - for example using vmware instead of QEMU, but this combination worked well for me.

  • One (or more) of (kqemu & QEMU), (kvm & QEMU [if your CPU has VT instructions]), VMWare, Parallels or Xen.

    • This guide suggestions qemu
  • xvidcap (record the session - video only, audio dubbed on later)
  • audacity (record the audio)
  • openoffice.org (for titles)
  • avidemux (for combining video and audio together and re-encoding to some other formats)
  • ffmpeg2theora (convert to ogg/vorbis/theora)
  • oggenc (make an ogg/vorbis version of the audio track)

.. and all their dependents

kqemu & QEMU

Install qemu package from universe repository.

{{{ sudo apt-get install qemu }}}

kqemu is a closed-source kernel based accelerator designed for QEMU. Its author is the main developer behind QEMU itself.

https://help.ubuntu.com/community/KQEmu

kvm & QEMU

kvm is a kernel based virtual machine. It includes a kernel module and a modified QEMU package. It utilises the VT instructions in modern CPUs to accelerate emulation.

Feisty has kvm in the 2.6.20 kernel.

Other releases need to compile kvm manually from http://kvm.sf.net/ using http://kvm.sourceforge.net/howto.html as a guide.

{{{ Note: From this point on it is assumed that you have either chosen kqemu or kvm or neither and have the necessary kernel module loaded when running QEMU. Alternatively you may use a different virtualisation system such as VMWare, Parallels or Xen, but the use of those tools is documented elsewhere and is beyond the scope of this document. }}}

xvidcap

Downloadable .deb from http://xvidcap.sf.net/.

{{{ wget http://kent.dl.sourceforge.net/sourceforge/xvidcap/xvidcap_1.1.4p1_i386.deb sudo dpkg -i xvidcap_1.1.4p1_i386.deb }}}

OpenOffice.org

Should already be installed.

avidemux

Install avidemux package from multiverse repository.

{{{ sudo apt-get install avidemux }}}

ffmpeg2theora

Install ffmpeg2theora package from universe repository.

{{{ sudo apt-get install ffmpeg2theora }}}

oggenc

Install vorbis-tools from the main repository.

{{{ sudo apt-get install vorbis-tools }}}

Setting up the environment

Download ISO(s) or Obtain CDs

Get ISO images of the versions you want to screencast.

Create a virtual disk

{{{ qemu-img create -f qcow dappervm.qcow 10G }}}

"10GB should be enough" - yes, quote me on that in 10 years Smile :)

Boot up and install into VM

Use more memory (-m) if you have it available.

{{{ qemu -hda dappervm.qcow -cdrom dapper.iso -m 256 -boot d -net nic -net user -soundhw all }}}

Follow the usual procedure for installing. When prompted for a user, create a generic username which will be used during the screencasts.

Boot up installed VM

{{{ qemu -hda dappervm.qcow -m 256 -net nic -net user -soundhw all }}}

Add all necessary updates but do not make any further changes, so that this becomes a "golden" image. Backup the image.

Test recording software

  • Start the vm

The environment variables set below will casue a WAV file to be created which holds all the audio output made by QEMU. This can be mixed later with the narration.

{{{ export QEMU_AUDIO_DRV=wav export QEMU_WAV_PATH=$HOME/capture.wav qemu -hda dapperbase.qcow -m 256 -net nic -net user -soundhw all }}}

  • Start the video recording application.

{{{ xvidcap</xvidcap> }}}

http://gallery.popey.com/gallery/screenshots/Screenshot_XVidCap

  • Select the window to record
  • Start recording yourself doing some stuff

Note the colour bar in xvidcap shows whether you are hitting your fps target - red is bad, green is good.

  • Stop recording.
  • Test playback of the resultant video in various players for smooth playback.

Record a screencast

ScreencastTeam (last edited 2010-11-10 17:25:46 by g65)