What is so difficult about broadcasting MLB.TV?

As a member of the development team for the Major League Baseball MLB.TV project, I've had a somewhat unique perspective on the successes and failures of the project. There is a bit of backlash in the blogosphere about the technologies surrounding the players, and the inherent superiority of one technology over the other. This post examines only the technologies involved in the situation, and not any of the underlying business decisions surrounding it.

So, what is so difficult about broadcasting MLB.TV? Funny you should ask, regardless of all the Flash vs Silverlight debate that has surrounded the MLB.TV launch this year, the player itself represents only about 10% of the complexity. So, how does it all work? There are a series of inter-related processes involved.

1. Acquisition of feeds – Home and away video feeds from the ball park are provided by the networks covering the games. If there are problems with those feeds, the video/audio never makes it to MLB. As an example of this, in one of the opening games, an unplugged cable in the feed truck was responsible for lack of an audio feed in the MLB.TV player. There are any number of things which could go wrong at the ball park or in the broadcast trucks to provide the signal. Assuming all is acquired properly, the next step is...
2. Encoding of feeds – The video and audio content streams from the broadcasters at the ballpark across the network to the MLB Advanced Media offices in New York City. There, the data is encoded into various formats for the various players, including MLB.TV, Gameday Audio, iPhone, etc. For MLB.TV, the stream is encoded at 7 different bit-rates, so the proper quality of video can be delivered, based on the end users connection speed to the internet.
3. Provisioning – As a game starts, all of the data about the game and the feeds available for it needs to be provisioned into internal systems at MLB. This data is used by all the various applications to determine what game's are available, what feeds are available for each game, and which qualities are available for each feed. If one of the encoders fails, or one of the feeds drops, or anything else goes wrong in steps 1 and 2, the data needs to be re-provisioned to reflect the current accurate data for a game.
4. Services - There are a series of Java based services which consume the provisioned data, and make it available to the player and other applications. Amongst the jobs the services provide are login, authentication, geo detection (to help enforce blackout restrictions), managing stream security and more. Of course, these services are dependent on the data about each game being available and accurate.
5. Streaming Servers – There are dozens of Flash Media Servers at the Content Delivery Network (CDN) partner of MLB, from which all the video and audio (and lots of other things too) are streamed to the end user. The CDN has the capacity to stream hundreds of thousands of games at once.
6. MLB.TV player – While this is the only part of the process most end users see, this is merely a front end to all the systems described above. While we are constantly finding problems, fixing them, making improvements, testing to ensure we haven't caused other problems, 99% of all bugs reported in the Forums and MLBlog actually relate to one of the "upstream" elements of this system. As I mentioned earlier, an unplugged cable caused hundreds to complain that our flash version of the media player couldn't properly play sounds. Obviously, that wasn't the problem, as all the other games, and even the other feed for that game properly had the audio channels playing, it's simply a matter of the player playing the content which was provided to it.