PBS station KLCS-TV employs a 28-channel Omneon Spectrum media server system to provide near-video-on-demand to 1 million students and teachers in Los Angeles.
HD playout is probably the hottest topic in the broadcast industry right now. It is especially of interest to buyers and manufacturers of video server technology. This interest is fuelled in large part by the accelerated adoption of new HD technology in the United States, Australia and Japan. And now the upcoming soccer World Cup and winter Olympic games have become the catalysts driving consideration of HD playout in the European market as big sporting events tend to drive technology changes.
While many view the adoption of HD as inevitable, we are clearly entering a transition period in which broadcasters of all kinds have to face the fact that they must produce programming for new HD-capable receivers, while simultaneously maintaining their existing SD revenue streams. After all, it will be some time before the majority of TV sets are HD. This type of transition has occurred before; the industry faced the same issues during the transition from black and white to full color.
The need for simultaneous HD and SD playout
Business realities dictate that broadcasters have to offer programming in SD. They need to maintain their current revenue stream while also offering HD programming in order to future-proof that same revenue stream. That's the first point.
Two Omneon Spectrum media servers support production and playout tasks at WCPO-TV.
The second point is that there is a vast library of legacy material in vaults worldwide that was captured in SD, and these libraries will still have great value as we move toward the HD world. Both of these points lead to the simple conclusion that HD output will need to be created from material that was originated in SD.
As we move through the transition period, it is foolish to arbitrarily limit our SD output to material that originated in the past in SD; the ability to generate SD output from new HD material is a clear need. And so there is a real necessity to crossconvert SD and HD material as we navigate our way through the transition period and beyond. No one is going to convert all their legacy material to HD all at once; it will be a process that continues for some time.
Figure 1. Generating simultaneous HD and SD content. Click here to see an enlarged diagram.
Thus, we find that many manufacturers are now offering the ability to mix SD material and HD material on the same timeline (i.e., the same server output channel), under the control of a single channel of automation. While most offer this capability via internal up-/downconversion, some offer the additional ability to use external equipment for this function. In any case, up-/downconversion is a reality in the current business model. (See Figure 1.) But simply solving the frame/line structure issue is not enough. We have to consider the question of aspect ratio.
Aspect ratio conversion
Almost all HD material originates in widescreen 16:9 format, and almost all SD material is 4:3. Because letterboxing doesn't happen by itself, this is the first point of consideration when up-/downconverting material.
The simplest and most tempting approach is to set the crossconversion once and leave it. In the broadcast world, however, there are always exceptions that have to be taken into account. For instance, while most SD material is indeed 4:3, there are many regions where SD has been shot in 16:9. SD can even be shot 14:9, a compromise standard used in Europe, which minimizes the black bars when projected on to a 16:9 screen, while losing the minimal amount of picture information when projected onto a 4:3 screen. Or consider an anamorphic squeeze, where the aspect ratio of the actual pixels is altered in order to easily fit 16:9 into 4:3 to pass through legacy equipment.
These exceptions to the rule force alternate approaches, such as the idea of having clip-dependent aspect ratio conversion (ARC) as a requirement. There may be no control over the aspect ratio of the material received, but it can still be converted to be presented in the best way to the viewers. Clip-dependent ARC will probably successfully address most of the issues a facility will face, but the topic is laced with additional complexities.
Consider the following scenario: A piece of material originates as HDV (16:9) and, in some external process, is letterboxed for SD projection. Finally, it arrives at a facility, where an ARC is performed to produce an HD output. Unless the original aspect ratio of the material is taken into account, the letterboxed material will be pillarboxed, resulting in reduced active picture area.
There are ways to resolve this problem, basically requiring that a history of the ARC previously applied to the material be encapsulated with the clip itself. Within the server infrastructure, the easiest way to do this is in the metadata included as part of the file structure of the clip. However, external to the server infrastructure, the information probably needs to be carried in the video stream itself.
Closed captioning
Just like the aspect ratio issue, closed captioning needs to be taken into account. In SD, EIA 608 is the standard for the inclusion of closed captioning in a digital signal. In the HD domain, there is the EIA 708 standard. As part of the real-time conversion process, the closed captioning information needs to be crossconverted, and most servers accommodate that functionality within their I/O channels.
In Europe, though, the situation is not so straightforward. There is no ratified standard for carrying closed captioning and subtitles in the HD signal. This will need to be dealt with quickly, and users and manufacturers will no doubt unite in bringing this to conclusion within the next year.
Control/timecode
Figure 1. Generating simultaneous HD and SD content. Click here to see an enlarged diagram.
Finally, consider the idea of automation and the timecode implications of progressive material. Automation systems use the frame rate information — 29.97fps in the United States and 25fps in Europe — to calculate the duration of a specific clip. But now in this transition period, we introduce the intermingling of HD and SD material on the same timeline, which isn't a problem until we consider the issues of progressive material, running at 50fps or 59.94fps. (See Figure 2.) We can have slower frame rates in progressive, but the motion tends to be jerky.
The problem is how to describe the timecode. How do we represent 60fps (rounded up, of course) to an automation system that's expecting 30fps? The answer is that in most cases, we sidestep the issue, treating a pair of frames as if it's a pair of fields and trick the automation by presenting 30fps timecode. It is a trick, but it works. We've been dealing with an accuracy of 1/30th of a second for years, so nothing is lost. However, it must be taken into account if counting frames through an API, and most servers offer an API for partners to exercise greater control over their operation. None of this is insurmountable, nor does it necessarily cause any problems, but the user should be aware of the issue so as to ask the right questions of vendors as they migrate to the HD world.
Conclusion
There's more to think about in the playout of HD and SD in a server infrastructure than just the video. The good news is that these issues are well understood by vendors, and compromise solutions are in place to deal with the corner cases. These issues will be with us for some time, so it certainly makes sense to consider the pros and cons of each approach as you make your own plans to adopt HD in your environment.
Paul Turner is vice president of product marketing for Omneon Video Networks.
