Video on the Web
Video on the web is here to stay. Over the past two days at work, I developed a new video podcast on using Google’s new “MyMaps” service, part of Google Maps.
(The feed for the podcast is here: TechTimes Live.)
So, with folks like the Washington Post now sporting HD podcasts (presumably for the AppleTV), what gives for instructional video podcasts?
I’ve recently found some online tutorial sites, such as MacInstruct and Screencasts Online, which are great (for Mac users). Tonight, I received an e-mail from Apple, with this suggestion (er, warning?):
It’s best not to create two different podcast feeds for different resolutions. By doing so, you dilute the popularity of your podcast and reduce exposure in our charts. It’s better to have one feed high in the charts than two that are lower.
They like 16:9 format, and they really like 640 resolution, across.
If your source files are 16:9, stick with that aspect ratio. Don’t add letterboxing to make them 4:3. By doing so, you prevent the video from expanding to fill a 16:9 widescreen TV and instead end up with black space on all four sides. Also, your original source files should be at least 640 pixels wide.
This was my solution in working with the new video podcast.
I developed an introduction at 30fps at HD resolution (1280×720). This is too big for some monitors (1024×768). It’s great for an Apple TV. But the original source file was 5.42 GB. That’s bigger than a DVD for an 11-minute podcast (full 48kHz audio, 30fps, Motion-JPEG). These are huge files. My screen recording, likewise, filled the majority of those 11 minutes at the same resolution.
I next did some editing in Final Cut Pro. The entire video required re-rendering. Not sure why. This is FCP 4.
After the editing, I got my giant 5.42 GB file. I dragged it into a 3rd-party encoder (MPEG Streamer) and compressed the video to 800px wide, by 450 tall. This seemed to be a nice compromise. I used H.264, mono AAC audio, and 15 fps.
I wasn’t overly impressed with the video quality (at 62 MB). I might try again at a higher bit-rate. I could also try again with another compression engine (Quicktime, VisualHub, etc.) to see if the quality would improve. My app contained an option to multi-pass, which I did, and didn’t see any significant improvement for the 3-times as long wait.
The problem with instructional videos that rely upon screen capture is that, even at 640×480, they are not effective for iPods. They “sing” at HD. But a good quality HD video at 11 minutes would likely be 150-200MB download. And that’s not reasonable for distribution on the web–yet. The 800×450 ratio is likely a good candidate for Apple TV, but my videos are intended for teachers (and in some cases students) using a 1024 or 1200-pixel wide laptop.
The one thing that did translate well in the video I made was the zooming-in using the Universal Access feature in Mac OS X. When you *really * want someone to see something, it’s worth invoking. The more you, I think the better the video is.
Developing a good instructional video takes time and patience. I think future attempts will include more motion graphics to support the underlying soundtrack (more examples, visualizations), and maybe a “talking head” component so people can actually see the instructor. No one needs to see me for the entire production, but the human-element of having a person delivering the content might help.