Troubleshoot H.264 and HEVC MPEG-TS streams distributed over QAM with the Thor H-IPRF-QAM-32CH. Learn how SPS/VUI timing, PID mapping, Service IDs, VCT/PSIP and TV decoder state can cause missing video despite excellent RF signal quality.
Table of Contents
A real-world IPTV-to-QAM deployment using the Thor Broadcast H-IPRF-QAM-32CH uncovered an unusually difficult interoperability issue involving H.264 timing metadata, MPEG transport stream parsing, television decoder behavior, PSIP/VCT channel information, Service IDs, and codec changes between H.264 and HEVC.
The installation did not use a traditional broadcast encoder as the video source.
Instead, prerecorded video files were played from Linux servers using FFmpeg, converted or remultiplexed into MPEG Transport Streams, delivered by UDP multicast to the Thor IPTV-to-QAM unit, and then converted to QAM for distribution to televisions over coax.
The complete signal path was:
EN
Prerecorded Video File
↓
Linux Server
↓
FFmpeg
↓
MPEG-TS
↓
UDP Multicast
↓
Thor H-IPRF-QAM-32CH
↓
QAM RF
↓
Coax Distribution
↓
LG Television
The system had already successfully handled H.264, HEVC, AC-3, and even 4K60 HEVC content. However, certain H.264 source files caused a very unusual failure where the television continued to report excellent RF signal strength and signal quality but produced no video or audio.
After extensive testing, the problem was traced not to the QAM RF layer, but to abnormal timing information embedded inside the original H.264 elementary streams.
This application example demonstrates an important principle for IPTV and digital television systems:
A source file can play normally on a computer and still contain H.264 elementary-stream parameters that are unsuitable for reliable broadcast or QAM television distribution.
The customer initially reported that the H-IPRF-QAM-32CH had previously operated correctly with:
During testing of several H.264 files, however, the system eventually reached a condition where the television showed:
The troubleshooting process included:
Even after all of those steps, the TV could still receive the RF carrier correctly but fail to decode the service.
This distinction is very important.
A digital television chain contains several independent layers.
The television first has to receive and demodulate the QAM carrier.
This includes:
A TV reporting strong signal only proves that this layer is working.
Inside the RF carrier, the receiver must then correctly interpret the MPEG transport stream.
That includes:
After demultiplexing, the television must decode the actual video and audio.
For H.264, this includes:
A problem at this level can therefore cause a television to show excellent RF quality while still producing no picture.
One of the first items investigated was the Service ID.
Some television receivers can be sensitive to the Service ID or program-numbering structure used in the transport stream.
The Thor unit may initially create values such as:
1001
2001
3001
During troubleshooting, one recommendation was to temporarily test the program with:
Service ID = 1
The Service ID is changed within the Output TS program properties.
This can be a useful compatibility test when a television sees the QAM signal but does not correctly recognize the service.
However, in this particular case, Service ID was not the final root cause.
The Service ID identifies an individual service or program inside the transport stream.
Conceptually:
Transport Stream
│
├── Service 1
│ ├── Video
│ └── Audio
│
├── Service 2
│ ├── Video
│ └── Audio
│
└── Service 3
├── Video
└── Audio
The Service ID identifies the program itself.
This should not be confused with:
These are all separate elements of the digital television system.
The customer eventually discovered that the source files themselves contained unusual H.264 SPS/VUI timing values.
One problem file contained:
num_units_in_tick = 1
time_scale = 2000000000
fixed_frame_rate_flag = 0
Yet the actual content was normal:
59.94 fps
The embedded timing information therefore did not reasonably represent the actual video frame rate.
Importantly, this was not introduced by FFmpeg.
The same SPS/VUI information was already present in the original H.264 file before the file was placed into MPEG-TS.
The customer then scanned approximately:
1,600 H.264 files
and discovered:
They selected 20 representative files and individually tested them through the complete broadcast chain:
File
↓
FFmpeg
↓
MPEG-TS
↓
UDP Multicast
↓
Thor
↓
QAM
↓
Coax
↓
LG Television
The results were very revealing.
Every tested sample from the unusual 1 / 2000000000 timing family caused the LG television to enter the abnormal decoder state.
Another source containing similarly unrealistic timing values of approximately:
1 / 180000
also produced the same behavior.
SPS means:
Sequence Parameter Set
The SPS contains information needed by the video decoder to correctly interpret the H.264 elementary stream.
It can include:
A decoder must understand this information before it can reliably decode the pictures.
VUI means:
Video Usability Information
The VUI is an optional part of the H.264 SPS that provides additional information describing how the video should be interpreted.
Among the available VUI fields are timing parameters such as:
num_units_in_tick
time_scale
fixed_frame_rate_flag
These values can help describe frame timing.
If the timing information is wildly inconsistent with the actual video, different decoders may react differently.
This is one of the most important lessons from the entire case.
The problem files played normally in ordinary computer media players.
That is because modern software players are often very forgiving.
A software player may use:
A television's embedded hardware broadcast decoder may not behave the same way.
The same file that appears completely normal in a computer player can therefore become problematic when transported through:
H.264
↓
MPEG-TS
↓
QAM
↓
TV tuner/demultiplexer
↓
hardware video decoder
The customer specifically concluded that a file being labeled:
H.264 1080p/59.94
does not guarantee that the H.264 elementary stream itself contains sensible broadcast timing values.
One of the most unusual findings was that the malformed source could apparently put the LG television decoder into an abnormal state.
Once this happened:
The television did not fully recover until AC power was physically removed for approximately:
10–15 seconds
and in earlier testing, sometimes approximately:
15–30 seconds
before being reapplied.
This has an important troubleshooting implication.
After removing the bad source and returning to a known-good stream, the Thor unit may already be transmitting a valid signal.
However, the television decoder can remain locked in a bad state.
Therefore, technicians should not automatically assume that the QAM modulator remains defective.
When testing after an abnormal stream condition, physically remove AC power from the television for at least several seconds before continuing.
A normal remote-control power-off may not necessarily clear all tuner and decoder state.
The decisive test was to re-encode the problematic H.264 files.
After re-encoding the same source material using normal H.264 timing parameters:
the problem disappeared completely.
The customer therefore made an important architectural decision.
Instead of feeding arbitrary H.264 files directly into the broadcast system, they began creating standardized production masters.
Their current tested 1080p production standard includes:
At playback time, FFmpeg does not re-encode the material again.
FFmpeg simply remultiplexes the standardized master into MPEG-TS and transmits the resulting stream over UDP multicast.
The customer reports that this configuration has performed very well.
The customer sends MPEG-TS using:
1316-byte UDP payloads
This is a very common transport size for MPEG-TS.
Each MPEG Transport Stream packet is:
188 bytes
Seven packets are:
188 × 7 = 1316 bytes
So a UDP datagram can contain:
TS Packet 1
TS Packet 2
TS Packet 3
TS Packet 4
TS Packet 5
TS Packet 6
TS Packet 7
────────────────
1316 bytes
This allows multiple complete MPEG-TS packets to be carried efficiently while remaining suitable for standard Ethernet networks.
Another important discovery concerned changing the video codec of an existing input.
For example:
H.264 → HEVC
or:
HEVC → H.264
When making this type of change, the incoming PMT and stream type change.
The proper workflow is not simply to change the source and press Reparse while the old program remains assigned to the output.
The correct sequence is:
Before changing the stream type, remove the current program from the selected Output TS.
For example:
H.264 → HEVC
Use:
Reparse TS
on the input.
The unit will inspect the incoming transport stream again and discover the new:
Confirm that the newly detected TS/program appears correctly.
After the new input has been parsed, manually move or assign the detected program back into the appropriate:
Output TS 1
...
Output TS 32
The sequence is therefore:
Remove program from Output TS
↓
Change H.264 / HEVC source
↓
Reparse TS
↓
Detect new PMT / stream type
↓
Manually assign program back to Output TS
This procedure is especially important when the codec itself changes because the PMT's elementary-stream type is different.
The customer's testing showed that some changes within HEVC, such as different frame rates or resolutions, did not always require the same manual reparse process, but a codec change between H.264 and HEVC should be treated as a significant transport-stream change.
The PMT, or:
Program Map Table
tells the television what streams belong to a program.
For example:
Program 1
│
├── PMT
│
├── Video PID 0x0101
│ Stream Type = H.264
│
├── Audio PID 0x0102
│ Stream Type = AC-3
│
└── PCR PID 0x0101
If the incoming video is changed to HEVC, the video stream type must also change.
Conceptually:
Before
Video PID 0x0101 → H.264
After
Video PID 0x0101 → HEVC
The remultiplexer therefore has to inspect the updated PMT before rebuilding the output correctly.
For a 32-channel deployment, the customer also asked whether all 32 multicast inputs could be provisioned at once.
For example:
224.2.2.2:1001
224.2.2.2:1002
224.2.2.2:1003
224.2.2.2:1004
...
At this time, the unit does not provide a supported method for batch provisioning of all 32 TS inputs.
There is currently no:
Each IP multicast address and UDP port must be entered individually through the web interface.
For larger deployments, this should be taken into consideration during initial system setup and when preparing replacement or spare units.
A future batch configuration or configuration-import capability would significantly reduce commissioning time for systems using predictable multicast addressing.
Another important feature in a multi-program system is PID handling.
PID means:
Packet Identifier
Each component inside an MPEG Transport Stream is identified by its PID.
For example:
PAT PID 0
PMT PID 100
Video PID 101
Audio PID 102
PCR PID 101
When PID Pass Through is used, the incoming PID numbering can be preserved at the output.
For example:
INPUT
Video PID = 256
Audio PID = 257
↓
PID PASS THROUGH
↓
OUTPUT
Video PID = 256
Audio PID = 257
This can be useful when the incoming transport stream has already been correctly engineered and you want to preserve its PID structure.
PID remapping allows the remultiplexer to change the PID numbers used in the output transport stream.
This becomes particularly important when multiple independent input streams reuse the same PID values.
For example:
Input 1
Video PID = 256
Audio PID = 257
Input 2
Video PID = 256
Audio PID = 257
Input 3
Video PID = 256
Audio PID = 257
Those streams are independent before they are multiplexed.
Once several programs are placed into the same output transport, PID collisions must be avoided.
The remultiplexer can therefore assign different output PIDs.
For example:
Program 1
Video PID = 256
Audio PID = 257
Program 2
Video PID = 300
Audio PID = 301
Program 3
Video PID = 400
Audio PID = 401
The PMT associated with each service must then point to the new output PIDs.
This is one of the main reasons PID remapping is useful in IPTV-to-QAM systems.
These items should not be confused.
Identifies the service/program.
Example:
Service ID = 1
Identifies an elementary stream or transport component.
Example:
Video PID = 101
Audio PID = 102
The virtual channel number displayed by the television.
Example:
23
The subchannel displayed by the television.
Example:
1
Combined:
23-1
The channel label displayed by the TV.
Example:
Hip-Hop
All of these values serve different purposes.
The H-IPRF-QAM-32CH can either:
For custom QAM channel naming and virtual channel numbering, VCT/CVCT must first be enabled.
This is the portion of the configuration that determines how a television identifies and displays a virtual channel such as:
23-1 Hip-Hop
24-1 Top50
25-1 Country
26-1 Jazz
VCT means:
Virtual Channel Table
For cable television applications, this is typically represented as:
CVCT - Cable Virtual Channel Table
The VCT/CVCT provides television receivers with information such as:
This allows the number displayed by the television to be independent from the actual RF frequency carrying the signal.
Suppose a QAM carrier is transmitted at approximately:
57 MHz
which corresponds to physical cable channel:
Channel 2
Without virtual channel information, the television may primarily identify the service from:
The customer may instead want the television to display:
23-1 Hip-Hop
even though that service physically exists on QAM RF channel 2.
This is what VCT/CVCT makes possible.
In the Thor web interface, go to:
Parameters
↓
TS Config
↓
General
In the General tab, enable:
VCT / CVCT
This must be turned on first.
If VCT/CVCT is disabled, the custom major/minor channel information will not be transmitted to the TV in the intended way.
After enabling VCT/CVCT, go to the desired:
Output TS 1
Output TS 2
Output TS 3
...
Output TS 32
Select or click the program inside that Output TS.
A program-properties pop-up window will appear.
Within that program configuration, assign:
For example:
Output TS 1
Major Channel: 23
Minor Channel: 1
Short Name: Hip-Hop
Another output TS could be:
Output TS 2
Major Channel: 24
Minor Channel: 1
Short Name: Top50
Another:
Output TS 3
Major Channel: 25
Minor Channel: 1
Short Name: Country
And another:
Output TS 4
Major Channel: 26
Minor Channel: 1
Short Name: Jazz
Each Output TS/program can therefore have its own independent virtual channel identity.
When the television performs a cable channel scan, it first discovers the physical QAM carrier.
For example:
57 MHz
The television then demodulates the QAM signal and reads the MPEG transport stream.
If VCT/CVCT is enabled, the television can read the virtual channel information.
The process is approximately:
Physical RF Frequency
↓
QAM Demodulation
↓
MPEG Transport Stream
↓
PAT / PMT
↓
VCT / CVCT
↓
Major Channel
Minor Channel
Short Name
↓
TV Channel List
The television can therefore display:
23-1 Hip-Hop
instead of simply displaying the physical RF channel.
If VCT/CVCT is not enabled in the General tab, the television will normally identify the service using the physical channel information and Service ID rather than the custom virtual-channel assignment.
For example:
Physical RF:
57 MHz
Physical cable channel:
2
The TV may then use the physical channel as the major channel and use the Service ID as the minor/program identifier, depending on the television.
Conceptually:
VCT OFF
Physical Channel
+
Service ID
↓
TV Channel Display
Instead of:
VCT ON
Configured Major
+
Configured Minor
+
Short Name
↓
23-1 Hip-Hop
This difference is extremely important when deploying QAM systems in hotels, hospitality facilities, commercial buildings, campuses, entertainment venues, or private cable systems where users need recognizable channel numbers and channel names.
Another important point is that VCT configuration is associated with the program in the Output TS.
It is not simply a global name attached to the RF carrier.
One RF QAM carrier can contain multiple programs.
Each program can therefore have its own:
For example:
Physical QAM Carrier
57 MHz
│
├── Program A
│ ├── Major 23
│ ├── Minor 1
│ └── Hip-Hop
│
├── Program B
│ ├── Major 24
│ ├── Minor 1
│ └── Top50
│
└── Program C
├── Major 25
├── Minor 1
└── Country
The physical RF channel and the channel number shown to the viewer are therefore two different concepts.
Suppose a system has four multicast inputs:
224.2.2.2:1001
224.2.2.2:1002
224.2.2.2:1003
224.2.2.2:1004
They carry:
Hip-Hop
Top50
Country
Jazz
The operator could configure the Thor outputs so the television displays:
23-1 Hip-Hop
24-1 Top50
25-1 Country
26-1 Jazz
The viewers never need to know:
Those are transport and headend parameters.
The viewer sees only the virtual channel information defined in the VCT/CVCT.
There are two common situations.
If the incoming source already contains valid channel information, it may be appropriate to preserve/pass the relevant information.
For a custom system, the operator can enable VCT/CVCT and create the desired virtual channel lineup inside the Thor configuration.
For example:
23-1 Hip-Hop
24-1 Top50
25-1 Country
26-1 Jazz
This is particularly useful for:
If a customer reports:
“The television shows 100% signal but there is no picture or sound.”
use the following process.
Confirm:
Confirm:
Confirm the Thor detects:
If the TV sees the RF channel but not the program, test with a simple Service ID such as:
1
when appropriate.
Verify:
When combining several sources, check whether multiple programs use identical PIDs.
Use PID remapping where required.
Remove program from Output TS
↓
Change codec/source
↓
Reparse TS
↓
Detect new program
↓
Move new program back into Output TS
Check:
This is one of the best ways to determine whether the problem is:
If the TV previously received a malformed stream, physically disconnect AC power for approximately 10–30 seconds.
Do not assume that a normal remote-control power cycle clears all decoder state.
If the re-encoded version works and the original does not, normalize the content library instead of repeatedly changing headend configuration.
For file-based IPTV/QAM applications, validate at least:
This case demonstrates why troubleshooting digital television systems should not stop at RF signal strength.
A signal can simultaneously have:
and still fail because of information inside the elementary video stream.
The failure may occur at a layer much deeper than the RF system.
The most important diagnostic lesson is:
When a television receives a strong QAM signal but produces no video or audio, inspect not only the RF and MPEG transport structure, but also the elementary-stream codec parameters, SPS/VUI timing, PMT, Service ID, PID mapping, and receiver state.
Because RF signal quality only confirms that the television can demodulate the QAM carrier. The failure may still be caused by PMT, PIDs, codec information, H.264 SPS/VUI timing, audio format, or the television decoder itself.
Yes. Computer software players can tolerate or compensate for unusual timing information that an embedded TV decoder may not handle correctly.
Remove the existing program from the Output TS, change the source, use Reparse TS, allow the Thor to detect the new PMT/stream type, and then manually assign the new program back to the desired Output TS.
Yes. Enable VCT/CVCT under TS Config → General, then configure the major channel number, minor channel number, and short name for the desired program in the appropriate Output TS.
The television will generally identify the service based on the physical RF channel and Service ID rather than your custom virtual major/minor channel information.
Yes. Each Output TS/program can be assigned its own major number, minor number, and short name.
No. There is currently no batch configuration, API, CLI, SNMP provisioning, or bulk-import function for the 32 TS inputs. Each multicast IP address and UDP port must be configured individually through the web interface.
PID pass-through preserves the incoming PID values. PID remapping allows output PIDs to be changed, which is useful when combining multiple input streams that reuse the same PID numbers.
Certain malformed or unusual streams may leave the television's tuner/demultiplexer/decoder in an abnormal internal state. Returning to a valid stream may not clear that state. Removing AC power for approximately 10–30 seconds may be necessary.
