You are here: Home Page » HDTV » NBC delivers three-screen Olympics

NBC delivers three-screen Olympics

Oct 1, 2008 12:00 PM, By Brad Dick

Here’s how the network produced everything from HD to Web and mobile programming using IT and IP technologies.

Home sweet home

David Mazza, vice president, engineering-Olympics, NBC, began his Olympic career at the 1996 Summer Olympic Games in Atlanta, GA. Since then, he’s headed up each NBC Olympic broadcast from locations around the world. At the Beijing Olympics, he met with Broadcast Engineering editorial director Brad Dick (shown on the right).

Another transformation in the network's Olympics workflow was to further build on its substantial and successful work-at-home effort. Beginning with the Winter Olympics in Torino, NBC experimented with doing actual content assembly in the United States. The process involved sending material back to New York so U.S.-based editors and staff could assemble final content. Not having to transport, house and support hundreds of production people at a remote location could result in significant cost savings. Mazza's support of this concept really shined in Beijing.

The work-at-home production was spread across eight U.S.-based control rooms. Five were at NBC headquarters at 30 Rock, one in New Jersey, one in Florida for Telemundo, and one at SoHo in lower Manhattan for the foreign language feeds. The work was divided into three types of programming: the off-tube factory, where voice-overs took place; the streaming factory, where new media streaming content originated; and the highlights factory, where SD and HD clip-based material was assembled.

While the Torino games required only 14 program feeds back to the United States, more than 100 separate program feeds were in place this year. Forty of these feeds were Web streams. The remaining feeds were a combination of HD and SD signals. NBC streamed more than 2200 hours of content for the Summer Olympics.

A 6000 mile remote

Because of the long distance between Beijing and the United States, any remote production solution had to meet three criteria. First, the content had to be resolution-independent. That's because the network needed to deliver content at rates ranging from 50Kb/s for streaming feeds to 50Mb/s for HD. Second, the solution also had to be location-independent. While the content originated in Beijing, production needed to occur in New York. Finally, the solution had to support a file-based workflow.

So what is the major challenge in producing content 6000mi remote?

“The first is physics,” Mazza says. “It requires about 240ms to loop the signal via fiber between Beijing and New York. This places unique requirements on any file-based content passing through routers.”

Figure 1. A key component in NBC’s production of more than 2200 hours of streaming content, in addition to the work-athome project, was Omneon’s MediaDeck, MediaGrid and ProCast CDN. Combined, they allowed the network to create both Web and HD content with a U.S.-based staff.
Click to enlarge

A key component in the work-at-home solution was provided by several Omneon products. (See Figure 1.) Twenty-two Omneon MediaDeck servers supporting 44 channels of ingest were based in Beijing, handling both IMX and XDCAM HD files. These servers also automatically generated matching low-resolution proxies for transmission to the United States. Both high-resolution and proxy files were then stored on a Beijing-based MediaGrid server. Eight channels of MediaDeck servers and another MediaGrid server were located in New York.

Once the content and proxies were generated, the proxies and some HD content needed to be sent back to New York. For this task, NBC used an Omneon ProCast CDN file transport engine. The ProCast CDN is designed to quickly move large files over long distances and yet remain unaffected by path length.

“TCP/IP sends a small blast of data, and then very quickly after transmission, it listens and says, ‘Did you get that?’ And if it doesn't get a response, it assumes that you didn't get it, so it sends it again,” Mazza explains. “However, with 240ms of delay, this could just result in chatter. ProCast overcomes this issue through the use of several transfer protocols.”