EIT and EPG Schedule in DVB: p/f, Schedule, Actual and Other Explained

The Event Information Table is the part of DVB SI that viewers experience directly. Every programme title, start time, synopsis, and content rating displayed on an EPG grid comes from EIT data carried in the transport stream. Getting EIT right — and keeping it right in real time — is the central operational challenge of PSI/SI management.

This article covers the full EIT family: present/following (p/f) and schedule, actual and other, the key descriptors each carries, and the timing requirements that govern transmission.

The EIT family: four table variants

EIT is not a single table but a family of four logical variants, each assigned its own table_id range in ETSI EN 300 468. Understanding the distinction between them is essential before looking at the content they carry.

• EIT p/f Actual — table_id 0x4E. Present and following events for services in the current transport stream. Mandatory for every service that carries a programme signal.
• EIT p/f Other — table_id 0x4F. Present and following events for services on other transport streams within the same network. Optional but expected by most receivers for cross-multiplex now/next display.
• EIT schedule Actual — table_ids 0x50–0x5F. Up to 16 sub-tables, each covering a 4-day window (days 0–3 relative to the sub-table's start day) of schedule data for services in the current transport stream. Together they provide a maximum of 64 days of EPG grid data, though in practice most broadcasters populate 7–8 days using sub-tables 0x50 and 0x51.
• EIT schedule Other — table_ids 0x60–0x6F. The same structure and maximum 64-day window, but for services carried in other transport streams of the network.

All four variants are transmitted on PID 18. The table_id field in the section header is what allows a receiver to distinguish between them.

EIT p/f — present and following

EIT p/f carries exactly two event entries per service: the currently airing event (section_number 0) and the next scheduled event (section_number 1). These two sections drive the "now and next" banner that appears when a viewer changes channel, and they feed the present/following row in EPG applications.

Because viewers expect now/next information to be accurate at all times, EIT p/f Actual must be updated at every programme boundary — at the moment the current event ends and the following event begins. A mismatch between the playout clock and the EIT p/f start times will cause the EPG to display the wrong programme title on-air, which is a visible broadcast fault.

The repetition requirement for EIT p/f Actual is a maximum interval of 2 seconds, meaning the table must be transmitted at least once every 2 seconds per service. On a multiplex with many services, the aggregate EIT p/f bitrate can be significant, and the injection system must manage PID bandwidth accordingly.

EIT schedule — the full programme guide

EIT schedule carries the multi-day programme grid. The 16 sub-tables (0x50–0x5F for Actual) each cover a contiguous 4-day window. Sub-table 0x50 covers days 0–3 (starting from midnight UTC today), 0x51 covers days 4–7, 0x52 covers days 8–11, and so on — giving a theoretical maximum of 64 days across all 16 sub-tables. In standard broadcast practice, only sub-tables 0x50 and 0x51 are populated, delivering the 7–8 day EPG window that receivers expect.

Within each sub-table, sections are organised by service_id and by 3-hour segment. The section_number encodes both the segment index (which 3-hour slot within the 4-day window) and the section within that segment, allowing receivers to locate and verify schedule data efficiently. For a multiplex with many services and dense schedules, EIT schedule will typically consist of hundreds of sections, and their combined transmission takes priority planning.

The maximum transmission interval for each EIT schedule sub-table is 10 seconds. In practice, most professional systems aim for much shorter cycle times — particularly for sub-table 0x50 (covering the first 4 days), which viewers are most likely to be browsing.

Actual vs Other — why both matter

The Actual/Other distinction maps to transport stream scope. A receiver tuned to multiplex A will process EIT Actual tables to populate its EPG for services on that multiplex. To fill in guide data for services on multiplex B and C without having to retune, it relies on EIT Other tables — transmitted by multiplex A but describing services elsewhere in the same network.

This architecture allows a receiver to pre-populate the full network EPG from a single tune. It also means that the PSI/SI generator for any given multiplex is responsible not only for its own service schedules but potentially for re-injecting schedule data for partner multiplexes as EIT Other.

Carriage obligations for EIT Other are defined in the network's carriage agreement. It is common for a network operator to mandate that the primary multiplex carries EIT p/f Other for all services network-wide, ensuring viewers always see accurate now/next data regardless of which multiplex they are currently tuned to.

Key descriptors inside EIT events

Each event entry in an EIT section carries one or more descriptors. The most important are:

• short_event_descriptor — mandatory for any populated event. Carries the event name (programme title) and a short description, both encoded as DVB text strings with optional character set prefixes. Maximum 255 bytes each.
• extended_event_descriptor — carries a longer synopsis and optional item list (cast, director, year of production). Because a single descriptor is limited to 255 bytes, long synopses are split across multiple numbered extended_event_descriptors within the same event.
• content_descriptor — carries one or more content nibble pairs classifying the programme genre (news, sport, film, documentary, children's, etc.). Used by receivers to colour-code the EPG and enable content-type filtering.
• parental_rating_descriptor — carries per-country parental guidance ratings. Required for broadcasters subject to watershed and ratings obligations. A receiver with parental controls enabled uses this to block or flag content.
• component_descriptor — describes the audio and video components of the event: SD or HD video, mono or surround audio, subtitle presence, and teletext. Referenced via the component_tag values defined in the PMT stream_identifier_descriptor.
• PDC descriptor / time_shifted_event_descriptor — used for PDC (Programme Delivery Control) triggers and time-shifted service references. Less common but required for certain VCR programming and catch-up integrations.

Event timing and programme boundaries

EIT event start times and durations are encoded in UTC, using the DVB Modified Julian Date (MJD) format for the date component and BCD-encoded hours, minutes, and seconds for the time. All receivers derive their clock from TDT/TOT (Time and Date Table / Time Offset Table), so the EIT timestamps are always interpreted in UTC regardless of the viewer's local time zone.

Accurate programme boundary timing is critical for two reasons. First, the EIT p/f transition — when the following event becomes the present event — must occur at exactly the correct second. Second, recording applications and catch-up systems use EIT timestamps to trigger recordings; even a small offset causes recordings to miss the opening seconds of a programme.

Where live events overrun, the EIT must be updated in real time. A PSI/SI system connected to a scheduling or traffic system can receive live updates and re-inject corrected EIT within seconds of a schedule change being committed.

Transmission bandwidth and cycle management

A complete EIT dataset for a mid-sized network — say 20 services with 8 days of schedule Actual and 2 days of schedule Other — typically runs to several thousand sections. Managing the transmission cycle so that all sections meet their repetition deadlines without exceeding the available PID bandwidth requires careful bitrate budgeting.

The ETSI EN 300 468 repetition guidelines by table type:

• EIT p/f Actual: maximum 2 s interval
• EIT p/f Other: maximum 20 s interval (recommended 10 s)
• EIT schedule Actual sub-table 0x50: maximum 10 s (current day; many operators target 2–3 s)
• EIT schedule Actual sub-tables 0x51–0x5F: maximum 10 s each
• EIT schedule Other: maximum 10 s per sub-table

A well-designed PSI/SI generator prioritises EIT p/f transmission above schedule data, ensures the current-day schedule (0x50) cycles faster than future days, and dynamically adjusts cycle times based on real-time bitrate measurements.

The operational challenge: keeping EIT current

Unlike PAT, PMT, and NIT — which change only when the network topology or service configuration changes — EIT schedule is in constant flux. Programmes change, events overrun, advance schedule data arrives from rights holders on rolling update windows, and ad-hoc inserts and deletions occur throughout the broadcast day.

This means the system generating and injecting EIT must be connected to the scheduling infrastructure, capable of processing inbound schedule data in whatever format the traffic or EPG system produces (XML TV, XMLTV, DVB SIxml, proprietary JSON APIs), and able to regenerate and re-inject affected sections within a defined SLA window — typically 60 seconds or less from schedule commit to on-air update.

It is this continuous operational loop — ingest, validate, generate, inject, verify — that distinguishes a production PSI/SI generator from a one-time table builder. The EIT is never finished; it is a live data feed embedded in the transport stream.