This is the question many broadcasters find themselves asking now that the FCC has ordered all U.S. terrestrial DTV stations to include PSIP in their broadcasts by February 1, 2005.
To understand just what is required, it is helpful to first read one of the pertinent passages from the actual FCC Report & Order. (If you would like to access the full Report & Order from the FCC, go to http://hraunfoss.fcc.gov/edocs_public/attachmatch/ FCC-04-192A1.doc.)
“We conclude that adoption of ATSC A/65B (PSIP) into our broadcast transmission standards will serve the public interest. As pointed out by commenters, during the development of PSIP, the ATSC carefully considered which elements of PSIP should be mandatory and which should be optional...We therefore require that broadcasters fully implement PSIP to the extent that ATSC A/65B requires. In order to give broadcasters adequate time to come into compliance, this requirement shall take effect 120 days after publication in the Federal Register. We expect broadcasters to populate the required tables and descriptors with the proper information to help receivers assemble functioning guides. All tables and descriptors that require one time setup should be set correctly, including TSID, Short Channel Name, Service Type, Modulation Mode, Source ID, and Service Location Descriptor. ATSC A/65B also requires that broadcasters send populated EITs covering at least a 12 hour period. These EITs should be populated with the correct information, so that the user knows what programs are on for this 12 hour period. Also, we expect that manufacturers will have every incentive to build equipment that looks to PSIP for its basic functionality, but we will revisit the issue if necessary. Standardized use of the data transmitted through PSIP will ensure that the full benefits and innovations of the new digital system will be available to the public.”
I have italicized certain portions of this passage for the purposes of this article. Let’s look at those individually:
All tables and descriptors that require one time setup should be set correctly, including TSID, Short Channel Name, Service Type, Modulation Mode, Source ID, and Service Location Descriptor.
The implication here is that you set up all of these attributes correctly in your PSIP generator. Since these are “static” elements of PSIP, you should only have to set them up once, save them, and not have to worry about them again. This is the easy part. The rest of what the FCC requires implies “dynamic PSIP,” which is not quite so straightforward:
ATSC A/65B also requires that broadcasters send populated EITs covering at least a 12 hour period.
EITs are Event Information Tables within PSIP. These contain the basic program guide information that allows the consumer to see what programming you’re currently showing, and what’s coming up. These include information such as show name, start time, and duration of the entire program. ATSC A/65B actually requires that the first four EITs (EIT-0 through EIT-3) are sent, each containing three hours of events. However, as programs are completed in the current EIT (EIT-0), it will reduce from three hours, eventually down to zero, meaning that right at the end of EIT-0, you will only be sending out nine hours of EITs (basically EIT-1 through EIT-3). Although the FCC Report & Order specifies a minimum of 12 hours, the actual A/65B standard that they cite really only requires this nine- to 12-hour range covered by EIT-0 through EIT-3.
These EITs should be populated with the correct information, so that the user knows what programs are on for this 12 hour period.
The key word in this sentence is “should.” As a colleague very familiar with these things pointed out to me, in FCC parlance, “should” typically means “we highly recommend you do this, and if you don’t, we’ll make you.” So, if you accept that, you need to make sure that the information you send out in these EITs is accurate.
How Accurate Is Accurate Enough?
If you’re currently populating your EITs based on information from a listing service that might be two weeks old, that may not be accurate enough. Where do you get more accurate information regarding program names, start times, and durations? Well, your traffic and automation systems certainly have this information.
If you want all of this information to be as accurate as possible, an interface from your automation system to your PSIP generator is required. However, would getting this information from traffic be good enough? To answer that, we must address another question.
How Many Hours Of EIT Information Should I Be Sending?
Although the minimum requirement in A/65B is the next four EITs, covering 9-12 hours of programming, is that really enough? If you want your viewers to have a good experience, probably not. The ideal amount of EIT information to send out may be more along the lines of several days’ worth. There are a couple of reasons for this:
Digital Video Recorders (DVRs), also known as Personal Video Recorders (PVRs), that use PSIP data are coming to market. It’s a fact of life that an increasing percentage of your viewers are time-shifting using these devices. If you want to ensure that they properly record your content (and ultimately view it), you need to provide PSIP information far enough in advance for these devices. The farther in advance you can provide this information, the better. Many store seven days’ or more worth of guide information.
The other reason to consider sending out several days’ worth of EIT information is for traditional live viewing of your services. Yes, thankfully many viewers still watch TV this way!
PSIP is sent out by each broadcaster individually, and it will typically only provide information about their own services (although there are some special cases in which they may send out PSIP relating to other channels). This means that a receiver, when tuned to a particular channel, must acquire the PSIP data relating to that channel, and make it available to the viewer. This may take several seconds. To permit quicker tuning from channel to channel, some receivers perform a scan of all PSIP available from all available services periodically when not in use (perhaps in the middle of the night). This information can be stored and displayed to the viewer very quickly when they tune from channel to channel, giving a channel-surfing experience more along the lines of what they’ve become accustomed to in the analog world, without a potential delay of a second or two while jumping between channels.
Making it quicker and easier to tune to your channel(s) is in your best interest, so perhaps sending several days of PSIP data out is, too.
Should I Get This Information From Traffic Or Automation?
The answer in your case may be both, but the ultimate answer is dependent on your interpretation of the FCC’s order. To satisfy/exceed the FCC requirement, and to provide sufficient PSIP data to provide an enjoyable experience for your viewers, it seems advisable to send at least a few days’ worth of PSIP out.
Automation typically only has a view of upcoming events for the next day or less (except over weekends). This means that, while useful for last-minute updates, automation can’t give you the whole PSIP picture.
To get accurate guide information for the next several days’ schedules, the best source is your traffic system. Sure, you can get this information from a listing service as well, but the information obtained from listing services is typically about two weeks old. With your program schedule constantly evolving, you need a more accurate source of this information, and your traffic system can provide that.
However, if you want to provide the most accurate up-to-date PSIP information possible, you may want something to supplement the information you’re getting from traffic. You may want an interface from your automation system to your PSIP Generator, so that this information can be updated up to the last possible moment. For live events, such as breaking news or sports, this is the only way you can guarantee that your PSIP is 100% accurate.
A Challenge: Accurate Names
So, it would seem that it may be in your best interest to have the ability to update PSIP from your traffic system, and maybe even your automation system. The information available in these systems is very basic (typically, start time, duration, and show name).
However, before putting in place such an interface, it is important to first ensure that the show names that are currently in use in these systems are in a form that are acceptable for display in front of your viewers. Some broadcasters have show names such as Friends (Barter Version) or “Late Night Movie (Weekend).”
Would you really want your viewers seeing these names? So, before putting these interfaces in place, you will want to spend some time considering how to best clean up these names and make them presentable to your viewers.
The good news is that you probably only have to clean them up in your traffic system. These program names typically flow from traffic into automation, so getting them right in traffic should result in them being right in automation. If these names do not flow this way in your operation, you will want to be sure that whatever the source of the names, it is providing them in a format acceptable for viewing on an EPG.
The Bottom Line
It’s ultimately your decision as to how you plan to comply with the FCC’s requirement for complete and correct PSIP by February 1, 2005. Encoda has taken an active role in creating solutions to the PSIP data problem, from involvement from day one in the ATSC’s committee that created the PMCP standard, to demonstrating support for it from D-Series Automation earlier this year. We are continuing our support of this new industry standard, and are working on being able to provide you with the capability of getting PSIP-related data out of your traffic systems as well. We encourage other traffic and automation vendors to do the same, and make it as easy as possible for broadcasters to get complete and accurate PSIP information out of their broadcast systems, and into their digital broadcasts.
Christopher Lennon has spent more than 20 years in the broadcast industry, and currently serves as program manager within Encoda Systems’ automation team (Harris recently acquired Encoda Systems). He was one of the founding members of the ATSC group that went on to create PMCP, and is presently chair of an ad hoc group within SMPTE, seeking to establish a standardized means of data exchange among traffic, automation, and content delivery systems.
More about regulatory and standards
