IPTV System Design
BLANKOM Engineering Guide Series
GUIDE 07 / 12
EPG · EIT · SDT · SID REMAP · TDT/TOT · RECEIVER VALIDATION
Preserve EPG in IPTV:
EIT Processing and Receiver Validation
An IPTV service can carry perfect video and audio while losing its programme guide. Preserve the EIT when an MPTS is converted to SPTS, keep service IDs and time information coherent, and validate the result on the actual receiving device.
01 · DEFINE THE EPG REQUIREMENT
“EPG required” is not a complete specification
The Electronic Programme Guide carried in a DVB transport stream is not a separate video service. It is signalling data, primarily in the Event Information Table (EIT), linked to the service description and service identity. When a receiver-streamer extracts one TV service from an MPTS and creates an SPTS, the EPG has to remain logically attached to that service.[1, pp. 40, 59–61]
Before selecting equipment, define what the client actually needs: no EPG, present/following only, or a schedule; which languages matter; whether PVR depends on the guide; and which TV, STB or middleware will display it.
NONE
No programme guide
Acceptable only when the project deliberately requires basic linear zapping and the customer accepts the missing programme information.
BASIC
Present / following
The receiver shows what is on now and what comes next, provided the EIT is processed correctly and the endpoint supports it.
FULL
Schedule EPG
Several hours or days of programme data may be required for browsing, middleware functions or recording. Define the required depth explicitly.
02 · FOLLOW THE TABLE RELATIONSHIPS
The EIT is linked to the service identity and to the time base
The planning guide identifies the EIT on PID 18 decimal (0x0012). The SDT indicates whether EIT information is present for a service, and the EIT itself is linked to the service ID (SID). Correct TDT/TOT information is also important because EPG events depend on the broadcast time and local offset.[1, pp. 40, 59]
| Item | Role | Why it matters for EPG |
|---|---|---|
| EIT | Events / programme guide | Carries present/following and schedule information associated with services. |
| SDT | Service description | Carries service information and flags indicating EIT availability. |
| SID | Service identity | If a service ID is remapped, the EIT relationship must follow the remapping. |
| TDT / TOT | Date, time, local offset | Incorrect time information can make otherwise valid events appear at the wrong time. |
Figure 1. Full EIT / SDT example and a demultiplexed EIT in an SPTS, reproduced from the IPTV Headend Planning Guide, 2nd edition (2026), Figure 20.1.
03 · KEEP EPG ATTACHED TO THE SPTS
Demultiplexing the service also means remapping and rewriting its EIT correctly
When a headend selects one service from the incoming multiplex, it may also remap the service ID. The planning guide states that this SID remapping has to be applied to the demultiplexed EIT and that the result must be rewritten into the outgoing table carousel. The EIT itself is dynamic: old event information disappears and new event data is added over time.[1, p. 59]
-
Select the service
Identify the wanted service in the incoming MPTS and its original service ID.
-
Demultiplex the required EIT
Extract the event information that belongs to that service instead of discarding all multiplex-level EIT data.
-
Apply SID remapping
If the outgoing SPTS uses a different service ID, update the EIT relationship accordingly.
-
Rewrite and inject
Play the processed EIT out as part of the outgoing service signalling at a suitable rate.
-
Observe over time
Because EIT is a carousel, validate more than a single static snapshot when schedule information is required.
04 · DEFINE HOW MUCH EPG YOU NEED
Present/following and a full schedule are different requirements
The source guide distinguishes present/following information from scheduled EPG data. A basic linear IPTV system may provide only present/following information, and even that depends on the receiving device. More advanced EPG processing can create present/following plus schedule information and control playout rate, schedule and language priority.[1, pp. 59–61]
PRESENT / FOLLOWING
Minimum useful guide
Useful when the endpoint only needs the current event and the next event. State explicitly whether this is sufficient for the project.
SCHEDULE
Browse and recording use cases
Define how much schedule depth is required and which languages matter. PVR and richer middleware functions normally make the programme database more important.
05 · CHOOSE THE EPG SOURCE
Broadcast EIT is one route; XMLTV and middleware databases are others
The planning guide describes three practical EPG paths. A headend may demultiplex EIT from the broadcast multiplex and attach it to the selected SPTS. An EPG processor may also import XMLTV or data from an internet/internal EPG service and generate EIT. A middleware platform can maintain its own programme database and present the guide to clients through its user interface.[1, pp. 59–61]
BROADCAST EIT
Preserve what arrives with DVB
Demultiplex, remap and rewrite the service-related EIT from the incoming MPTS into the outgoing SPTS.
XMLTV / EPG SERVICE
Generate a controlled EIT
An EPG processor can use file-based or IP-delivered programme data and generate outgoing EIT profiles.
MIDDLEWARE
Build an application-level guide
The middleware stores programme data in its own database and presents it through the client interface; this is separate from relying only on EIT inside each SPTS.
Figure 2. EPG processor module and functional blocks reproduced from the IPTV Headend Planning Guide, 2nd edition (2026), Figure 20.2. Product image and diagram are a source example; verify current availability and configuration separately.
06 · VALIDATE ON THE ACTUAL ENDPOINT
Commission the EPG as a complete path: source → headend → SPTS → receiver
The following is an editorial commissioning workflow for this Engineering Guide. It translates the source guide’s EIT, SID, time and endpoint requirements into a repeatable acceptance process; it is not a quoted manufacturer test procedure.
-
Record the incoming reference
Identify the source transponder, service name/SID and whether the incoming multiplex carries present/following and schedule EIT.
-
Check SDT and time information
Confirm that the service description and EIT flags are coherent and that TDT/TOT reflect the intended time and offset.
-
Inspect the outgoing SPTS
Confirm the outgoing service ID, presence of EIT and the relationship between the rewritten service identity and its event data.
-
Wait for carousel updates
Observe the service long enough to prove that new event data appears and old events roll out as expected.
-
Test the real client
Use the actual hospitality TV, STB or middleware client planned for the project. Check present/following, schedule depth, language and displayed time.
-
Document the result
Record the headend configuration, endpoint model/software, test time, EPG depth and any limitations for handover.
07 · REVIEW BEFORE MODEL SELECTION
EPG / EIT requirement checklist
- Required services and source transponders are identified.
- EPG requirement is defined as none, present/following or schedule.
- Broadcast EIT, XMLTV/EPG service or middleware database is selected as the programme-data source.
- Service-ID remapping requirements are known.
- TDT/TOT and local time/offset behaviour are part of validation.
- Required EPG languages are documented.
- The actual TV/STB/middleware client for acceptance is identified.
- PVR or recording functions that depend on programme data are declared.
- Exact headend/model/firmware support is confirmed before quotation.
- Commissioning records include the observed EPG depth and any limitations.
CUSTOMER REFERENCE
Use the guide to state exactly what “EPG support” means in a quotation
A quotation can reference the relevant section when EPG preservation is part of the proposed solution. The quotation itself should still name the selected equipment and state the confirmed EPG behaviour for that exact configuration.
“The proposed IPTV headend is specified to preserve the programme-guide behaviour required for the selected services. Please refer to BLANKOM Engineering Guide 07 for the EIT/SID/time relationships and receiver-validation method used to define this requirement.”
08 · DEFINE THE PROGRAMME-GUIDE REQUIREMENT
What to include in your EPG / EIT RFQ
Tell us which services need programme information, how much EPG you expect, where the programme data comes from and which endpoint must display it.
The most useful request identifies the source service, required EPG depth, EPG source, service-ID handling, languages, time-zone behaviour and the TV/STB/middleware client used for acceptance.
The request opens the existing IRENIS / BLANKOM enquiry page. Exact model and software support will be confirmed for your project.
Project brief outline
IPTV EPG / EIT PROJECT BRIEF Country / installation location: Source standard and transponder: Required TV/radio services: EPG requirement: [ ] none [ ] present / following [ ] schedule Required schedule depth: Required languages: EPG source: [ ] broadcast EIT [ ] XMLTV / external EPG service [ ] middleware database Service-ID remapping expected: yes / no / unknown TDT/TOT / local time requirement: PVR / recording dependent on EPG: yes / no Endpoint model(s): TV / STB / middleware: Endpoint software / firmware: Acceptance requirement / test window: Current headend / equipment to retain: Quantity / timing / open questions: Reference: IPTV System Design - Guide 07, BLANKOM
ENGINEERING FAQ
Questions that matter in EPG commissioning
Is EIT the same thing as EPG?
The EPG is the programme-guide information presented to the user. In DVB, that information is carried primarily in the Event Information Table (EIT). A middleware platform may instead maintain its own programme database.
Why can video work while the programme guide is missing?
Video/audio decoding depends on the service’s elementary streams and programme signalling. The EIT can be omitted or linked incorrectly while the A/V payload still decodes normally.
Why does SID remapping matter?
The EIT is associated with a service identity. If the headend changes the service ID when creating the SPTS, the corresponding EIT relationship must be updated as well.
Do we always need a full schedule?
No. Some projects need only present/following; others require schedule data for browsing, middleware functions or recording. Define the required result before selecting equipment.
Can we validate EPG only with a transport-stream analyser?
No. The analyser verifies that the table data exists and is coherent. Final acceptance should also use the actual TV, STB or middleware client because endpoint behaviour determines what the user sees.
SOURCE BASIS
Primary engineering source
This guide reformulates the EPG/EIT sections of Ralf Riedel’s published 2026 second edition. The receiver-validation workflow, RFQ structure and quotation-reference wording are editorial engineering tools added for the web series; they are not manufacturer specifications.
- Ralf Riedel — IPTV Headend Planning Guide, 2nd edition (2026)
Primary scope: Chapter 12, p. 40 for EIT / SDT / TDT-TOT relationships; Chapter 20, pp. 59–61 for EIT demultiplexing, SID remapping, EPG processing and XMLTV/EPG-module paths.
Document reference: BLANKOM-EG-IPTV-07 · Web revision 1.0
IPTV System Design · BLANKOM Engineering Guide Series
- Requirements and ArchitectureGuide 01
- Services, Transponders and Tuner CountsGuide 02
- SAT-IF DistributionGuide 03
- IPTV Headend SelectionGuide 04
- Pay-TV IntegrationGuide 05
- DVB Transport Stream ValidationGuide 06
- EPG / EIT Processing and Receiver ValidationGuide 07
- IPTV Multicast Network DesignGuide 08
- IPTV Stream DeliveryGuide 09
- Local Video SourcesGuide 10
- IPTV Endpoints and ServicesGuide 11
- Resilience and OperationsGuide 12
© 2022–2026 BLANKOM, IRENIS GmbH. All rights reserved. Technical details, product names and compatibility are subject to change. Verify current product documentation and project-specific requirements before specification or purchase.
