U2, YouTube, And The Future Of The "Boob Tube"
I’m a pretty big U2 fan, so Sunday night I caught the live streaming performance of the band’s Los Angeles concert on YouTube. As I’ve written before, live-streamed video is a far more technically challenging endeavor than traditional server-to-client Internet-delivered content, predominantly due to two factors:
- Its multicast (one source to many destinations) topology nature,
- The unknown number of destinations at any point in time, along with the variability of viewer numbers across time, thereby requiring constant re-balancing of capability versus cost, and
- The variability of the bandwidth between the source and each of the destinations, along with consumers’ lack of tolerance for any consequent degradation in quality
With all of those potential pitfalls in mind, I was really impressed with how well YouTube pulled off the performance. Granted, the video frames were only 480×292 pixels in size, so Bono and the rest of the boys were a bit blurry when expanded full-screen to the native resolution of a 1440×900 pixel LCD. And granted, the sound was two-channel in nature, not surround sound. But considering that the alternative was a 10-hour one-way drive to the Rose Bowl, coupled with buying a scalped ticket for a nosebleed seat in the parking lot at a few hundred dollars, I’m pretty happy with the free view we had from my futon
The presentation was somewhat jerky indicative of dropped frames, but a bit of experimentation with different computers confirmed my suspicions that the root cause was a shortcoming on my end of the connection. I initially hoped to be able to watch the concert through my Apple TV HDMI-tethered to my 37" LCD TV, but the live stream ended up only being viewable via the web page of U2’s YouTube channel. I could have put a notebook computer on my lap, but instead I fired up my dual 1.8 GHz G5 Power Mac connected to a 19" widescreen LCD.
Although the Power Mac runs modern Mac OS 10.5, it’s based on archaic PowerPC CPU technology. Its graphics processor also doesn’t hardware-accelerate MPEG-4 video decoding. So what I was encountering wasn’t an insufficient sustained bit rate coming from the YouTube servers but instead was a system with completed consumed CPU resources. Now that the show is over, it’s up on YouTube in more conventional form. Enjoy!