IPTV System Design
BLANKOM Engineering Guide Series
GUIDE 06 / 12
DVB TRANSPORT STREAM · PSI/SI · PCR · CONTINUITY · DYNAMIC PMT
Validate DVB Transport Streams:
PSI/SI, PCR and Dynamic PMT
A stable picture is not enough to prove that a DVB-to-IP stream is correct. Validate the programme tables and PIDs, confirm PCR timing and continuity, and make sure the headend follows dynamic service changes before the stream is accepted for IPTV distribution.
01 · DEFINE STREAM ACCEPTANCE
A picture on the screen proves less than you may think
A receiver may show video and audio while the transport stream still contains table, PID, timing or continuity problems. The 2026 planning guide therefore recommends looking inside the DVB transport stream rather than judging the headend only by the visible picture.[1, pp. 36–44]
This guide concentrates on transport-stream validation at the DVB-to-IP boundary: how an incoming MPTS becomes service-level SPTS outputs, which PSI/SI information must remain coherent, and which timing and continuity conditions need to be checked before acceptance.
02 · UNDERSTAND THE DEMULTIPLEXING TASK
One transponder arrives as an MPTS; IPTV normally needs service-level SPTS streams
A DVB transponder carries a multi-programme transport stream containing several TV/radio services plus signalling and data. The receiver-streamer receives the complete MPTS, selects the required services and creates individual SPTS outputs. The source guide notes that these SPTS outputs are normally variable-bit-rate streams and do not need the null-packet stuffing used to fill a constant-bit-rate DVB multiplex.[1, pp. 36–37]
INPUT
MPTS
One RF transponder carrying multiple services, shared PSI/SI tables and, where applicable, conditional-access information.
PROCESS
Demultiplex and rewrite
Select the requested services, retain the required elementary streams and rebuild coherent service-level tables.
OUTPUT
SPTS per service
Each output contains the selected service, the table information needed by the receiver and its assigned IP destination.
Figure 1. Example analyser view of an incoming MPTS, reproduced from the IPTV Headend Planning Guide, 2nd edition (2026), Chapter 12.
03 · VERIFY THE PROGRAMME MAP
Check the tables and PID relationships that tell the receiver what the service contains
The source guide identifies the PAT, PMT, SDT, EIT and TDT/TOT among the important tables in the DVB transport stream. The PAT identifies programmes and their PMTs; each PMT identifies the video, audio and data PIDs and the PID carrying the PCR. SDT carries service names and provider information. EIT and time tables matter when programme-guide information is required.[1, pp. 39–41]
| Item | What it describes | Validation question |
|---|---|---|
| PAT | Programme list and the PID of each programme’s PMT. | Does the selected service point to the PMT that is actually present in the output? |
| PMT | Video, audio, data and PCR PIDs belonging to the service. | Do the listed PIDs match the elementary streams in the SPTS, and are PMT changes followed when they occur? |
| SDT | Service name and provider information. | Is the service identity coherent after any remapping or demultiplexing? |
| CAT / ECM | Conditional-access signalling where encrypted content is present. | Is the selected service intended to remain encrypted or has it been lawfully descrambled upstream? Validate the chosen pay-TV architecture separately. |
| EIT + TDT/TOT | Programme-guide events and the time basis used with them. | If EPG is required, is the relevant information present and coherent? Detailed EIT processing is covered in Guide 07. |
| Elementary PIDs | Video, audio, subtitles/teletext and other service components. | Are only the intended components present, and do the PMT references match them? |
Figure 2. DVB/MPEG table families reproduced from the IPTV Headend Planning Guide, 2nd edition (2026), Chapter 12. Open the image to inspect the original labels.
For practical validation, inspect the actual incoming and outgoing streams with a transport-stream analyser. The planning guide explicitly warns that broadcasters can transmit wrong table assignments or flag values; those faults are not visible from RF level alone.[1, pp. 38–41]
04 · VERIFY THE DECODER CLOCK
PCR timing is part of stream integrity, not an optional diagnostic
The programme clock reference provides the time base that the decoder uses to synchronise elementary streams. In the source guide, the PMT identifies the PID carrying the PCR; a PCR is transmitted at least every 100 ms, while ETSI TR 101 290 measurement guidance is described as flagging intervals above 40 ms. The guide also states a maximum permitted PCR jitter of ±500 ns.[1, pp. 42–43]
For a project acceptance test, do not reduce this to a single screenshot. Record the service, measurement point, observation period and analyser result so a later fault can be compared with the commissioning baseline.
05 · LOOK FOR LOST PACKETS
Continuity counters show whether packets disappear from a PID sequence
Each PID, except the null-packet PID, carries a four-bit continuity counter that runs from 0x0 to 0xF and wraps back to zero. A gap in the expected sequence reveals a missing packet. The planning guide notes that a rising CC-error count at a receiver input often points to a weak or disturbed RF signal and should trigger investigation of the reception path.[1, p. 43]
Figure 3. Analyser views used for PCR and continuity checks, reproduced from the IPTV Headend Planning Guide, 2nd edition (2026), Figure 13.2.
06 · TEST TIME-DEPENDENT SERVICE CHANGES
Dynamic PMTs can make a service fail only during a regional or scheduled window
Some broadcasters change the PMT during the day. The source example shows regional services that normally point to a main programme but switch to their own audio/video PIDs during a scheduled regional window. A headend that keeps the old PID map may then deliver a black picture or the wrong programme even though the same service appeared correct earlier in the day.[1, p. 44]
Figure 4. Dynamic-PMT example reproduced from the IPTV Headend Planning Guide, 2nd edition (2026), Figure 13.4. The source example illustrates a scheduled regional-content change.
STATIC TEST
Not enough for a dynamic service
A short daytime acceptance test can miss a PMT change that occurs only during a specific regional or scheduled window.
REQUIRED CHECK
Observe the real change
Where the selected broadcaster uses dynamic PMTs, validate the service through at least one known transition or use a controlled test stream that reproduces the change.
07 · MAKE THE CHECK REPEATABLE
A transport-stream validation sequence for commissioning and fault finding
The following sequence is an editorial commissioning method developed from Chapters 12 and 13 of the planning guide. It organises the source material into a repeatable acceptance process; it is not a substitute for the analyser manufacturer’s measurement procedure or an applicable broadcaster specification.
-
Capture the incoming MPTS
Identify the satellite/transponder or other DVB source, record the measurement point and confirm which services are expected.
-
Inspect the PSI/SI structure
Check PAT, PMT, SDT and the service PIDs. For encrypted services, relate CAT/ECM behaviour to the approved pay-TV architecture.
-
Compare the selected SPTS
Verify that the output service contains the intended video/audio/data components and coherent service-level signalling after demultiplexing or remapping.
-
Measure timing and continuity
Observe PCR behaviour and continuity-counter errors over a defined period rather than relying on a single instant.
-
Exercise dynamic behaviour
If the broadcaster changes PMTs, audio tracks or regional content, validate the service through the relevant transition.
-
Confirm the endpoint result
Test the actual TV/STB/decoder expected in the project. Record picture, sound, service identity and any required programme information as acceptance evidence.
Minimum evidence to keep with the project documentation
- Source/transponder and service identification.
- Incoming MPTS and outgoing SPTS measurement points.
- Relevant PAT/PMT/SDT/PID findings.
- PCR and continuity-counter observation results.
- Dynamic-PMT test result where applicable.
- Endpoint model/software used for acceptance.
- Date, analyser/tool and responsible engineer.
CUSTOMER REFERENCE
Use stream-validation requirements to explain why headend functions matter
A quotation can link to the table/PID, PCR or dynamic-PMT section when a project requires more than simple DVB reception. The quotation itself must still identify the selected equipment and state which required functions are confirmed for that exact configuration.
“The proposed DVB-to-IP configuration is based on verified service demultiplexing and transport-stream requirements. Please refer to BLANKOM Engineering Guide 06 for the PSI/SI, PCR, continuity and dynamic-PMT checks relevant to commissioning.”
08 · DEFINE THE STREAM REQUIREMENT
What to include in your transport-stream RFQ
Tell us which DVB services you need and which stream behaviour must be preserved or validated. Where a function is uncertain, mark it “to be confirmed” rather than assuming every gateway handles it.
The most useful request identifies the source/transponder, selected services, required PSI/SI behaviour, programme-guide requirement, dynamic-PMT requirement and the endpoint used for acceptance.
The request opens the existing IRENIS / BLANKOM enquiry page. Exact model and firmware support will be confirmed for your project.
Project brief outline
DVB / IPTV TRANSPORT-STREAM BRIEF Country / installation location: Source standard: DVB-S/S2/S2X, T/T2 or C: Satellite / transponder / frequency: Required TV/radio services: FTA or encrypted: Required output: MPTS / SPTS: PAT/PMT/SDT remapping requirements: EPG/EIT requirement: Dynamic PMT required / observed: Audio / subtitle / teletext components: PCR / continuity acceptance requirement: Receiving TV / STB / decoder: Existing analyser captures available: Quantity / timeline / open questions: Reference: IPTV System Design - Guide 06, BLANKOM
PRACTICAL QUESTIONS
DVB transport-stream validation FAQ
If video and audio are working, is the SPTS validated?
No. A working picture does not by itself prove that PSI/SI, PID mapping, PCR timing, continuity or time-dependent PMT behaviour is correct. Validate the stream structure and the required endpoint behaviour as separate acceptance items.
What does the PMT tell the receiver?
The PMT identifies the elementary-stream PIDs belonging to a programme and the PID carrying its PCR. If the programme changes its PIDs dynamically, the receiving chain must follow the updated PMT.
What does a rising continuity-counter error count mean?
It indicates missing packets in a PID sequence. The source guide notes that rising CC errors at a receiver input often point to weak or disturbed RF reception, but the fault should be isolated through defined measurement points rather than assumed.
Why can a regional channel fail only at certain times?
A broadcaster may change the PMT during a regional window and point the service to different audio/video PIDs. If the headend keeps the previous mapping, the picture can go black or show the wrong programme only during that window.
Is EIT validation part of this guide?
EIT is part of the DVB service-information structure, so its presence and relationship to the service matter here. Detailed EIT demultiplexing, SID remapping, EPG delivery and receiver validation are covered in Guide 07 and the related EIT Technical Paper.
IPTV SYSTEM DESIGN
BLANKOM Engineering Guide Series
This is Guide 06 of the twelve-part web series. Published guides are linked; planned guides remain unlinked until their final URLs exist.
View the twelve-guide programme
- Plan an IPTV System: Requirements and ArchitecturePublished
- Plan Satellite Reception: Services, Transponders and Tuner CountsPublished
- Engineer SAT-IF Distribution: Coax, Fibre and MultiswitchesPublished
- Select an IPTV Headend: Capacity, Interfaces and ExpansionPublished
- Plan Pay-TV Integration: CAMs, Descrambling and Re-encodingPublished
- Validate DVB Transport Streams: PSI/SI, PCR and Dynamic PMTYou are here
- Preserve EPG in IPTV: EIT Processing and Receiver ValidationPlanned
- Design an IPTV Multicast Network: Bandwidth, IGMP and SwitchingPlanned
- Plan IPTV Stream Delivery: Multicast Addresses, UDP/RTP Ports and IP GatewaysPlanned
- Integrate Local Video Sources: Encoding, Transcoding and IP DecodingPlanned
- Select IPTV Endpoints and Services: TVs, STBs, Middleware and SignagePlanned
- Plan IPTV Resilience and Operations: Redundancy, Monitoring and HandoverPlanned
SOURCE BASIS
Primary engineering source
This guide reformulates the transport-stream inspection and timing material in Ralf Riedel’s newly published 2026 second edition. The commissioning sequence, RFQ structure and acceptance-record format are editorial tools developed for this web series. Exact product support must be confirmed against the selected model, hardware and firmware.
- Ralf Riedel — IPTV Headend Planning Guide, 2nd edition (2026), Version 2.0
Primary scope: Chapter 12, pp. 36–41 (MPTS/SPTS, PSI/SI tables, PIDs and analyser use); Chapter 13, pp. 42–44 (PCR timing, continuity counters and dynamic PMTs). Author title in this edition: Director Technical Sales & Engineering, IRENIS GmbH.
Document reference: BLANKOM-EG-IPTV-06 · 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
© 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.
