5 Key things to consider with broadcast EPG (Electronic programming guide)

As competition on viewers time increase and digitalization takes over traditional news papers and their TV Listing -sections, broadcasted EPGs have become even more critical to both broadcasters and operators. This blog tries to explain the basics on how EPGs work in DVB networks and what you as a content owner should take into account to achieve a better TV experience.

1) Ensure the source for your EPG data

Well, the EPG source management varies substantially depending whether you are a broadcaster or an operator, so let’s investigate both cases.

For Operators the situation is bit more complex as they need to provide EPG data for all their channels, up-to hundreds most likely. The most common approach for them is to rely on a 3^rd parties to supply and enrich the EPG data.

Companies like Gracenote, Babeleye, Simply.tv, and others offer EPG data as service. Many of these companies can also provide editorials, images, and videos for your programming. This additional and valuable data can be utilised the best with an enhanced EPG.

Alternatively operators can have one-to-one agreements with the broadcasters or extract the EPG data from contribution signals or directly from other networks, such as satellite.

For broadcasters the situation is naturally quite a lot simpler. They have the data in their systems already, the question is how to get it out in correct format . This part I leave to you to figure out…

Regarding the EPG formats, unfortunately there isn’t a standard defined to ingest EPG data to EPG generator servers, there are some more popular formats though. We tend to recommend XMLTV or TV-Anytime as they offer a good support on systems that are used to edit/manage EPG and the EPG generators like Icareus Playout.

2) EPG content must be accurate

This is quite a “naturally” -case, and it can be divided into two bits.

Firstly, information like start time must be correct and title and description must be short but precise. Secondly, EPG data need to be updated, if any changes take place.

The latter sounds easy, but too often the EPG updates are not going through the network operator fast enough. The update frequency or hot-updates has to be agreed between the broadcaster and operator. There may also be a 3^rd party involved that manages the EPG data, as described above, for the operator. This may complicate a task that sounds trivial from the start.

So will you update it when it changes, every 3 minutes or once per day, it all depends on how you build your workflow.

3) DVB defines the EPG format

DVB standards lay down the structure of EPG data you can provide.

The standard is based on two tables in which the data has to be distributed:

EIT P/F (Present / Future)
EIT Schedule tables.

EIT P/F (=present/following) is a smaller and more dynamic table that contains only the running program’s and the next program’s information from your EPG data. It may also be triggered via broadcast to update the present event, convenient for sports events for instance.

EIT Schedule table is the table that contains all your EPG data that is on-air. The table supports the following fields, which I consider the most important ones.

Name	Desciption	Comments
General event data
start_time	This field contains the start time of the event		Mandatory
duration	This field contains the duration of the event in hours, minutes, seconds		Mandatory
content_type	This field defines content identifier	Content type codes	Mandatory
image_icon	The image icon carries inline icon data or a URL that identifies the location of an icon file.		Optional
running_status	This field indicates the status of the event	Field value is defined automatically. Possible values are: 0 – undefined 1 – not running 2 – starts in a few seconds 4 – running	Mandatory
free_CA_mode	This field, when set to ‘0’ indicates that all the component streams of the event are not scrambled. When set to ‘1’ it indicates that access to one or more streams is controlled by a CA system.		Mandatory
Event titles description		It is possible to define titles for one or more different languages.
language_code	This field identifies the language of the following text fields	Language codes	Mandatory
name	This field contains the name of the event		Mandatory
short-description	This field contains the short description of the event		Mandatory
long-description	This field contains the long description of the event		Mandatory
Parental control		It is possible to define parental control values for zero or more different countries.	Optional
country_code	This field identifies a country for parental control	Country codes
rating	This field is coded based on the recommended minimum age in years of the end user	Values: 0x00 – undefined 0x01 to 0x0F – minimum age = rating + 3 years 0x10 to 0xFF – defined by the broadcaster
Notification message		This field allows broadcasters to provide receivers with a textual message which the receiver may display to the user at appropriate times.	Optional
country_code	This field contains the ISO 639-2 three character language code of the language of the textual message.	Country codes
text	This is a field containing a string of characters specifying the text to be displayed.
Content identifier	Content identifiers are part of TV-Anytime information in DVB transport streams (ETSI TS 102 323 v1.5.1)	Events in input source may contain a content reference identifier (CRID) which is a unique identifier for the content. If the input source contains CRIDs these can be output as content identifier descriptors in the output.	Optional
crid_type	This field identifies the type of the CRID.	Values: 0 – No type defined. 1 – CRID references the item of content that this event is an instance of. 2 – CRID references a series that this event belongs to. 3 – CRID references a recommendation. This CRID can be a group or a single item of content.
crid_location	This field specifies the location of the CRID information.	Values: 0 – Carried explicitly within descriptor (this is the only supported value) 1 – Carried in a CIT table (not supported)
crid_bytes	This field carries the explicitly encoded CRID.	Values: The CRID is specified in a similar manner as an URL.

4) Bandwidth is scarce resource

The question I get quite frequently is: “EPG consumes my precious bandwidth, how should I optimise my EPG?”

First, the most important aspect is to define how much bandwidth are you able to allocate (=how much money do you have), perhaps 50kbit/s for each channel. The required bandwidth is based on the repetition rate and the amount of your data. The more frequently you send your data the more bandwidth you need. On the other hand, higher bandwidth means that your EPG is shown faster on the TV.

Fortunately, you can fine-tune your EPG delivery in several ways:

You can opt to send only EIT P/F and not EIT Schedule
You can decide the number of days broadcasted – will you send data for 2 or 21 days?
Optimise EIT table modules (yes, very technical) – it is possible to optimise the repetition rates/bandwidth per module. You can define e.g. that the first module that contains today’s data may use more bandwidth than the 7^th day. There is a lot of fine-tuning to be done here.
EPG Event content optimisation
1. It is also possible to define that e.g. for days 1-3 you send long descriptions and for days 4-7 only short descriptions.
2. You can make your descriptions shorter
3. Decide if you will send parental information
4. Decide if you will send Content reference IDs (see bullet 5).

Don’t hesitate to contact me, if you want to discuss your EPG content strategy..

5) Serving the PVR/DVR lovers

Digital Video Recorded (DVR) usage is still high in many countries and one thing to consider is how to serve these users better (and ensure that your programs, and ads, are seen).

There are few things you should do, or consider at least:

Indicate to viewers that a show is a re-run.
Another important topic for heavy recorders of series is the episode number
Uniqueness of the program, if you move the program to another time slot, some DVRs will miss the recording. The recording automation doesn’t understand that the program moved, but uses the original start-time and records what-ever is broadcasted at that time.

How can you as a broadcasters to convey this information?

There are three things basically you can use:

EPG events title, add as much information that fits
EPG events description, add as much information that fits
CRID, Content Reference Identifier

EPG event title and description can take the necessary information in textual format. Fortunately most DVRs have intelligent recording algorithms that can use title and description information and ensure that it doesn’t record the same program twice, but at the same time do record automatically all episodes of the series.

CRID is used to give each EPG event a unique ID that can be used by DVRs to ensure that they record the correct program. This is the “right” way to convey unique information for DVRs. I won’t go into details with it, but have a look from Wikipedia. Keep in mind, although excellent feature in DVB, it is not supported by all receivers.

+1) Consider to offer enhanced EPG

As you probably understood from above, DVB limits quite heavily what you can offer to viewers in EPG. An enhanced EPG combines content from broadcast and broadband and can thus include images, videos and more detailed and even personalised information on programming. Depending on the case it may also offer advertising opportunities.

Enhanced EPG can be provided either by a broadcaster or operator and take over the device manufacturers default EPG, to which they do not have any control over.

We at Icareus have also years of experience building EPGs apps for both operators and broadcasters and can help you to outline the correct strategy in combining broadcast and enhanced EPG.

Below are some examples of enhanced EPGs, for both broadcasters and operators.