The First Thing? Reinstall the OS

This might seem like craziness to some people, but the default OS X install has a bunch of language files, fonts, and printer drivers that you will never ever use. I immediately get the restore disc out and do a clean install of OS X (in this case, Snow Leopard). To do this properly, once you boot from the install disc and select your language, click on Tools in the Menu Bar and open Disk Utility. From there, select your primary hard drive from the column on the left and click on the Erase tab on the right hand side. Ensure that Mac OS Extended (Journaled) is selected and hit Erase. Now you’re ready to hit the ground running.

Quit Disk Utility and you’ll be brought back to the Installer. Click continue until you arrive at a screen with the “Customize” button in the lower left. Click on that and uncheck everything in there so that “Essential System Software” is the only thing being installed. You’re already well on your way to a leaner, meaner system.

Update Everything, Install Only One Program

Even on my brand new machine, the first thing I had to do after booting up for the first time was apply critical system and security updates to OS X. This may take you a few restarts depending on how old your installation disc is, but with my method you’ll never need it again. After your system is completely up to date, open Disk Utility again (located in Applications > Utilities), select your partiton from the left (usually named Macintosh HD), and click on the button that says “Repair Disk Permissions” under the First Aid tab. I generally do this after applying large amounts of updates just to ensure there’s no data corruption now or in the future. If you want to know a little more about this process, check out Apple’s Support Document on the topic.

The hard drive should only contain the freshly installed-and-updated system: none of the programs you use, none of your user files like pictures, music, etc. I download only one program at this point: SuperDuper!

Time For the First of Many Backups

Some people swear by Carbon Copy Cloner, but I love the speed and interface of SuperDuper! — In reality both programs are amazing at what they do: creating a bootable backup of your system. The one feature of the new MacBook Pros and iMacs that got me jazzed was the inclusion of a dedicated SD card reader. The first practical application I thought of, beyond the obvious quick retrieval of photos and videos, was a bootable SD card backup and that’s exactly what I did. You’ll need at least an 8GB SD card for this to work, and I’d recommend Class 6 or higher. The Class of an SD card is a measure of it’s speed; Class 6 cards usually range in the 20-24mbps range, which is plenty fast for our purposes.

Insert the SD card into the dedicated slot or into a card reader connected via USB, open Disk Utility and select it (not its indented partition, but the device itself) in the left column. Once you’ve done that, click on the “Partition” tab on the right side. Under Volume Scheme, select 1 Partition, then click on the “Options…” button. From here, make sure to select the GUID Partition Table, which will make this SD card a bootable OS X device, then click OK to come back to the main Partition section. From here you can optionally name your volume or just hit the Apply button. Disk Utility will format and partition the card and it will appear back on your desktop. Quit Disk Utility and switch over to SuperDuper!

The interface here couldn’t be simpler: In the first drop down, you select your primary hard drive, in the second you select your SD card, and the one underneath should have “Backup – all files” selected. Once that’s done, click on Copy Now, enter your user password, and go grab a sandwich.

First Backup Done, Initialize Offsite Backup

You now have a fresh, up-to-date version of Snow Leopard you can restore from in the future should you ever want to start over or deploy a basic installation quickly on a new machine. Remove the SD card, flip the switch into the “Lock” position, and store the card away somewhere safe.

The next thing I do is install an off-site backup manager. There are literally dozens to choose from and after giving them all a fair shake I decided to go with BackBlaze. Here’s a quick list of other services you can choose from for the sake of fair-and-unbiased-ness:

• Mozy
• Carbonite
• iDrive
• Crashplan
• JungleDisk
• ElephantDrive

They all vary slightly in price and implementation, but all work great. I chose BackBlaze because it’s $5/month/computer for unlimited storage and installs itself as a simple System Preferences panel. All of these services say that the initial backup takes the longest, which is why I still don’t put any of my files on the computer at this point: I basically want  a working duplicate of my computer in the cloud. Your mileage will vary from mine at this point depending on your internet connection, but you basically have to upload roughly 12GB of system files onto the internet. This is something I let run overnight, while I sleep soundly knowing my data is being secured.

Finally, Move Your Files Over, Install Your Apps

I assumed a lot from you going into this article, not the least of which was that you had your data safely stored on some sort of external device or computer. Well, now’s the time to bring all of your goodies into the fray. Add your music, movies, photos, etc and order them however you’d like. If you’re as particular about your folder structures and naming conventions as I am, this could very well be the longest step. Also feel free to install all of the programs you use as this point.

More Backing Up

We’re almost at the home stretch, so now you’re probably thinking “What the hell more could we do to secure our data?” Well, we’ve already started on one: Backblaze.

After I moved all my files over and installed the programs I use on a regular basis, the amount of space I was using jumped from 12GB to 204GB. Backblaze (or whichever service you’ve chosen) will back all of that information up. For me, it took roughly 3 weeks (all the while adjusting how much bandwidth I wanted BackBlaze to use: more at night, less during the day, etc), so that’s pretty much a background thing that will be happening for a while. The last thing to set up is OS X’s own Time Machine.

Taming Time Machine

I love Time Machine; before it was introduced in Leopard I never had a backup/restore plan. I figured if I lost everything (thankfully that’s never happened), I’d just start over again from scratch — the force (of  laziness) was strong in this one. Time Machine made it easy and important to me to back up everything digital. Though it isn’t without it’s flaws, it’s certainly the solution a majority of people who use OS X are most familiar with. I don’t use any third party tools to control the times of day it chooses to back up, but I am very particular about what it backs up. Below is a list of folders that I explicitly tell Time Machine NOT to back up and why. If you’d like to save a little space on each back up, you can add any or all of these folders by going to System Preferences > Time Machine > Options.

• /Applications — This folder changes so often and drastically that I’d prefer to manage it on my own. If I need to get an app that I accidentally deleted, I’ll make sure to get the latest version from the company’s website.
• /Library/Audio — After installing Final Cut Studio and Logic Pro, this folder jumps up to a whopping 32GB. Again, if I accidentally delete something from here (unlikely), I’ll reinstall from the disc.
• /Library/Caches — Non-vital files that can accumulate in size rather quickly and change even quicker. No harm here.
• ~/Library/Caches — Same as above
• ~/Downloads — This folder changes so often that I’d rather not have anything in here backed up. I do pretty regular maintenance to keep this folder clear anyhow.
• ~/Dropbox — I’m a mega Dropbox user. If you haven’t heard of it, you should really make it a part of your life. Anyway, Dropbox files already live in the cloud (and usually on many other computers) and have the ability to go back multiple versions. No need to back this stuff up.
• ~/Library/Application Support/MobileSync — Only applicable if you’re an iPhone user, but definitely worth looking into. I’ve synced my iPhone 4, which is loaded with video, to my MacBook only a handful of times, but this folder clocks in at 18GB+ for me.
• ~/Movies — I only use this folder as a drop point for DVDs I rip before storing them on an external drive. This is another situation where the folder changes so many times I’d rather not waste the time having Time Machine back up huge, temporary files.
• ~/Music/iTunes/iTunes Music/Podcasts — This folder might have a slightly different path depending on whether iTunes has updated your library recently, but I never bother to backup Podcasts since I download so many of them at a time, watch them, then delete a majority of them.
• ~/Documents/Virtual Machines — This is the folder that VMware uses to store Virtual Machines in. If you use Parallels, VirtualBox, or something else you’ll have to find out where they store these massive files. Basically, every time you boot into the virtual machine the files within are changed slightly, but since the Finder (and, ergo, Time Machine) only see this as one large file, it will back up the whole thing again and again. Needless waste of space here.

Dropbox and Alternative Approaches

Some files I choose to keep in my Dropbox folder for easy access: documents, some pictures, application data, and more. Dropbox is as good a backup solution as any if you’re willing to pay a little more for a very fast, very convenient service that offers a native app as well as a web interface.

It’s worth mentioning that you don’t need to back up to an SD card, but it’s a method I chose because they’re inexpensive, reliable, and fast. You could just as easily follow the same steps on an external USB or Firewire hard drive. Hell, you could even use a USB memory stick if you had one of those lying around. Another option would be to save that step until after you’ve moved all of your files and programs onto the machine and then create a bootable backup of your entire system. You can even automate this with the paid version of SuperDuper so if your primary hard drive ever fails, you literally boot into your backup and pick up where your last backup left you off.

Recap

Here’s how I roll, in list format:

1. Clean OS X Installation
2. Update OS X via Software Update
3. Repair Disk Permissions in Disk Utility
4. Create a bootable backup of my primary hard drive using SuperDuper!
5. Install BackBlaze for off-site backups
6. Move all of my files onto the hard drive, install all of my apps
   1. BackBlaze passively continues to back up all of these files
7. Set up Time Machine on my Mac, excluding several folders that are greedy with my gigabytes
8. Revel in the fact that I’m safe should my MacBook’s internal hard drive bite the dust

In Closing

There are clearly a variety of ways to ensure that your data is safe. None of them are perfect and a few of them (I’m thinking my way, for sure) are a hell of a lot of work to maintain, but when your primary source of income can be crippled because of something as small as a corrupted hard drive, it’s a good feeling to know that you’ve taken steps to make sure you won’t be out of commission for too long.

First Things First

Obviously the first thing you’ll need is a high quality source file. (Note: any file will do, but encoding from the original, lossless source always yields best results). In my case, I was working with an HD video file that I just finished editing in Final Cut and exported using Compressor. If you’re exporting from an editing suite and not intending to serve up an HD version of your video, then exporting a standard DV file will work. If you’re taking the video directly from a video camera like a Flip Mino, Kodak Zi8, or even your phone, then chances are your videos are already compatible.

A Brief and Incomplete History of Video Codecs and Containers

Working with video can get overwhelming very quickly if you’re unfamiliar with the terminology or concepts, so here’s a quick breakdown of video as well as the two types we’ll be dealing with: MP4 and Ogg.

It’s safe to assume that if you download videos from the internet, you’ve encountered a few of the more common extensions: MOV, MPG, AVI and unfortunately WMV. Those files are known as video containers. Think of a video container as you would a ZIP file: an all-in-one package that contains the content you’re really after. In the case of video containers, the files within are known as streams or tracks and represent a variety of things including video, audio, subtitles, and more.

Ogg is a free, open-standard container format supported natively by Firefox 3.5+, Google Chrome, Opera and most distributions of Linux. You can also watch Ogg content on OS X or Windows easily enough by installing the appropriate codecs. For our purposes, we’ll be dealing with the OGV container, which is specific to video. Within the OGV container, we’ll have two tracks: the Ogg Video track known as “Theora” and the Ogg Audio track known as “Vorbis”. Ogg file formats are on their way to becoming the standard way that Wikipedia delivers audio and video information, in hope of establishing this patent-free codec as the <video> standard.

MP4 is the container format of choice for Apple and most mobile platforms and is supported natively by Safari (Webkit), Flash video players, the iPhone, some Android phones, and also Google Chrome. Within the MP4 files we’ll be working with, we’ll again have two tracks: “H.264″ for video and “AAC” for audio. H.264, like Theora, is a video codec, but the comparisons end there. H.264 offers a plethora of options and features that are a result of it’s evolution over many years. If you’ve ever watched a trailer on Apple’s site, a BluRay movie, and HD video on YouTube, or downloaded a movie/television show through iTunes, then you’ve encountered H.264 in one of it’s many profiles. H.264 profiles are the key to its versatility, as different profiles best serve different mediums. The Baseline H.264 profile is supported on the iPhone and some Android phones, while the Advanced Profile is used by BluRay discs for the ultimate in video quality.

So, to recap:

Ogg

• Ogg is supported natively by Firefox 3.5+, Google Chrome, Opera, and most Linux distros
• Ogv is the container we’ll be working with
• The video track within an ogv container is known as “Theora”
• The audio track within an ogv container is known as “Vorbis”

MP4

• MP4 is supported natively by Safari, Google Chrome, iPhone OS, Android OS, OS X, and Flash video players
• MP4 is also the name of the container we’ll be working with
• The video track within our mp4 container is known as “H.264″
• The audio track within our mp4 container is known as “AAC”

Acquiring the Encoders

I’ll preface by saying that I had a hell of a time finding a reliable GUI-based Theora encoder. The Quicktime plugin was buggy and didn’t always output files as expected, even resulting in a few crashes. Firefogg, a highly recommended Firefox extension, simply did not work for me while dedicated encoding programs that I looked into, particularly Episode and Sorenson Squeeze, were both absent of the Theora codec entirely. This left me with the command line alternative: ffmpeg2theora. For those of you not comfortable working in the command line, fear not, as the calls to output a Theora video file are quick and easy. For exporting the H.264 video, I used the free (and incredibly nifty) Handbrake, which is available for Windows, OS X, and Linux.

You Down With Ogg?

After installing ffmpeg2theora, you’ll have to open either your terminal (OS X/Linux) or command prompt (Windows). From there, you can type “ffmpeg2theora –help” to get your bearings or just base your settings off of mine. After playing with a few variations of settings, the ideal preset for my project came out to look like this:

ffmpeg2theora –videoquality 6 –audioquality 4 –max_size 416×232 –optimize InputFile.mov

• videoquality X — where X can be any number from 0 to 10
• audioquality X — where X can be any number from -2 to 10
• max_size tells the encoder what the output size should be. If removed, input and output source size will be the same.
• optimize adds some time to the encode process, but gives you the best possible balance of quality and file size
• InputFile.mov can be almost any type of video container. A shortcut to inputting it is to simply drag and drop the file into your Terminal/Command Prompt after writing out the above settings

My uncompressed input file was 106MB at a resolution of 1280×720. Using these settings the file size came down to just a fraction above 16MB. I easily could’ve gone lower than that, but didn’t want any visible video degradation and anything below 20MB seemed like a reasonable streaming video size.

H.264 U

Encoding with Handbrake should be much easier for the average person since there’s a nice, clean interface in which to work. After launching the program, select your input source and, from the Preset Drawer, select “iPhone and iPod Touch”. This setting isn’t specifically for these devices, but more a good starting point from a compatibility point of view. From the top down, choose these settings:

• Container: MP4
• Make sure “Web Optimized” is checked
• Video Codec: H.264
• Framerate: Same as source
• Constant Quality: This is (very loosely) akin to Theora’s 0-10 scale and can be tested by enabling live preview in Handbrake to view your settings live on the video before committing to a lengthy encode. Power users could also simply specify a Target Size or Average Bitrate.
• Under the “Audio” tab, make sure that the Samplerate is 44.1 as 48 is overkill for web video.
• Click on the Picture Settings icon and then adjust the video to your desired size. You may also crop here if necessary.
• Finally, before submitting the export, you can click on the Preview Window icon to get a live, 5-60 second preview of your video with the settings you’ve chosen applied.

Going from the aforementioned uncompressed file I was able to get the MP4 down to 17Mb, which is a space savings of roughly 600% with relatively no visible pixel degradation or blurring.

The Code To Get It Done

The HTML5 code to embed a video is super simple and very much akin to using the <img> tag:

<video src=”MyVideo.ogv”></video>

You can take it a step further and add a width and a height, just like with images:

<video src=”MyVideo.ogv” width=”640″ height=”480″></video>

There are also a number of options you can add on to your video tag, they are: controls, autoplay, autobuffer. They’re all pretty self explanatory, and equally easy to implement. For example:

<video src=”MyVideo.ogv” width=”640″ height=”480″ controls autoplay></video>

The above line tells the browser to use it’s native controls for video and autoplay as soon as the page is done loading. You could swap autoplay with autobuffer to have the video begin downloading right away and then have the user initiate playback using the native browser controls. The options aren’t endless, but they’re certainly nice to have.

The only thing remaining is specifying which video will work in which browser. Rather than wasting away precious bandwidth by loading two movies and letting the browser decide which one it can handle, all you have to do is use the <source> element of HTML5 to tell the browser which video to download. The source element looks like this:

<video width=”640″ height=”480″ controls>

<source src=”MyVideo.ogv” type=’video/ogg; codecs=”theora, vorbis”‘>

<source src=”MyVideo.mp4″ type=’video/mp4; codecs=”avc1.42E01E, mp4a.40.2″‘>

</video>

So from that you can see that the video element no longer links to the file, but still contains the video attributes like width, height, autoplay, etc. Inside the video element we have two source elements that give us the path to the video as well as the video type, respectively. Note that the type attribute is wrapped in single quotes, which is a little weird, but this is due to the fact that the codecs have to wrapped in quotation marks for this to work.

Beware of the Mimes

I ran into a hugely frustrating issue where my development server simply wasn’t playing the OGV video natively in Firefox or Chrome, yet when I tested my code locally everything worked perfectly. I tried different character encodings, files permissions, and much more before I figured out that it was a simple issue of the server not understanding what the hell an OGV file is in the first place. There are two ways to remedy this issue:

1. If you’re the server admin *and you know what you’re doing*, you can edit httpd.conf and add the following lines to cover all variations of OGG media (one per line, do no include commas): AddType video/ogg .ogm, AddType video/ogg .ogv, AddType video/ogg .ogg
2. If you’re not the server admin but have FTP access, create a file called “.htaccess” in your root directory and add the lines you see above in the same format.

Note that the first method is a server-wide change whereas the second must be done on a domain-by-domain basis. Once I established my Mime types, it was smooth sailing.

In Summary

HTML5 video is exactly what a lot of people have been waiting for and, beyond learning a little bit about video encoding, should be comfortable territory for any proficient HTML coder. The only obstacle at this point is Internet Explorer, which seems to have no intention of supporting either file type now or in future versions. Though it would be easy enough to write a Javascript workaround to fallback on YouTube in the event of IE, the native implementation and seamlessness are really what make the HTML5 video element shine. In the web development world, where working drafts take years to be approved and the inhabitants argue fruitlessly over the minutiae of doctypes or trailing slashes, HTML5 video feels like an evolutionary first step in the right direction: An open web that utilizes open source tech to solve usability conundrums.

You can view my finished page here.