I’ve been focussed on putting together a load of video demonstrations for this online training course I’m writing. Time has just flown by.

I’m gradually figuring our an effective (and increasingly efficient) workflow so my hope is that I will continue to increase the speed with which I produce each part of the course. (The good news being that all the writing is pretty much done.)

For those interested I’ve outlined my current workflow below.

With each page written on the website I have placeholders showing where the various media files will appear.

For each video I create a running order. This is a page per video in Notebook, with each instruction I am going to execute, notes on why I am running it and what points need to be made in the final video. These pages form the shot-list for each video.

Then I use SnapzPro to capture video of the on-screen activity as I run each page of commands. I’m using a virtual PC running VMWare Fusion for the execution. Using the virtual machine has big benefits for being able to recover to a known state, but more importantly most potential students for this course will have access to Windows, so the course is run on Windows XP (which runs in the VM).

Once I have all the raw screen capture, I process it with Apple’s FinalCut Pro to remove any mistakes and make each sequence into one seamless shot sequence. These sequences are very short as all the pauses in the original captured material are removed.

These shorter sequences run through the examples very quickly, often only a few frames of each command are shown. Obviously useless for a demonstration, but lightweight material for the next step.

Referring back to the Notebook shot-lists I process each of the reduces screen sequences to make one longer sequence with animated graphics explaining what is happening with each command. These sequences are longer than the reduced screenshot material but still run through far too quickly for demonstration purposes.

The Motion sequences produced in the previous session are not rendered, but left as motion projects. Leaving them as Motion project makes them easier to adjust later.

Next, I record the voice over using Apple’s Soundtrack Pro. Again, the Notebook shot-list and notes are used to ensure I cover the relevant material.

Using Soundtrack Pro to record the voiceover is a bit of an overkill, but it allows me to record and edit the voiceover in one seamless workflow. As I record the audio I manually step through the Motion sequence to make sure the voiceover makes sense with the graphics. I make notes of any additional information the sequence requires using Notebook, tagging it with a keyword to make it easy to find. Most of the additional material is, at this point, things like additional slides, ‘tip’ boxes, and other material that will be overlayed onto the Motion sequence, rather than changes to the Motion sequences themselves. If I spot a mistake in the Motion sequence while recording the voiceover I edit it there and then.

Once I am happy with the voice over I render the audio out from Soundtrack Pro to a new aiff file. I do this because the Soundtrack project can be pretty busy at this point and producing one consolidated voiceover track makes it easier to handle in subsequent steps (it also means I do not have to worry about the temporary capture files produced by Soundtrack).

I now have the Motion sequence and a full length voiceover, but the two do not match up.

Returning to FinalCut Pro the final assembly can begin. Each Motion sequence contains one or more teaching units. For example, one sequence might show two or three ways to use one particular command. The voiceover for each unit is cut into its own sequence and the Motion sequence is then retimed using freeze frames so that it coincides with the voiceover. Any additional information identified during the creation of the voiceover is overlaid onto the resulting sequence. (These overlays are often Motion sequences too, so these are create now.)

The result of the workflow to this point is a FinalCut project with a collection of sequences each representing one teaching unit. These individual sequences are now assembled into various combinations depending upon the target output. For example, a sequence may be used in a show ‘Show Me’ style video, as part of a longer video that aggregates all of the information for one particular command, and also as part of a promotional/tutorial video to be posted on YouTube. The individual sequences are joined with transitions to ensure a smooth flow to the final product. Where appropriate title sequences are added to the start and end of these aggregate sequences.

Finally each of the aggregate sequences is output to Soundtrack Pro for audio finishing. This involves adding music, stings and sound effects as well as smoothing out audio transitions and sweetening the audio to get the best results I can. Once this sweetening is complete the whole project is re-exported back to FinalCut.

A final check in FinalCut and any changes required after the final audio changes, then each aggregate sequence is rendered to HDV720p using Compressor. Selected sequences are also rendered for other formats such as H264 podcasts. The HDV720p material can be uploaded straight to the training course and sites like Vimeo and YouTube. It can also be used as source material for assembly into a DVD format, more an this later.

Each sequence is checked and then uploaded to the appropriate service for use.

And that is why producing this stuff takes time!

The sense of horror that washes over me when I merely contemplate the plunge into the tarmac terror that is Bank Holiday traffic is enough to persuade me that, short of life threatening circumstances, the project can be delayed.

Why do I raise this issue now? Well, first, and most obviously, it is a Bank Holiday weekend. Secondly, while playing with chroma-key video editing (you know, the green/blue screen technique for separating and transplanting one image into another) I discovered that, while I could achieve reasonable results with a very rough set-up, what I really need is better lighting.

This all stems from my need, not for perfection, but to get the best result I can from my system. The masks I was getting, even with the limited system I was using, were not too bad. The tricky parts of masks tend to be fine detail like hair. One ends up with either flat hard edged hair that looks like someone has cut you out of a magazine, or you get a distracting flickering halo at the edge of the hair as the algorithm struggles to show the wispy hair as semi-transparent. Neither result met my criteria for ‘best result possible’.

The difference between generating a reasonable mask and a good mask using consumer video cameras are two-fold:

1. Good software
2. Good lighting

The good software comes, for me, in the form of Apple’s Final Cut Pro and a superb plug-in dvMatte Pro (more on these in a moment).

The good lighting proved to be a problem. You see, I’m not a big fan of lights. I have exactly three lamps in my house; one beside the bed, one I use as a video light in the study and a ‘daylight’ lamp I have on the desk. All other lighting in the house is provided by 60W ceiling bulbs.

The upshot of the paucity of flexible lighting (or even bright lighting) makes it tricky to brightly and evenly light the green backdrop and makes correctly lighting the foreground (me) almost impossible. The different types of light make colour balance tricky and the inability to evenly light the backdrop made it even more difficult to produce a clean mask.

The standard matte tools in Final Cut Pro are designed for use with high quality video. Consumer cameras tend to produce low quality video. Low quality in the sense that it is compressed and this compression causes artefacts in the image imperceptible to the human eye but all to evident to software algorithms. The practical upshot of this being that it is nigh on impossible to produce a sharp mask with the built in matte tools. dvMatte Pro to the rescue!

dvMatte Pro is nothing short of astounding. Designed specifically for creating mattes from DV and HDV footage this plug-in worked wonders with even the roughly lit footage I produced while experimenting.

The conclusion that the problem was lighting was arrived at over several experiments. The best mask I could achieve used three lights; the overhead 60W incandescent bulb, a halogen lamp lighting the foreground subject and the daylight lamp (which has a greeenish tint anyway) lighting the backdrop from below. Using three different types of light creates ‘interesting’ challenges for colour balance too, but that’s another story.

Oddly, the best results also used the plain magnolia wall of my study and not the green screen. I suspect this is because the wall shows less variation across its surface when lit with just one lamp. Also, the daylight lamp produces a green tint on the wall (this tint is only apparent on video, it looks white to the naked eye).

The problem areas in the resulting mask were as follows.

1. Hair was being picked out much better than previous attempts, but still remained ill-defined and resulted in an odd shimmering halo when pushed too far.
2. Tops of shoulders had some odd highlight artefacts and even more peculiar a shadowy halo on the raw footage. I suspect this was partially because the screen was lighter around this area and the lack of a back light and weak foreground lighting conspired to produced the odd shadows in the video.
3. Ears also had problems for some reason. Getting ears clearly defined meant pushing the hair too far into the flickering halo effect.

All in all the results were comparable with green screening circa 1980. The foreground image showed haloing and did not integrate well with the scene into which it was dropped. If I hardened all the edges by cutting my hair or wearing a hat I have no doubt I could get a good result (this seems to be a common tactic among YouTubers), but that would be defeatist talk!

To get reasonable results I think I need better lighting to produce better defined raw footage and help the matte algorithm. Specifically I need to address the following.

1. Bright even light on the green screen.
2. Brightly lit subject.
3. Back light on subject

Bright even lighting of the green screen should make it much easier for the algorithm to identify. This much is obvious.

Brightly lighting the subject will help to sharpen the image and reduce DV artefacts due to poor light. The more light the camera has to work with the better and brightly lighting the background while ignoring the foreground will produce a problem with back lighting (a bit like filming someone against a window the image blows out unless compensated for in camera, but this in turn causes the backlit screen to overexpose which causes a whole other set of problems).

Back lighting the subject is, for this project, icing on the cake. It should help to eliminate spill from the green screen, help to eliminate boundary shadows on the subject and help punch the subject out of the background.

Having looked around at specalist video lights I decided they were too expensive for what I need. Frankly, I’m not looking at producing broadcast TV here. I just want to produce reasonable quality video. The solution seems to be 500W halogen work lights. They’re cheap, bright and flexible. I need two to light the screen, one for a back light and one for the foreground light. Four lamps, total cost around £80 (less than the cost of a single video light and stand).

Sorted then? Not quite. As I said, it’s a Bank Holiday weekend. The closest store I can find on-line that I know has these lamps in stock is a large DIY depot half an hour away and this project can wait.

I am not going to a DIY store, of all places, on a Bank Holiday weekend!

It’s been a long, but ultimately satisfying day today. Managed eleven hours straight through on one task; preparing a video showing the various methods of accessing a Subversion repository and the options available for securing communication between the client and server.

Working with Apple’s Studio Pro is  a joy. I’m currently using Motion for all the main animation work and assembling the final cut in, well, Final Cut. It seems to take about one hour to prepare one minute of video, although obviously this varies a lot depending on how dense the animations are and how much fine tuning I do. Tomorrow I will be working with Final Cut and Soundtrack Pro to assemble the sound in the final edit.

While waiting for scenes to render I got more work done editing the course material. The course material is shaping up nicely now that the site style has settled down I’m rather pleased with the results. It is, however, turning out to be an interesting challenge transfering information from the book form into an on-line course. There is quite a difference in how the information needs to be structured between the two.

I need a few weeks of this kind on intensity to make some serious progress, and that is going to be tough. That said, if I don’t get stuck in then I’ll starve before this makes enough money to make it worth while. So, it’s heads down tomorrow and Friday, then a weekend with my son and back at it on Monday for a full week.

Meanwhile, I’ve been working on my professional blog. This is forming a part of the promotion material for the course so I need to keep adding to that to maintain reader interest.

I’m in the process of developing a lot of video demonstrations. To do this I am using SnapzProX on Mac OS X to capture screen video at HDV720p25, which provides 25fps at 1280×720 resolution, ideal for my purpose. These screen capture videos are then assembled with titles, voice over, music, etc. into the final product using Final Cut Pro (with some Motion work thrown in for good measure). The final video is then rendered to various formats using Compressor and the excellent CRAM library of Compressor settings.

This workflow works very well but for one step. When loading SnapzProX capture (SnapzProX claims to be writing Apple HDV720p25) into a Final Cut project with an HDV720p25 timeline the video is chopped off early. The problem, it turns out, is caused by the way SnapzProX records video. The framerate in the video is recorded using a variable rate and is not properly encoded as 25fps when written out, despite the codec being set to HDV720p25. Long story short, the captured video is complete (plays back fine in Quicktime) but Final Cut is more picky and always reads the framerate as 10fps (the default constant framerate used by SnapzProX) even though the actually recorded video may have a variable frame rate. Confused? So was I.

The solution, it turned out, was to re-encode the SnapzProX produced video using Compressor set to produce HDV720p25 video. This additional step corrects the framerate information in the video (making the video slightly larger as a conseqence). With this corrected encoding Final Cut is satsfied and all is right with the world again.