ATSC to IP gateway guide for IPTV delivery using multicast, SPTS, bandwidth planning, and Thor Broadcast equipment.
This knowledge base article explains how to move local off-air ATSC channels into an IPTV system, when to use a direct RF-to-IP gateway, when to re-encode to H.264 for bandwidth efficiency, and how to plan decoding, monitoring, and multicast transport on the receiving side.
Table of Contents
A common IPTV challenge is adding local channels to a remote headend. In many deployments, the local ATSC signals are available at one site, but the IPTV platform is located elsewhere. The objective is to receive the RF channels, select the required programs, and transport them over IP to the headend for ingestion into the IPTV platform.
The most important design decision is whether the IPTV system can accept the original transport stream format directly, or whether the channels need to be converted into a different codec such as H.264. That single requirement determines whether a simple ATSC to IP gateway is enough, or whether a tuner-plus-encoder workflow is needed.
In many real-world deployments, a direct RF-to-IP gateway is the most efficient solution because it does not transcode or alter the original video. It simply tunes the ATSC channels, identifies the services inside each RF carrier, and makes those services available as IP streams.
This means the gateway preserves the original picture quality and transport characteristics. The stream that comes out is effectively the stream that went in, just translated from RF/coax to Ethernet/IP delivery. That is particularly attractive when quality preservation, low latency, and system simplicity matter more than maximum compression.
One of the most important capabilities in an ATSC to IP deployment is SPTS, or Single Program Transport Stream. Instead of moving the entire RF multiplex as one large payload, SPTS allows the operator to choose only the subchannels or programs that matter.
For example, if one RF carrier includes several subchannels and only two or three are required for the IPTV lineup, those can be extracted and output as separate multicast or unicast streams. This is a practical way to avoid carrying unwanted services across the network while still preserving the original program quality of the selected channels.
Bandwidth planning should start with a realistic understanding of the source. ATSC transport streams can approach roughly 19 Mbps for a full RF stream, depending on the service mix. If you pass the entire transport stream, that full rate must be accommodated on the network. If you extract only selected services via SPTS, the transport load can be reduced, but the degree of savings depends on how much of the multiplex is being omitted.
In a project with approximately 6 RF channels and around 16 total desired programs, the main bandwidth questions are:
When the network is stable and multicast-capable, direct SPTS transport can be highly practical. When the link is constrained, or when H.264 is mandated by the IPTV platform, encoding becomes the bandwidth-optimized design.
IPTV distribution is often best handled with UDP multicast, especially when multiple receivers or downstream systems need access to the same services. Multicast is efficient because one stream can serve multiple destinations without duplicating traffic for every endpoint.
A multicast-ready network should be designed with a proper IP switch and IGMP support. IGMP allows the switch infrastructure to manage multicast group membership so traffic is forwarded only where needed. Without correct multicast handling, IPTV traffic can become wasteful or unstable.
A gateway is ideal when you want a direct RF-to-IP translation. However, there are cases where a re-encoding workflow is the better answer. The two most common reasons are:
In that scenario, the design changes. Instead of simply translating RF to IP, the channels must first be decoded to baseband or HDMI and then re-encoded into H.264 or H.265 for IPTV transport. This adds hardware and complexity, but it can dramatically improve bandwidth efficiency and compatibility with modern IPTV headends and smart-device ecosystems.
| Product | Role in the System | Best Use Case |
|---|---|---|
| H-8ATSC-IP 8 ATSC inputs to IP gateway |
Tunes ATSC RF channels and outputs multicast or unicast IP streams, including SPTS selection of individual subchannels. | Best first-choice product for transporting local off-air channels to a remote IPTV headend without re-encoding. |
| H-HDPerformux-16 16-channel HDMI to IP H.264 / H.265 encoder |
Encodes up to 16 HDMI sources into IPTV streams using H.264 or H.265. | Best for mid-scale deployments where approximately 16 channels need bitrate reduction or H.264/H.265 compatibility. |
| H-HDPerformux-24 24-channel HDMI to IP H.264 / H.265 encoder |
Higher-density encoding platform for larger channel counts or future expansion. | Best when additional growth is expected or when the project may exceed 16 encoded programs. |
| H-STB-QAM-ATSC ATSC / Clear QAM to HDMI decoder set-top box |
Decodes RF signals to HDMI for local monitoring, validation, and viewing. | Useful for confidence monitoring and signal verification during install, testing, and troubleshooting. |
If the goal is to move around 6 RF channels and about 16 desired services into an IPTV system, the H-8ATSC-IP is typically the natural starting point. It covers the RF count and supports selection of multiple subchannels from each carrier. If the IPTV provider later confirms a hard requirement for H.264, then a decode-and-encode workflow built around the H-HDPerformux-16 or H-HDPerformux-24 becomes the more appropriate design.
No. A gateway translates RF transport streams into IP streams. It can improve practical efficiency by allowing you to select only the services you want, but it does not re-compress video. If the source is MPEG-2, the output remains MPEG-2 unless you encode it with a separate compression stage.
Yes. A single ATSC RF carrier can contain multiple programs or subchannels. With the correct gateway configuration, multiple subchannels from one tuned carrier can be extracted and output as separate IPTV streams.
Usually yes, depending on the endpoint. IP streams still need a decoder, player, middleware platform, or IPTV headend ingestion workflow. A computer running a compatible player may be able to decode the multicast stream for testing, while production televisions often need a dedicated IPTV or RF decoding method.
Then use a decoding and re-encoding path. This adds cost and complexity but improves interoperability and bandwidth efficiency.
Start by confirming two things: whether the network supports multicast with IGMP, and whether the IPTV platform can ingest the original stream format from the gateway. If both answers are yes, the gateway path is usually the fastest and most cost-effective design.
For education, planning, and real deployment strategy, the key lesson is simple: choose the least complex architecture that still satisfies codec, bandwidth, and endpoint requirements. In many local-channel transport projects, that means using a direct RF-to-IP gateway such as the Thor Broadcast H-8ATSC-IP with multicast and SPTS selection. If the IPTV ecosystem demands H.264 or the transport path is more constrained, scale into a higher-density encoder workflow using the H-HDPerformux-16 or H-HDPerformux-24.
This educational article is intended as a technical knowledge-base reference for ATSC to IPTV transport planning, multicast video design, IPTV headend integration, and RF channel distribution workflows.
ES
