What is EPG?

Electronic Program Guide EPG is a service for television, radio or other multimedia application displaying information about currently broadcasted content. The user can browse through information on present or following program content. Often EPG is based on some dedicated middleware for set-top-boxes. They differ by target distribution technology, implemented features, middleware and required bandwidth.

An elementary EPG implementation without requirements on special middleware is defined by the EN 300 468. The standard defines EPG data to be carried out through Event Information Tables (EIT). These tables are multiplexed within a MPEG-2 transport stream along with other tables and service data. The delivery mechanism can be satellite, cable or terrestrial network.

EIT are generated independently for each service. The table for each service is subdivided into sub-tables, segments and sections. EIT of all services share the same bandwidth and Packet IDentifier (PID) within a MPEG-2 transport stream.

Basically there are two groups of tables:

• present/following
  Carrying information of events currently on-air (present) and events next on schedule (following). These tables should be updated very often, so viewers switching from some other program can access event information quite fast. A typical repetition rate is 2 second. Therefore present/following tables for all programs should be inserted in the transport stream at least once every 2 s.
• schedule
  Carrying information of content from now up to 64 days in future. The update rate of these tables can be somehow variable. Some guideline is to repeat the schedule table at least every 30 seconds. It can of course be more often. Because viewers are mostly interested for the next 24 hours, it is suggested to repeat the schedule tables for the next 24 hours every 10 seconds.

EIT is part of the Program-specific information (PSI) and Service information (SI) tables defined by MPEG-2 and DVB standards. Other important tables from these mentioned standards are: PAT, PMT, NIT, SDT, CAT, TDT, TOT. With exception to Time and Date Table (TDT) these tables are more or less static and not very complex to build. Therefore DVB multiplexers on the market have integrated capabilities to build and play these tables.

EIT on the other hand is based on dynamic data and must be updated very often. Separate devices called EPG Builder, EPG Generator or EPG Inserter are used for this task. A general implementation of a system for building a DVB MPEG-2 transport stream is shown in fig. 1.

Typically video/audio encoder and SPTS multiplexer are combined in a single device called just encoder or service encoder. Often these encoders do not just encode a TV program - consisting of video and one or multiple audio contents - but add also basic PSI tables. Nevertheless for combining multiple TV or radio services a transport stream multiplexer is required. By multiplexing multiple SPTS or even MPTS and insertion of new rebuild tables a new transport stream is generated. Again an external EIT builder for generating EPG information is required.

As mentioned above EPG contains information about events. Whereas events, when speaking about EPG, are basic program elements which have a defined start and end time e.g. magazines, movies, TV series, talk shows, game shows, etc.. For generating EPG these event information have to be gathered and ingested in some local storage - database - for later processing. The whole process of building EIT is shown in fig. 2.

Every event is described by a few mandatory elements:

• event_id
  Unique event identification number.
• start_time
  The time at witch the event starts in Universal time - UTC. (Unregarded to the country of origin, the time is always UTC/GMT.)
• duration
  The duration of the event in seconds.
• running_status
  The current status of the event e.g. not running, running, pausing, etc.
• free_CA_mode
  Indicating if any of components of the service is scrambled and controlled by a conditional access system.

Till now there was no “real” useful information for the viewer except beginning and duration of the event. Therefore the mentioned standard defines plenty of descriptors which can be used for describing events. Not all of them are used by broadcasters and only a few of them are supported by the majority of STBs and TV sets.

The most often used descriptors are:

• short_event_descriptor
  This is the basic descriptor for events. It contains the event name or title and the short description or sub-title. Each of these fields can be up to 255 characters long.
• extended_event_descriptor
  Here we can find the detailed text descriptions of event. By broadcasters often called synopsis. This field can be up to 3984 characters long.
• parental_rating_descriptor
  Information to help parents control what level of content they allow their children to watch. This is done by signaling an index according to the Television content rating system. As the rating can differ by country the index must always reference the country for which it applies. ISO 3166 is used for this. With 3 uppercase characters the country is defined e.g. FRA (France), SVN (Slovenia), ITA (Italy), etc.
• component_descriptor
  This descriptor gives information on the event service components e.g. aspect ratio format of the video, compression system used for video and audio, available audio languages, format of subtitles, etc.
• content_descriptor\ The intention of the content descriptor is to provide genre classification information for an event. The standard specifies a list of genres to be used. Multiple genres can be applied to a single event.

Descriptors with textual fields (short_event_descriptor and extended_event_descriptor) have to refer to the language used in the text. This is done by using 3 lowercase characters according to ISO 639-2 e.g. ger (German), eng (English), rus (Russian), etc.

Diversity of languages implies the need to handle different code pages used to represent special characters in each language. The widely-used unicode system UTF-8 seems to be a best fit. But there are still STBs and TV sets that will not correctly display characters within the UTF-8. Therefore alternative code pages should be used if possible e.g. ISO/IEC 8859-9 (West European), ISO/IEC 8859-2 (East European), ISO/IEC 8859-5 (Latin/Cyrillic), etc.

If no code page is specified a superset of ISO 6937 is used.

The declaration of code page used inside a text field is done by preceding the text with some 1 to 3 character codes e.g. \x05 (ISO/IEC 8859-9), \0x10 \x00 \x02 (ISO/IEC 8859-2), \x15 (UTF-8), etc. This has to be done for each text field separate.