Selecting an in-house HD format can sometimes be an easy decision. However, for one network (which has asked to remain anonymous), making the correct technical decision proved to be more difficult than the engineering staff expected.
What finally led to the solution was a simple, yet effective, document: a written test plan. This test plan gave manufacturers something to commit to (or not). It gave operators, producers, talent and crafts people a way to participate. The document provided engineers with technical work to sink their teeth into. Perhaps most importantly, it gave management a tool for evaluating how the selection and implementation process was progressing while under the gun of an immovable HD launch date. The following is the story of how that network succesfully established an HD house format.
HD streams vs. files
It wasn't difficult to select an in-house streaming video format. That was settled early in the project because decisions had to be based primarily on hardware availability. Given the timeframe and the need to support a wide variety of operations, there was not enough equipment available that could provide interconnects to either the SMPTE 372M or 424M 3Gb/s SDI interfaces. This led to the selection of SMPTE 292M 1.5Gb/s for routing and distribution of 1080i video with embedded audio. One downside of the requirement for a quick decision is that it effectively eliminated using 1080p.Today, 372M and 424M are widely supported, so 1080p is a candidate for an HD infrastructure.
The design process
The broadcast infrastructure was designed around SMPTE 292M. Without minimizing the complexities involved, the work was straightforward. The network followed manufacturers' recommendations for things like Dolby E audio subrouting, up/downconversion to local confidence monitoring, and sync and delays.
Unfortunately, when it was time to choose input and output ports for the facility's video servers, which was a seemingly trivial technical selection, the team hit an impenetrable wall. It seemed impossible to select a compressed HD file format that would meet the facility's needs.
By the time the network went live with HD satellite feeds, it was still unfeasible to order those pesky video server ports. This posed a schedule risk worthy of escalation to the executive level. (See Figure 1.)
Compressed HD files
This schedule risk existed for a few months. It was difficult for the network to resolve the trade-offs. Some compression formats are better for editing, while others are better for transmission. Some file wrappers are more suited for news systems, while others are better for archive restoration and long-form production. Certain software applications and workflows are better for human interaction, whereas others are better for automated control and message-passing.
The network documented its workflows and mapped them to new equipment and improvements. New workflows were planned to include digital asset management versus tape dub orders, and browse proxies versus tape carts from the library. Everything worked out on paper except for those video server ports. The ports themselves weren't the problem per se. Server manufacturers offered a variety of compressed HD formats and SMPTE 292M compatibility. The problem was making a network commitment to a compressed HD file format so the right ports could be ordered in the accurate quantities.
Navigating the trade-offs
P2 cards from the network's field cameras familiarized craft people with using DVCPRO HD at 100Mb/s. But video server manufacturers weren't planning to support that format until after the network's studios switched to HD cameras. The network would, therefore, have to transcode months of video from an interim format to DVCPRO HD for permanent archive and workflows. And 100Mb/s is a lot of bandwidth even over Gigabit Ethernet.
MPEG-2 HD was available at lower bit rates between 50Mb/s and 140Mb/s,wrapped as MXF in some workflows and as QuickTime in others. Engineering calculated that it could transfer 50Mb/s to 80Mb/s files across Ethernet quickly enough, and could install dual network cards into workstations. Local traffic congestion could be relieved with a Fibre Channel SAN for day-of-air storage and collaboration. But how would the network's editing computers perform with large files and high bit rates if they also had to calculate through long GOPs?
Editing HD MPEG-2 works better with all I-frames, but would the video from the new HD studio cameras look good enough for all of the network's needs? The network also had to weigh the options of either using MP@HL and losing those two color bits (4:2:0) versus 422P@ML and losing the 1080 raster size (from 720).
Editing and graphics departments naturally had differing points of view. Some manufacturers offered 422P@H-14 or 422P@HL equipment within the network's timeframe, but these were not yet demonstrable when integrated at a comparable operational scale with enough proxy generation. Because of HD file sizes, many network workflows have to rely on proxy video at least part of the time.
Web, graphics and promo workflows suggested HDV in a QuickTime wrapper for easy interchange between software applications. The broadcast side of the house supports the network's Web site with timely video elements and a rapid workflow. The national marketing and advertising operation demands the highest resolutions, so YUV and RGB color space tranforms had to be minimized. But for broadcasting, HDV QuickTime required major changes to the network's graphics systems, transmission elements and automation-assisted master control.
To complicate matters, AVC-Intra was looming on the horizon, and transcoders were turning in faster benchmark performance times.
Birth of a test plan
The test plan started as a simple question during rack layout discussions. Could the news operation count on editing-in-place in HD? If not, SD and HD VTRs would have to remain in the satellite feeds area and edit suites. The network brought in hardware HD codecs to see if edit-in-place in HD was practical. (See Figure 2 on page 92 and Figure 3.)
While brainstorming a benchmark test platform to measure edit-in-place-in-HD durations, the network realized it could collect video quality evaluations from producers at the same time. The combination could help select an in-house HD file format that would work for everyone. Building a benchmark platform was routine, but the network realized immediate value from its documentation package. (See Figure 4.)
When the simple edit-in-place test area was asked to also serve as a place where video producers could evaluate video quality, that larger group of stakeholders required more coordination and therefore more documentation. The following is a list of that documentation and its effects:
- List of participants and schedule. This engaged production, operations, engineering, IT and management.
- Executive summary: objectives and methodology. The process of defining these proved controversial, and as each dispute was resolved, the network removed another technical variable from consideration.
- Drawing and bill of materials. These illustrated exactly what could be obtained and when. Since they included known specific model numbers, they cleared up ambiguities and greatly simplified the choices to select from.
- Pretest checklist. This isolated the effects of the broadcast network infrastructure, such as pings, permissions and directories.
- Test sequences. These defined where, when and how video quality could be, and needed to be, evaluated. Screenshots were taken and published, and this brought to light any software that was not ready for testing.
- Test results. This included an executive summary, recommendations and detailed compilation.
Conclusion
Although the selection process was arduous, the network relied on a time-proven test plan process that worked. Surprisingly, it never had to turn on the benchmark system. Once the test plan was clearly documented, all the stakeholders made their choices and commitments without seeing a single frame of video. They just needed a clear model that defined what and where the trade-offs were.
Josef Marc is vice president of media systems and operations for tps Consulting and consulting director of systems and partner integration for SAMMA Systems.
