EIT Demultiplexing: Preserving EPG in IPTV
EIT demultiplexing keeps a selected TV service’s programme information with its individual SPTS output when a DVB multiplex is converted to IP. Compatible IPTV televisions, set-top boxes and middleware can then use that data to display a programme guide alongside the received channel.
Why Can the Picture Work While the Guide Is Missing?
A DVB-to-IP gateway may deliver a channel’s video and audio successfully without delivering the programme information needed by the receiver’s guide. Generating an SPTS and retaining the associated EIT are distinct processing requirements. BLANKOM’s A-model documentation explicitly identifies automatic EIT insertion as an additional function.1, 5
| Term | Meaning in this paper |
|---|---|
| MPTS | Multi Program Transport Stream: one transport stream carrying several services. |
| SPTS | Single Program Transport Stream: one selected service, including its retained components and signalling. |
| EPG | Electronic Programme Guide: the programme information presented to the viewer by a TV, STB or application. |
| EIT | Event Information Table: DVB service-information data about programme events. It can carry event timing and descriptive information. |
EIT is data, not a graphics overlay. The gateway carries it; the receiving device or middleware determines how it is displayed.3, 4
How EIT Demultiplexing and Automatic Insertion Work
The gateway selects the required service from a received multiplex, separates its relevant EIT information and adds that information to the corresponding SPTS. The supplied IGS-900A / IGS-924A datasheet describes this automatic insertion explicitly; the IGS-8008 portfolio entry identifies EIT demultiplexing and streaming with SPTS.1, 2
Shared Multiplex
TV service A
TV service B
TV service C
EIT information for A, B and C
Select + Associate
Select each service and its components.
Demultiplex the relevant EIT sections and insert them into the corresponding SPTS.
SPTS A
Service A + EIT for A
SPTS B
Service B + EIT for B
SPTS C
Service C + EIT for C
In DVB, EIT sections are carried on PID 0x0012, decimal 18. Multiple services can share this PID. Passing the entire PID is therefore not the same as selecting the EIT sections belonging to a particular service.4, 5
Four Different EPG Handling Approaches
| Approach | What happens | Design consequence |
|---|---|---|
| SPTS without EIT | The selected audiovisual service is delivered without its EIT. | Picture and sound may work, but this stream does not supply DVB guide data. |
| Whole EIT PID pass-through | All incoming EIT packets are forwarded without service-specific section selection. | May include information for unrelated services; this is not EIT demultiplexing. |
| Service-specific EIT-to-SPTS | Relevant EIT sections accompany the selected service. | Provides an in-band source for compatible receivers or middleware. |
| Separate EPG source | A separate database or EPG processor supplies guide information. | An independently designed guide workflow, not an implied gateway feature. |
This comparison separates transport-stream selection from guide generation. TSDuck documents selected-service EIT filtering separately from basic service selection; BLANKOM’s IPTV whitepaper also distinguishes middleware and dedicated EPG processing.3, 5
Linear IPTV and Middleware-Based Systems
Guide Data Reaches the Receiver
The SPTS passes through the managed IP network to a compatible television or STB. Its own software can use the received EIT for programme information. A separate middleware server is not intrinsically required for this path.1, 3
Guide Data Feeds the Platform
A middleware platform can extract the received EIT and use it in its programme database and user interface. The gateway supplies the in-band data; the platform still defines the presentation and application features.3
The application diagram on page 4 of the supplied A-model datasheet places the gateway upstream of managed switches and receiving devices, with the middleware server explicitly optional. It is a reference architecture—not a guarantee that every television or application implements the same guide functions.1
| Application | Practical use of EIT-to-SPTS |
|---|---|
| Hotels, hospitals and residential IPTV | Provide broadcast programme information with each selected channel, subject to the TV or STB’s EIT support. |
| Cruise ships, vessels and crew accommodation | Keep programme information in the local IPTV distribution path alongside received broadcast services. |
| Corporate and campus television | Support programme identification on compatible shared TVs and IPTV clients. |
| Middleware with guide-based recording | Supply event information that the recording platform can use. The recording engine, storage and user interface remain separate functions. |
These are system-design examples, not claims of model-specific end-to-end certification. EIT support is most relevant when the project intends to obtain programme information from its received broadcast streams.
EIT Support Is Not the Same as Dynamic PMT Support
The A-model datasheet lists Dynamic PMT and EPG demuxer support together, but they address different requirements. Dynamic PMT handling concerns changes in a service’s programme map and component selection; EIT handling concerns programme-event information. The datasheet associates Dynamic PMT with regional TV service separation.1
What Must Be Verified End to End
The documented EIT-to-SPTS feature establishes a gateway function. It does not establish every EPG outcome for every receiver. Treat the following as project acceptance questions rather than additional product specifications.
Source information
The received service must provide the EIT information the project needs. The gateway cannot transfer event descriptions or schedules that are absent from the source.
Now/next versus schedule
EIT present/following and EIT schedule are separate table categories. A general EIT-support statement does not establish a guaranteed number of guide days.4
Receiver and middleware behaviour
Confirm EIT support in the exact TV, STB or application, including its software version, guide display, language handling and channel association.
Output protocol and downstream processing
The claim concerns EIT inside a transport stream. Do not assume it survives every protocol mode, transcoder, repackager or OTT delivery path; verify the stream after the complete chain.
Identifiers and guide updates
Validate service association and updated programme information after any remapping or source change. A correct first display is not sufficient evidence of continued operation.
Guide scope
A channel-specific SPTS should not be assumed to provide a complete all-channel guide. Establish how the receiving system acquires the full line-up’s programme information.
IGS-8008, IGS-900A and IGS-924A
These BLANKOM gateways document EIT demultiplexing with SPTS delivery. The table compares the satellite configurations relevant to this paper. Alternative reception standards must be specified separately.1, 2
| Model | Satellite tuner inputs | Maximum SPTS outputs | EIT-to-SPTS function |
|---|---|---|---|
| BLANKOM IGS-8008 → | 8 × DVB-S/S2/S2X | Up to 64 | EIT demultiplexing and streaming with SPTS.2 |
| BLANKOM IGS-900A → | 16 × DVB-S/S2/S2X | Up to 128 total | Automatic EIT demultiplexing and insertion into SPTS.1 |
| BLANKOM IGS-924A → | 24 × DVB-S/S2/S2X | Up to 128 total | Automatic EIT demultiplexing and insertion into SPTS.1 |
Choose by received multiplex/transponder count, selected service count, bitrate and required output behaviour—not by the number of televisions alone. One satellite transponder may contain several TV or radio services. The IGS-900A and IGS-924A links open their shared family product pages; specify the A-model in an enquiry.
Verify the Guide, Not Only the Picture
The following is a proposed acceptance sequence, not a report of tests performed on these products. Use the project’s source channels and actual receiving system.
Inspect the source
Confirm that the required channel and its programme information exist in the incoming multiplex.
Inspect the output SPTS
Use a transport-stream analyser to check for EIT sections associated with the selected service; merely detecting PID 0x0012 is not enough.
Check signalling consistency
Review service identifiers, applicable SDT EIT flags and any configured remapping.
Observe programme changes
Check now/next transitions and, where required and supported, schedule updates over an adequate observation period.
Test the actual endpoint
Confirm the correct channel, programme text and displayed times on the intended TV, STB or middleware software.
Test the complete delivery path
Repeat after the normal switching, forwarding and stream-processing stages. Record the model, firmware and configuration used.
A useful acceptance result confirms both stream-level evidence and the intended user-visible behaviour. An analyser and a receiver answer different questions: whether the data is present, and whether the application uses it as required.4, 5
EIT-to-SPTS Frequently Asked Questions
Does every DVB-to-IP gateway with SPTS output preserve EPG?
Is a separate middleware server always necessary?
Does EIT-to-SPTS support guarantee a seven-day programme guide?
No. The result depends on source data, supported EIT categories and the receiving system. The cited gateway feature descriptions do not establish a guaranteed number of guide days.
Can the feature create EPG for a local information channel?
Not by itself. A locally generated channel without programme-event data requires a separately specified guide-data source and insertion workflow.
Technical References
Product capabilities in this paper follow the cited BLANKOM material. ETSI and TSDuck support the terminology and processing distinctions; they are not evidence of additional BLANKOM firmware features. Architecture examples and acceptance questions are engineering guidance, not certification claims.
- BLANKOM IGS-900A / IGS-924A datasheet, supplied v1.4 filePages 1–3: A-model features and output limits; page 4: IPTV application architecture.
- BLANKOM DVB-to-IP gateway portfolioIGS-8008: EIT demultiplexing and SPTS streaming; IGS-924: separate A-version feature note.
- BLANKOM — Whitepaper about IPTVPages 27–29: service-specific EIT, receiver and middleware use, and separate EPG processing.
- ETSI EN 300 468 V1.19.1 — DVB Service InformationClauses 5.1.3 and 5.2.4: EIT PID, present/following, schedule and service identification.
- TSDuck User GuideThe zap plugin documents service-specific EIT filtering; EIT processing and analysis are described separately.
Specify the Programme Guide as Part of the Signal Chain
Send your channel and transponder list, required EPG behaviour, output protocol and receiving-device details. We can then assess the appropriate BLANKOM gateway configuration and identify the compatibility checks required for your system.
© 2026 IRENIS GmbH. All rights reserved. Unless otherwise stated, the original text, diagrams, tables and illustrations in this publication are protected by copyright. Except where permitted by applicable law, they may not be reproduced, republished, distributed, translated, adapted or used commercially, in whole or in part, without the prior written permission of IRENIS GmbH. Any permitted quotation or reference must clearly identify IRENIS GmbH as the source and, for online use, include a link to the original publication. Third-party trademarks and credited materials remain the property of their respective owners.
