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.

Picture 1 - Electronic Program Guide on TV screen

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.

Figure 1 - DVB-MPEG-2 transport stream multiplexing

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.

Figure 2 - Building of EIT from gathered information

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.