PSI/SI Tables, Descriptors & Identifiers
The Complete Signalling Reference

1. Scope and sources

A transport stream without signalling is a bag of packets. The tables described here are what let a receiver discover which services exist, what each is made of, what they are called, when programmes start, and what time it is.

Two specifications divide the work. ISO/IEC 13818-1 defines PSI — Program Specific Information — the tables describing the stream's own structure. ETSI EN 300 468 defines SI — Service Information — the tables describing the broadcast as a service offering. Every descriptor tag in section 6 is taken from EN 300 468 V1.19.1 (2025-02), the current edition, read directly rather than from secondary sources.

For the container these tables travel in — packets, PIDs, sections and PES — start with MPEG Transport Stream Explained. For monitoring these tables in production, see DVB Errors & Troubleshooting.

2. The signalling model

Three nested structures carry all of it, and confusing them is the source of most parsing bugs:

• A table is a logical structure identified by a table_id. It is what you conceptually want — "the PAT", "the SDT".
• A section is the transport unit, at most 4096 bytes. A table may span up to 256 sections when it uses the long syntax, and all of them must be collected before the table is complete. Long sections carry a version number and a CRC32; short sections carry neither.
• A descriptor is a self-describing sub-structure carried inside tables, identified by a tag byte and a length byte. Descriptors are where almost all the detail lives.

The consequence worth internalizing: a receiver does not read "the SDT". It collects sections on PID 0x0011 with table_id 0x42, checks each CRC, assembles them by section number, notices the version number, and then walks the descriptor loops inside. Every one of those steps is a place things go wrong, which is why the error indicators in the troubleshooting sheet are so granular.

3. Reserved PID map

Signalling lives at fixed PIDs so a receiver can start with no prior knowledge.

PMT PIDs are not reserved. Each service's PMT sits on a PID chosen by the multiplexer and announced in the PAT. Three PIDs therefore share a single value in a way that trips people up: SDT and BAT both live on 0x0011, and TDT and TOT both on 0x0014, distinguished only by table_id.

4. The table_id registry

Because PIDs are shared, table_id is what actually identifies a table. These are the values you filter on.

DIT and SIT are defined by DVB for partial transport streams. Their table_id and PID values are omitted here because they could not be confirmed from the specification text during verification, and an unverified identifier in a reference table is worse than an absent one.

The EIT schedule range is worth noting: a whole block of table_id values, because a full multi-day schedule for every service does not fit into a single table. This is also why a complete seven-day EPG for a large operator consumes several megabits per second.

5. Table by table

5.1 PAT — Program Association Table

Produced by the multiplexer. Consumed by every receiver, first. Lists every service in the transport stream as a pair of service id and the PID carrying that service's PMT. Must recur at least every 0.5 s. Program number 0 is special: it points to the NIT rather than a PMT.

Without it nothing is decodable, which is why it is the highest-priority monitored item after synchronization itself.

5.2 PMT — Program Map Table

Produced by the multiplexer, one per service. Consumed by a receiver after the PAT. Describes exactly one service: the PCR PID, and for each elementary stream its PID, its stream type, and a descriptor loop carrying the detail — language, audio format, subtitle type, and CA information where the service is scrambled. Also recurs at least every 0.5 s.

The PMT is the single most useful table to read when diagnosing "why does this channel not play". Everything a decoder needs for one service is in it.

5.3 CAT — Conditional Access Table

Produced by the CA system's head-end components. Consumed by receivers holding a matching CA module. Lists the EMM streams present in this multiplex. Absent when nothing is scrambled — and its absence while scrambled packets are present is a monitored error, because a receiver then cannot obtain entitlement messages.

5.4 NIT — Network Information Table

Produced by the network operator. Consumed by receivers performing a scan. Technically describes the network: every transport stream in it, usually with complete tuning parameters, plus the services each carries and their logical channel numbers.

This is what makes fast scanning possible. A receiver tunes one transponder, reads the NIT, and learns where everything else is instead of sweeping the band. The delivery-system descriptors that carry those tuning parameters are tag 0x43 for satellite, 0x44 for cable, 0x5A for terrestrial and 0x79 for DVB-S2.

5.5 SDT — Service Description Table

Produced by the operator. Consumed by receivers building a channel list. Carries the human-facing description of each service: its name, its provider's name, whether it is scrambled, its running status. The service_descriptor (0x48) is where the name actually lives.

A stream with a valid PAT and PMT but no SDT plays perfectly and shows no channel name — a useful diagnostic signature.

5.6 BAT — Bouquet Association Table

Produced by a commercial operator. Groups services into a "bouquet" — a commercial package rather than a technical network. Several commercial operators may sell overlapping sets of the same services, which is precisely why bouquets are separate from networks. Shares PID 0x0011 with the SDT.

5.7 EIT — Event Information Table

Produced by the operator's schedule system. Consumed by the EPG. Comes in two flavours: present/following gives the current and next event per service and drives the now-and-next banner; schedule gives the full forward listing and drives the guide proper.

Schedule EIT is optional and expensive. It depends, as TSDuck's documentation puts it, on the operator's good will and available bandwidth — a complete seven-day EPG for a large operator uses several megabits per second, and sections are often sparse rather than complete.

5.8 TDT and TOT — time

Produced by the head-end. Consumed by receivers setting their clock. TDT carries UTC; TOT adds local offset per region, and uniquely among short-section tables it carries a CRC32. Typically broadcast only every 10 to 30 seconds, and monitored at a 30 s threshold.

5.9 RST, TSDT, DIT and SIT

RST signals that an event has started or finished early, letting a receiver update status faster than waiting for the next EIT cycle. TSDT describes the transport stream as a whole and is rarely used in practice. DIT and SIT belong to partial transport streams — recorded or spliced content rather than live broadcast.

6. The descriptor tag registry

Descriptors carry nearly all the substance of DVB signalling. Each is a tag byte, a length byte, and a payload whose structure the tag determines. The tags below are taken directly from Table 12 of EN 300 468 V1.19.1.

Tags 0x00–0x3F are the MPEG-defined range from ISO/IEC 13818-1, including CA_descriptor and ISO_639_language_descriptor. Tags 0x80 and above are user-private and only meaningful in the scope set by a preceding private_data_specifier_descriptor (0x5F). Four tags in the DVB range are omitted here rather than guessed, because they could not be extracted from the specification with confidence.

7. Placement — why the same tag means different things

EN 300 468 Table 12 does more than list tags: it specifies, for each descriptor, which tables it may appear in. A check mark means the descriptor may be carried in that table; a dash means it shall not be; an empty cell means the specification implies nothing either way.

This matters more than it first appears. Several descriptors are legal in exactly one table and meaningless elsewhere — network_name belongs only in the NIT, the delivery-system descriptors only in the NIT, service only in the SDT and SIT. A parser that reads descriptor loops without tracking which table it is inside will happily decode a descriptor that has no business being there, and produce confident nonsense.

The standard also notes that the table is about descriptors declared or defined within EN 300 468, and that the placement guidance does not imply their use in other tables is restricted. In other words: treat it as authoritative for what is intended, not as an exhaustive prohibition.

8. Stream type versus descriptor — the audio trap

Each elementary stream in a PMT carries a stream_type byte. Intuitively that byte should tell you the codec, and for video it broadly does. For DVB audio it frequently does not, and this is one of the most common sources of "why does my parser think this is private data".

The mechanism is straightforward once seen. Codecs that predate a given edition of the MPEG registry, or that were standardized outside it, are carried as a private stream type, with the actual codec identified by a descriptor in the PMT's descriptor loop. AC-3 is the canonical case: its presence is signalled by the AC-3_descriptor at tag 0x6A, and enhanced AC-3 by enhanced_AC-3_descriptor at 0x7A. The stream type alone will not tell you.

Two practical consequences:

• Never identify a codec from stream_type alone. Read the descriptor loop for that elementary stream as well. A parser that skips descriptors will mis-identify audio on a large fraction of real European transponders.
• The descriptor is the authority when both are present. If the stream type says private data and an AC-3 descriptor is present, it is AC-3.

The same pattern recurs elsewhere: subtitles are identified by subtitling_descriptor (0x59) and teletext by teletext_descriptor (0x56) rather than by distinct stream types. The descriptor loop is not optional detail — it is where the stream is actually described.

The authoritative stream_type value list is in ISO/IEC 13818-1. It is deliberately not reproduced here, because the freely circulating versions of that table disagree with one another and a wrong value in a reference document is worse than an absent one.

9. Repetition rates and what breaks

Signalling is broadcast on a cycle, not served on demand. The intervals below are the monitored thresholds from ETSI TR 101 290 V1.4.1; the underlying maxima and minima come from EN 300 468 and TR 101 211.

The 0.5 s figures explain a behavior that looks like a bug and is not. Immediately after tuning, a receiver — or a server asked for a program by PMT — may not yet have the tables. SAT>IP Servers Pro rejects a PMT-based request in exactly that window rather than guessing, and expects the client to retry. Asking by explicit PID list needs no table knowledge and can be served immediately; asking by program requires the PMT first. That is a signalling consequence, not an implementation quirk.

10. Signalling as editable data

It is tempting to treat PSI/SI as fixed truth arriving from the broadcaster. In a processing chain it is neither fixed nor necessarily true, and understanding that is what separates working remultiplexing from mysterious failures.

Two concrete illustrations from SAT>IP Servers Pro:

• Deriving a single-program stream from a PMT. Given a PMT PID, the server reads the table, collects the PID set that service actually needs — PMT plus PCR plus audio and video plus PSI — and emits only those. That operation is nothing but reading section 5.2 correctly.
• Rewriting PSI after decryption. With -t --cleanpsi, all CA information is stripped from the PSI so a successfully decrypted service presents to the client as clear. The video is no longer scrambled, so tables still advertising CA descriptors are now wrong, and correcting them is the right fix rather than a hack.

There is also a monitoring consequence worth stating plainly: you cannot audit table repetition on a filtered stream. Requesting a PID subset removes the very tables whose timing you wanted to measure. Monitoring feeds need the full multiplex.

11. Standards and sources

• ETSI Standards portal — EN 300 468, TR 101 290, TR 101 211
• TSDuck — table extraction and analysis tooling
• SATLINE.TV Virtual SAT>IP Servers

12. About the author