With all that's going on around video over the Internet, I thought I'd put down some of the basic concepts involved. A company looking to embrace Internet video will need to fully understand each of the following components of an Internet video ecosystem.

Video Codec
You're going to need to choose how to encode your video. Raw video file sizes are still far too large for playback over the open Internet. A video codec takes the raw format and uses math tricks to "compress" it. You use an encoder to "compress the video" and a decoder to "un-compress" the video right before you play it. You can't play "compressed" video the same way you can't get at a word doc in a zip file until you unzip it. The most common video codec is h.264 but it's not free. At a certain point you have to pay to use it and you pay a lot.

Audio Codec
You'll need an audio codec to compress audio just as you need a video codec for the video. You'll need an audio encoder/decoder as well. The most popular formats are AAC and Dolby's AC3. Neither of them are free.

Container Format
Here's where things get interesting. You're going to need to bundle your audio and video together and send it over the Internet to a video player. The most common container format if you're using h.264 has been either MPEG 2 or MPEG 4. Broadcast television is sent to your TV wrapped using an MPEG2 container. The Flash Video (flv) container is also very popular. Many container formats support embedding other content in them including closed-captioning information, multiple audio tracks, etc.

Video Player
Lastly, you're going to need a video player that can un-bundle the content from its container format, decode the audio, decode the video and play the content - preferably embedded within a web page. The video player will fail to play the content if the viewer's computer doesn't have the audio and video codecs installed on the local computer that correspond to the audio/video codecs used to encode the content in the first place. Flash remains far and away the most popular video player used in web pages to play back video. However, there are some challenges.

Psuedo Streaming over the Web
Traditionally, video players, Flash included, begin downloading the video content over the Internet and bring down the bits of the file a piece at a time. If the video player can't download the content fast enough, eventually there's nothing to play and the player will stop playing until it catches up - very annoying. Also, jumping around inside the video timeline to watch from a new place in the episode or movie can be very problematic. Remember, traditionally the content is one big file being retrieved over the Internet. So, for a long time you couldn't jump to a place in the video you were watching until you had downloaded the content up to that point in the episode or movie. Google's YouTube and others got around the problem of not being able to jump to an arbitrary location in the video by supporting something called pseudo-streaming.

Pseudo streaming requires a program on the server to intercept a request to retrieve a huge video file and instead return part of a video file. A video player will ask the server to retrieve the file starting from a specific place within the file. While not perfect, this solution is good enough and everyone from YouTube to CBS.com used this approach to let viewers click to anyplace in a TV show or video and start playing. Pretty much everyone used this technique until a year or two ago.

Chunked Video Streaming over the Web
Three or four years ago, the company I worked for, Move Networks, invented an ingenious way to deliver video. They broke a single TV show or movie video up into lots of independent video files, each a valid movie with a complete container format wrapping the audio and video. Each file contained just a few seconds of the content. Then, they also encoded the same small chunks of video over and over at different quality levels resulting in small files that varied in size from just a few kilobytes to several megabytes. They created their own video player that would get the highest quality chunk of video it could before it ran out of content to play and stopped. This made the time it took to start playing content a second or less and also made jumping from place to place in the video timeline nearly instant.

Just over a year ago, both Apple and Microsoft copied this approach nearly exactly. Since then open source solutions have emerged that emulate this approach to one degree or another.

Google's blog from the first day of Google I/0 2010 included a very important announcement whose significance some may have missed. Google announced WebM with a website for its tools and code. "The WebM project is dedicated to developing a high-quality, open video format for the web that is freely available to everyone."

I spent a few years working for Move Networks, a pioneer in the Internet Video space, and right now I'm helping a different company create a solution that revolves around capturing, transcoding and delivering high-quality video over an IP network. Many companies are adding video to their various products and solutions and those that haven't yet have it on the drawing board for the near future. The following provides some insight into some of the questions a company will need to answer in deciding on a solution.

Jump over to my Internet Video Primer if terms like pseudo streaming and chunked video are foreign to you. It's pretty short.

I've chosen Flash as an integral part of the solution I'm helping create at my current company, despite the fact that I can't stand Flash. I chose it because there really isn't a good alternative yet. We're encoding our content here in h.264 because the ecosphere around h.264 is so mature and complete: we're using h.264 encoders (hardware and software), our transcoding tools work well with h.264 and of course Flash play s h.264. Still, there are some serious problems with this solution that will wind up costing this company a lot of money in the long term and Google's WebM project could eventually solve these problems.

Problem: h.264 interoperbility
h.264 is a kitchen sink format, attempting to provide the best possible quality/size trade-offs for high to low quality and high to low encoded video size and the result is a very complicated format that often causes interoperability issues as you move from device to device and player to player

WebM Solution: VP8
I learned that Google acquired On2's VP8 not quite a year ago and like most in the industry realized that the slick VP8 codec, a much more focused codec, could help with some of the h.264 interoperability issues.

Problem: h.264/aac codecs are proprietary
The most popular video and audio codecs out there are proprietary and you have to pay to use them. This isn't a problem for many small companies initially because you don't usually pay until you get a lot of eyeballs and even then often you're using technologies that have payed for the right to use these codecs for you. However, with success a company can quickly find itself paying large licensing fees if they're not careful. Also, the proprietary nature of these codecs inhibits more video players and encoding technologies from embracing them.

WebM Solution: VP8 / Vorbis
Google paid a grundle for VP8 and has now made it free as in beer. Companies can use VP8 for video and the already open source Vorbis for audio. I used VP8's predecessor, On2 VP7, for years and was very pleased with its quality. VP8 is supposed to be a lot faster to encode and decode with the same quality.

Problem: proprietary video players
Flash remains the de-facto standard for playing back video over the Internet in a web page. Flash has some serious problems. It's extremely slow. Flash is a general-purpose animation platform. It doesn't actually play video that well compared to video players that specialize in just playing video. Flash takes more horsepower to play video than it should and I just don't want to be locked into a single vendor, Adobe.

WebM Solution: HTML 5 with VP8/Vorbis
HTML 5 is a set of emerging open standards for creating sophisticated, next generation web pages. It includes a brain-dead way to play video that lets the web browser pick any installed video player that can play the content. Apple and Adobe have fought Google on this standard because both Apple and Adobe are highly motivated to cripple how truly "open" this standard is so that their proprietary video players remain relevant: Apple Quicktime and the Adobe Flash Plugin. Google has given the HTML 5 video playback standard some real teeth by providing an world class, truly free video codec.

So, does Google's WebM bring nirvanna to small companies wanting to embrace video over the Internet? Unfortunately not, at least not yet. The entire industry has moved to h.264 video encoding and it will take some time to create a sufficiently mature ecosphere around VP8 to gain widespread adoption. It's also possible that Google is too late and that WebM will fail to reach the critical mass necessary to convince device manufacturers, content owners and video management companies to embrace it. We'll see.

There are a few factors in Google's favor here. First, Google's already converting its YouTube content to the new VP8/Ogg approach. YouTube all by itself is a force powerful enough to sway an entire industry. Then there's the fact that Google's wagon is hitched to HTML 5 and make no mistake, HTML 5 is going to win and win big. Developers, whether creating desktop apps or mobile phone apps, are already embracing it. Lets see, on one side I've got tons of infrastructure and support but I'm encumbered with license fees and on the other I've got Google and free. They're going to win a lot of developers over quickly.

Stay tuned. It should be interesting to see how this all shakes out.

A veritable cornucopia of web application approaches and frameworks, some old school and some new school, confuse even the most experienced. This article attempts to delineate the most popular of the approaches and the reasons why one would adopt one over another for a project.

It's time to move bxgrant.com forward in time with JPA, JSF and JBoss Rich Faces. This article explains how I've begun the effort by migrating to JPA from iBatis and highlites the benefit of clean, simple, enterprise architectures which make doing this piece-meal update possible. Look for future articles on JSF and Richfaces

I've been meaning for years to document how I created my web site using enterprise Java tools and design patters but still kept things simple and fast to develop. This article describes the approach I've taken to solving common problems of persistence, separation of cross-cutting concerns, scalability and UI.

This article provides a high-level review of three  Java UI frameworks I've used and explains the basic approach, positive and negative qualities of each - Apache Tapestry, Apache Velocity and Sun Java Server Faces.

This article delineates the many tasks necessary for releasing a high-quality software product that are often overlooked during software planning phases.

The power, flexibility and development velocity of modern scripting languages makes them attractive to software engineering managers everywhere. If your project only lives a few years then very little if any discipline is really needed. However, if your product is successful and you have not instituted sound engineering practices from the get-go you may find yourself in a world of hurt with code that is brittle, difficult to maintain and that actually impedes your ability to make quick changes. This article provides a few simple tips based on my experience creating two large, enterprise-scale systems using two very different scripting languages: JavaScript and Lua.

This article provides a simple example of using SSH to forward web content from a port on a remote server to a port on a local computer and view the content in the local web browser. It's not meant to be a comprehensive guide on ssh or port forwarding. Instead, it's meant for the relative Linux novice who needs to figure out how to do simple port forwarding. A basic knowledge of using ssh to log into a server is required.

This guide will walk through how to install and configure a Tomcat application server tied into Apache using mod_jk on a newly installed Ubuntu Linux Server and is meant for the complete Linux novice. The guide assumes readers have a moderate degree of experience with Tomcat, Apache and Java and application servers in general. This is the sixth installment of a series of articles explaining the technologies used to bring this web site online.

This guide will walk through how to install and configure an Apache web server on a newly installed Ubuntu Linux Server and is meant for the complete Linux novice. The guide assumes readers have a moderate degree of experience with Apache and web servers in general. This is the fifth installment of a series of articles explaining the technologies used to bring this web site online.

This guide will walk through how to install and configure a DHCP server on a newly installed Ubuntu Linux Server and is meant for the complete Linux novice. The guide assumes readers have a basic knowledge of DHCP and networking principles in general. This is the fourth installment of a series of articles explaining the technologies used to bring this web site online.

This guide will walk through how install and configure a Bind9 DNS server on a newly installed Ubuntu Linux Server and is meant for the complete Linux novice. The guide assumes readers have a basic knowledge of DNS and networking principles in general. This is the third installment of a series of articles explaining the technologies used to bring this web site online.

This guide will walk through how to configure a newly installed Ubuntu Linux Server and is meant for the complete Linux novice. This guide does not claim to be the ultimate authority on the best way to configure Ubuntu. Instead it explains how I like to configure Ubuntu from the standpoint of a Linux novice. This is the second installment of a series of articles explaining the technologies used to bring this web site online.

This guide will walk through how to install an Ubuntu Linux Server and is meant for the complete Linux novice. This guide does not claim to be the ultimate authority on the best way to install Ubuntu. Instead it explains how I like to install Ubuntu from the standpoint of a Linux novice. This is the first installment of a series of articles explaining the technologies used to bring this web site online.