The Life of a DVB Service: From PAT to EPG

When a viewer presses a channel button, a lot more happens than "video starts." A DVB receiver has to discover the service, locate its streams, build channel context, populate programme information, and optionally launch interactive applications. That entire journey is driven by PSI and DVB SI tables.

This is the story of what happens in the first seconds after tune-in, from PAT to EPG and HbbTV launch.

Scene 1: The receiver locks to a transport stream

The tuner locks RF parameters (frequency, symbol rate, modulation, FEC) and starts receiving MPEG-TS packets. At this point, the receiver has packets but no service map. It does not yet know which PID belongs to which channel.

The first objective is simple: find the transport stream directory.

Scene 2: PAT is discovered (PID 0)

The Programme Association Table (PAT) is always on PID 0, so every compliant receiver checks it first. PAT tells the receiver:

• Which service IDs exist in this multiplex
• Which PMT PID belongs to each service ID
• Which PID carries the network information reference (programme_number 0)

PAT is the root index. Without PAT, there is no path to decode any service.

Scene 3: PMT is located for the selected service

After the receiver identifies the service the user wants (for example by service_id from the channel list), it uses PAT to find that service's PMT PID and starts filtering that PID.

The Programme Map Table (PMT) is the service blueprint. It declares what elementary streams belong to this service and which descriptors apply.

Scene 4: Video and audio PIDs are identified

Inside PMT, each elementary stream entry includes a stream_type and PID. This is where decode starts to become possible:

• Video PID(s): MPEG-2, H.264/AVC, HEVC, etc.
• Audio PID(s): MPEG audio, AAC, AC-3, E-AC-3, etc.
• Optional component PIDs: subtitles, teletext, metadata
• Conditional access references: ECM PID(s) via CA descriptors when scrambled

Once these PIDs are known, the demux can route packets to decoders. The channel can now render picture and sound, even if guide data is still loading.

Scene 5: SDT provides service identity

The Service Description Table (SDT, PID 17) provides the human-facing identity of the service:

• Service name (what appears in the channel list)
• Provider name
• Service type (TV, radio, data)
• Flags indicating schedule and p/f availability

PMT explains how to decode a service. SDT explains what the service is. Receivers need both for a coherent user experience.

Scene 6: NIT provides network context

The Network Information Table (NIT, typically PID 16) adds network-level context beyond the current service:

• Network ID and network descriptors
• Transport stream loop entries for related multiplexes
• Delivery-system descriptors (satellite/cable/terrestrial tuning parameters)

This is how a receiver learns where other multiplexes live and builds a complete channel universe, not only the current frequency. NIT is essential for scanning and network navigation.

Scene 7: EIT provides schedule data for EPG

The Event Information Table (EIT, PID 18) fills the now/next banner and the full programme grid:

• EIT p/f Actual: current and next event on this transport stream
• EIT schedule Actual: multi-day schedule for services on this transport stream
• EIT Other variants: event data for services on other transport streams

Event entries carry titles, start times, durations, synopses, content genre, and parental ratings. This is the moment when the receiver transitions from "playing a channel" to "understanding programming timeline."

MPEG-TS receivers rely on PSI and DVB SI tables to discover and present services. EIT is where that discovery becomes viewer-facing EPG behavior.

Scene 8: AIT launches HbbTV applications

If the service carries interactive signaling, the Application Information Table (AIT) tells the receiver which HbbTV applications are available and how they should be started.

• Application identifiers and control codes
• Autostart vs user-trigger behavior
• Transport/protocol details for application assets

At this point, the service is no longer only linear AV. The receiver can expose red-button and hybrid broadcast-broadband experiences aligned to the tuned channel.

The complete mental model

Seen in sequence, PSI/SI is not a set of isolated tables. It is a discovery pipeline:

1. PAT: where is each service map?
2. PMT: which PIDs make this service?
3. Elementary streams: decode video/audio components
4. SDT: what is this service called?
5. NIT: what network and other multiplexes exist?
6. EIT: what is on now and later?
7. AIT: what interactive app should launch?

That chain is what gives viewers a usable channel list, reliable now/next, full EPG, and HbbTV interaction from a single tune event.

Why this matters operationally

In real playout environments, these tables are interdependent and continuously changing. A channel rename in SDT, a PID move in PMT, a schedule correction in EIT, or an application update in AIT can affect receiver behavior immediately. Managing that safely requires synchronized generation, validation, and repetition-rate control across the whole PSI/SI set.

For broadcasters, the goal is not only standards compliance. The goal is predictable receiver behavior at scale, on every set-top box model in the field.