Channels ▼
RSS

Open Source

Dual-screen Recording In Linux


Mike is a contributing editor to Dr. Dobb's. He can be contacted at mike@mikeriley.com.

Recently, the need arose for me to demonstrate several related web applications for a presentation. This is my story.

The Search Begins...

My preferred development platform of choice these days is Fedora 7 (though anxiously awaiting the final release of Fedora 9) in a Compiz Fusion-enabled dual-screen environment. However, I use Ubuntu on my single-screen laptop configuration due to the hassles associated with specific hardware port detection and notorious suspend/resume issues. I investigated several screen recording solutions that would allow me a 24-frames per second or higher capture rate for smooth mouse and window scrolling movements. I also needed audio support to simultaneously capture accompanying narration. Several open source choices exist, including:

  • Visit Linuxmafia.com for a more comprehensive list of currently available Linux screencast capture programs.

    After test driving each of these, I settled on recordmydesktop thanks to its ease of use, tweak-ability, and ubiquitous Linux distro repository proliferation. While the program worked flawlessly on my single-screen laptop, it hiccuped on my dual-screen configuration. While the results started off fine, once any window or desktop cube movement was recorded, the playback would go turn into a runny watercolor mess:

    Compared to the other options, only xvidcap seemed to successfully capture a good portion of the desktop without going rainbow on me:

    Unfortunately, if I exceeded a certain width, xvidcap would die with a segmentation fault. I returned to recordmydesktop after researching the application's website and noting its FAQ page mentioned known playback issues in Compiz-Fusion environments though no specific mention was made of dual-screen problems. I tried captures with Compiz-Fusion turned off during recording as well as playback to no avail. At this point I acquiesced and chose to reset my width expectations by reducing the screen recording area from 3200×1200 to 2000×1200. Partial dual-screen activity could then be successfully and smoothly replayed:

  • With several viewable screencast captures in the can, my next challenge was to assemble these into a more polished presentation format. While recordmydesktop admirably compresses each capture into a Theora wrapped Ogg Vorbis (.ogg) file, directly editing this compressed format in various commercial and open source non-linear editing (NLE) applications such as Sony's Video Vegas or Apple's Final Cut Pro isn't possible until converted into a more universal format such as raw digital video (*.dv). The Swiss army knife of video conversion programs, ffmpeg, will perform this conversion admirably using the following parameters:

    ffmpeg -i out.ogg -target ntsc-dv output.dv 
    

    However, given my preference to execute as many tasks in Linux as I can, I decided to try another popular open source program, this one designed to edit digital video.

    Capture Distillation

    Kino is a Gnome desktop-based DV editor that automatically converts compressed encoded video types (assuming the appropriate libraries have been installed) including .flv, .mpg and .ogg formats, into uncompressed .dv files. Just be sure to have plenty of available disk space available before doing so.

    Once imported, Kino works like many simple NLE's such as Microsoft's Movie Maker or Apple's iMovie, although Kino's UI and controls leave a lot to be desired. Still, for relatively simple digital video composite work, Kino is adequate for the job. Kino co-developer Dan Dennedy even demonstrates a screencast on the program's website showing how Kino can export to various compressed formats including Theora Ogg via ffmpeg2theora. Videos can then be published from a shell program that uploads the file directly to YouTube competitor blip.tv.

    A Successful Conclusion

    So how did my Odyssey end? While the full dual-screen objective failed to be fully realized, it really didn't matter. After a handful of sample recordings, the final results were simply at too high a resolution to view at web video-constrained sizes. Heavy compression also took its toll on small text that was obliterated in the final resampling:

    Reluctantly, I bid adieu to the idea of impressing my viewing audience with widescreen eye candy and instead leveraged the dual-screen real estate in a much more effective way. Since recordmydesktop (as well as other applications like xgidcap) allow for specific areas of the screen to be captured, I strategically positioned the recording area on my left screen, further reducing that screen area to a 1024×768 rectangle, and placed all my preloaded set pieces including code snippets, pre-populated browser windows and other GUI elements on my right screen, far outside of the recording rectangle. Another benefit of the non-captured screen space was the addition of my narrative script/notes to follow during the recording of the presentation. Once captured and distilled, the final output was even better than expected and really made a difference in the audience's enthusiastic comprehension of the project status:

    Since then, I have started adopting this screencasting approach for many other client education and team training scenarios, including code reviews, product demonstrations, configuration setting explanations, end user testing (great for showing developers how recorded end users might struggle navigating what was thought to be a brain-dead easy user interface) and so on. This process has become quite an invaluable addition to my project documentation and demonstration arsenal.


    Related Reading


    More Insights






    Currently we allow the following HTML tags in comments:

    Single tags

    These tags can be used alone and don't need an ending tag.

    <br> Defines a single line break

    <hr> Defines a horizontal line

    Matching tags

    These require an ending tag - e.g. <i>italic text</i>

    <a> Defines an anchor

    <b> Defines bold text

    <big> Defines big text

    <blockquote> Defines a long quotation

    <caption> Defines a table caption

    <cite> Defines a citation

    <code> Defines computer code text

    <em> Defines emphasized text

    <fieldset> Defines a border around elements in a form

    <h1> This is heading 1

    <h2> This is heading 2

    <h3> This is heading 3

    <h4> This is heading 4

    <h5> This is heading 5

    <h6> This is heading 6

    <i> Defines italic text

    <p> Defines a paragraph

    <pre> Defines preformatted text

    <q> Defines a short quotation

    <samp> Defines sample computer code text

    <small> Defines small text

    <span> Defines a section in a document

    <s> Defines strikethrough text

    <strike> Defines strikethrough text

    <strong> Defines strong text

    <sub> Defines subscripted text

    <sup> Defines superscripted text

    <u> Defines underlined text

    Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

     
    Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
     

    Open Source Recent Articles

    Video

    Upcoming Events



    Most Recent Premium Content