At U.S. broadcast stations, the implementation of DTV is unique. That’s because a single MPEG-2 transport stream with a bandwidth of approximately 19.4Mbps carries different mixes of HD and SD content during the course of a day. A typical scenario is to broadcast one HD program (or one HD plus one SD) during primetime and send multiple SD programs the rest of the day.
A direct consequence of this is that some programs in the ATSC transport stream keep switching back and forth between "active" and "inactive" states. This raises some major concerns among broadcasters: If an inactive program is simply not present in the transport stream, what happens if a DTV receiver tries to tune to that particular program? There is no firm answer to that question (and chances are two different receivers won’t behave the same way). Typically though, this could mean confusion, if not frustration, for the viewer.
Through its PSIP specification, the ATSC DTV standard defines the mechanism to signal an inactive program: The program is not present in the transport stream and thus is not described in the MPEG-2-defined PAT and PMT tables. It is listed in the PSIP-defined VCT table with the "hidden" flag positioned. The beauty of this mechanism is that only a few bytes in the VCT are needed to reference the inactive program: This is the most bandwidth efficient way to advertise a program that is not being broadcast.
Unfortunately, what ATSC and PSIP don’t define is how a receiver should handle that "hidden" flag. Should it tune to the first active program with the same major channel or maybe tune to a vendor-defined default program? In a perfect-world scenario, all receivers would indeed seamlessly tune to the first active minor channel with the same major channel; just as the perfect-world local cable operator would agree to carry the full ATSC transport stream unmodified.
Since this is not a perfect world and since DTV is right here, right now, a possible solution to that inactive program issue is gaining momentum among broadcasters: Why not maintain a low-bit rate video/audio barker channel for the programs that are temporarily not being broadcast? This barker channel (also referred to as a "trickle stream") could be a simple static "slide" explaining when the program will return and to what minor channel to tune. Not only would this inform the viewer about the situation, it would also guarantee that the receiver always has a video and an audio PID with which to work.
One implementation of that "trickle stream" concept consists in feeding all the programs (the HD and the four SDs from our initial scenario) to a statistical multiplexer and then switching the video source (between the program content and the barker slide) at the encoder’s input. If the "stat mux" is set up properly (with, of course, an output rate never to exceed 19.4Mbps), the HD and SD dynamic encoders should automatically use a very low bandwidth when fed with a static slide.
Compared to the "hidden" flag mechanism however, this solution transmits five videos at all times, so the key question remains, "How low can a realtime encoder really go?" Besides, not every broadcaster has invested in a high-end stat mux system.
In order to reach the lowest rate for a static barker channel, the best approach should be to use non-realtime software encoding. A pre-recorded, software-generated barker channel could theoretically be as low as the MPEG-2 compression can go. Thus, a different implementation of the "trickle streams" would be to switch the video in the compressed domain at the elementary stream level.
The video and audio PIDs remain the same and, in fact, the overall PSI/PSIP definition of the program is unchanged. This stream manipulation is known as splicing or sometimes digital program insertion (DPI) and when performed correctly is transparent to the receiver.
Since a barker channel can be pre-recorded as a transport stream file ahead of time, it can be stored in a server-like device that loops on the barker file when the corresponding program is inactive. Also, the HD and one of the SDs can share the same program number and the same video/audio PIDs in order to reduce the number of "trickle streams."
This might seem like a lot of work, but the goal is to make DTV viewing easy for the public. We’re the engineers; the engineering part should be on our end.
George Anderson and Jean Macher are, respectively, multimedia product line manager and sales manager, digital services, for Thales Broadcast & Multimedia.
