During my lecture on Thursday, I forgot to switch on the screen recording function in Open-Sankoré, something that I had originally planned to do. So, I decided to prepare a few mini screencasts to cover the essential material. This is taking much longer than I was expecting!
Firstly, I have been looking into multiple screencasting solutions. As an open-source fanatic, I’m always drawn in that direction. Open-Sankoré is extremely promising and works well… except, it turns out, when trying to capture the desktop to file on the Surface Pro. In the electronic whiteboard mode, it appears to work well. However, difficulties appear when capturing the Surface’s desktop. The problem is that visually, the pen lags and drawing is not smooth. In the end, I thought that this might be tolerable if it worked overall. So, I spent just shy of 20 minutes recording my first screencast. I eagerly opened the resulting video to discover that the sound progressively degraded (speed changes, dropping in and out) until there was no sound at all!
Following this disheartening experience, I quickly fired up Camtasia Studio. Camtasia is designed and optimised for this sort of thing and had no problem recording both screen and audio. The result was trimmed and uploaded to YouTube pretty much without any problems. This is what you might expect from a £200 piece of software.
However, I’m never satisfied with the commercial solution when I know that this can be accomplished using open-source software. To do this, it seems, does require some determination. For me, it also required switching software and computers, although I’m sure that this isn’t strictly necessary.
So, firstly, there are three main open-source options for screencasting. The most powerful and general tool is ffmpeg. This is a command line utility capable of doing almost anything with audio and video if you have the patience to learn all of the command line parameters and nuances of difference audio/video formats. Another way of screencasting is via VideoLan VLC player. I had no idea that it had this capability. Finally, another piece of software that I have used in the past is VirtualDub. A very powerful, yet simple, video editor. On Windows, all of these pieces of software rely on a DirectShow device for desktop streaming. There are several DirectShow device drivers available for download. However, the only one that I found released under an open-source license was screen-capture-recorder.
Now, here is where I ran into some problems. In VirtualDub and ffmpeg, the DirectShow device refused to recognise the Surface Pro’s full HD screen resolution, stubbornly reporting it to be 1280×720. The consequence of this was only a partial screen capture. VLC on the other hand did report the full screen resolution using the same device driver, but consistently crashed when halting the capture thus corrupting the video file. After some messing about and much head scratching, I discovered that the Windows 8 desktop scaling feature was tricking the DirectShow driver into thinking the resolution was only half HD (i.e. 150% scaling).
This feature is designed to make items display at a sensible size on a 10” 1920×1080 pixel display. Setting the scale factor to 100% fixed the incorrectly reported resolution. Hence, using ffmpeg with the command line;
ffmpeg -f dshow -i video=" screen-capture-recorder ":audio="Microphone (2- High Definition Audio Device)" -r 24 -s 1920x1080 -vcodec libx264 -crf 0 -preset ultrafast -acodec pcm_s16le output.mkv
I was able to capture my second screencast . I’ve opted for capturing uncompressed video to ensure the highest frame-rate. The files are then transcoded post-screencast. This is where I encountered another difficulty with ffmpeg. My transcoded files wouldn’t play in any of my usual media players! I have no doubt that ffmpeg is more than capable of producing widely playable video, but not with my naïve settings. This is where I employed another well known open-source video transcoder, Handbrake. Handbrake was able to read in my raw .mkv video file and spit out an .mp4 file suitable for iPads, Android devices and PCs.
After all of this, it then occurred to me that I still needed to edit the video. VirtualDub wasn’t playing nicely with my newly transcoded video (or the raw video), so I opened up the .mp4 file on my MacBook Pro. One thing that I like about Apple OS X is that it includes iMovie, which is a pretty decent video editor without shelling out additional cash. iMovie happily imported my .mp4 file, allowed me to edit it and then export an Apple QuickTime .mov video file. I’m not entirely satisfied with the .mov file, so I used HandBrake one more time (on the Mac this time) to transcode the video back to a universally playable .mp4. This was then uploaded to YouTube and shared with the students via facebook and twitter.
So, if you want an easy life, buy Camtasia. However, with a little effort there is an alternative route via open-source software. That said, the ffmpeg screen capture didn’t have perfect audio. During capture, video frames were dropped and I suspect that this is where corresponding audio was also lost. I’m sure that this can be fixed, possibly by adjusting some of ffmpeg’s many parameters. Another culprit may be that I opted to stream my full HD display to disk. Next time I may try a lower resolution display setting and see if this improves things. So, I will work on finding a solution and post my findings here.
Nevertheless, the Surface Pro is proving itself to be a very capable little device.
iteachstats 