The IRD works as a Gateway, which means that if the Satellite RF signal carries MPEG4 and MPEG1 or AC3 audio, you will have exactly the same TS on the IP or ASI output with all encoded audios. We cannot transcode it to MPEG2. Basically, whatever goes in will go out.

If the Sat channel has multiple TS's, we can modify it in the MUX setting, but please note that we cannot modify the TS bitrate. Whatever TS is encoded, it will stay the same.

At the same time, we can decode the video and audio to SDI/HDMI/CVBS and Analog Audio. We can only decode 1 stereo audio of your choice. So, even if the TS has, let's say, 1 Spanish + 2 English audio tracks, we can decode one of them.

Since you need MPEG2 video, the easiest way would be to decode that signal to SDI and then re-encode it using an MPEG2/AC3 encoder.

like this one :

https://thorbroadcast.com/product/1-ch-sdi-or-hdmi-hd-encoder-mpeg2-h264.html/120

https://thorbroadcast.com/product/all-inputs-iptv-streaming-and-asi-hd-encoder-608-708-captioning-8230.html

We have one ATSC tuner IRD – H-IRD-V3-ATSC or a two-ATSC tuner IRD  H-IRD-V3-ATSC-2 available. 

The H-IRD-V3-2 is a 2-channel ATSC tuner capable of generating multiple IP/ASI TS streams, which are modulated on two ATSC carriers.

For example, if a channel contains subchannels like 2.1, 2.2, 2.3, and 3.1, 3.2, 3.3, we can output all six of them as UDP multicast or unicast IP streams simultaneously, as well as through muxed MPTS ASI output.

However, the unit can decode SDI/HDMI video/audio for only one program at a time (e.g., 2.1 or 2.2), but not both simultaneously, as it has only one SDI/HDMI video output.

Please let me know how the customer is using their existing tuners. Do they output video as IP, ASI, SDI, or all of them at once? I can then recommend the best solution.

1. Is ASI obsolete, or is IP now the standard?

Customer:
I’ve been talking to different people, and some are telling me that ASI is basically obsolete now, and that programming should instead be delivered over the internet using IP streaming, possibly with protocols like SRT. Is that true?

Thor Fiber:
Not exactly. DVB-ASI is not discontinued or unusable. It is still a perfectly valid transport method. It’s just that many newer devices no longer include ASI interfaces by default, so more people are using IP-based workflows. But if you prefer ASI, there is nothing wrong with using it.

2. Current setup: 4 channels into one ASI stream

Customer:
Right now, I have one transmitter with an ASI input, and I use your H-4ADHD unit to combine four HDMI channels into one ASI output, which then goes into the transmitter. That gives me four subchannels on one transmitter.

What I want to know is: what hardware would let me do the same thing over IP instead of ASI?

Thor Fiber:
The same encoder can already do that. The H-4ADHD-QAM-IPLL has not only ASI output, but also IP output through the data port. So it can generate the same multi-program stream over IP.

https://thorbroadcast.com/product/4-hdmi-component-hd-to-coax-and-iptv-hd-8230.html/21

3. How do multiple subchannels work over IP?

Customer:
That’s where I get confused. I understand how four subchannels are carried on ASI, but I don’t understand how that works using IP.

Thor Fiber:
It works by creating an MPTS, which stands for Multi-Program Transport Stream.
That means the unit combines multiple encoded programs into one transport stream, just like ASI does, but instead of sending it through an ASI interface, it sends it as an IP stream, typically as UDP.

So in simple terms:

• ASI = one physical way to carry a transport stream

• IP = another physical way to carry that same transport stream

The content structure can be the same in both cases.

4. Can H.265 be used for ATSC broadcast?

Customer:
Some people mentioned H.265. Could I use H.265 for this?

Thor Fiber:
Not if you are broadcasting for standard ATSC 1.0 tuners.
For normal U.S. ATSC broadcasting, you need MPEG-2 video.

• H.265 / HEVC is generally for ATSC 3.0

• Standard ATSC receivers will not properly decode H.265 in ATSC 1.0 transmission

So if your transmitters are for current ATSC 1.0 broadcasting, you need to stay with MPEG-2 transport streams.

5. Remote transmitter locations and public internet

Thor Fiber:
Are these transmitters all in the same facility, or are they at remote sites?

Customer:
They are at remote sites. I do have fiber service to those locations, but it’s not my own private network — it’s essentially Ethernet over fiber using a provider, with public internet and static IP addresses.

Thor Fiber:
That’s an important distinction. Since it is not a private LAN, you would be using point-to-point IP transport, not multicast across your own local network.

6. What equipment is needed on the receiving side?

Customer:
If I send the multi-program stream over IP, what do I need at the far end by the transmitter?

Thor Fiber:
On the receiving side, you would use an IRD.
For example, the H-IRD-V3-ATSC can receive the IP stream and output ASI. That way:

https://thorbroadcast.com/product/ird-satellite-or-atsc-decoder-to-sdi-ip-asi-8230.html/76

1. The H-4ADHD creates the MPTS

2. It sends that stream over IP

3. The IRD receives it at the remote site

4. The IRD outputs ASI

5. The ASI feeds directly into the transmitter

So this effectively gives you an IP-to-ASI gateway.

7. Should the transmitters use ASI input or direct IP input?

Customer:
So if I’m buying nine new transmitters, what is the better choice?
Should I buy transmitters with ASI input, or transmitters that can accept multi-program transport stream input over IP directly?

Thor Fiber:
Either can work.

Option 1 — Simpler / safer:

Use transmitters with ASI input, and put an IRD at each site.

Option 2 — More direct:

If the transmitter itself can directly accept MPTS over IP, then you may not need the IRD.

So the key question when choosing transmitters is:

Can the transmitter directly accept a multi-program UDP transport stream?

If yes, you may go IP directly.
If not, use the IRD to convert IP back to ASI.

8. How many H-4ADHD units would be needed?

Customer:
If I need four subchannels for each of the nine transmitters, does that mean I would need nine H-4ADHD units at the headend, one per remote transmitter?

Thor Fiber:
Yes, if each transmitter needs its own independent four-program stream, then you would typically need one H-4ADHD per unique transport stream.

So if all nine sites carry different content, that would mean:

• 9 encoding/multiplexing units at the headend

• 9 receiving devices (IRDs) at the far ends, unless the transmitters accept MPTS directly

9. Is this point-to-point or point-to-multipoint?

Customer:
Would this be point-to-point or point-to-multipoint?

Thor Fiber:
In your case, because this is over the public internet, it would be point-to-point.

If all of your locations were on your own private local network, then we could use multicast, which would allow one stream to be sent to multiple receivers. But across public internet connections, the practical setup is one stream from one encoder to one receiver.

10. Static IPs and port setup

Customer:
We will have static IPs at all locations. Does that help?

Thor Fiber:
Yes, that helps. But usually static IPs are assigned to the router, so there may still be some network setup involved.
In most cases, you would need to configure the sender and receiver properly and possibly open or forward the needed ports on both ends.

But yes, it can absolutely be set up.

11. Is ASI still the simplest approach?

Customer:
It sounds like even though people say everyone uses IP now, it might still be simpler for me to just keep using ASI at the transmitter side.

Thor Fiber:
Yes, that may very well be the easiest and most cost-effective solution.

If your encoder already creates the stream, and the receiver can convert IP back to ASI, then your remote transmitter setup remains straightforward:

• Headend generates stream

• Stream travels over IP

• IRD outputs ASI

• Transmitter receives ASI

That allows you to keep a known and reliable workflow.

12. How many channels can be carried?

Customer:
Is the IRD limited to four channels?

Thor Fiber:
No, not directly. The limitation is really bandwidth, not the IRD itself.

One ATSC channel carries about 19.39 Mbps total.
You can divide that bandwidth among multiple subchannels, but the more channels you add, the lower the bitrate for each one, and the lower the video quality becomes.

So while more than four channels is technically possible, four is usually a practical limit if you still want acceptable video quality.

13. Can multiple encoders be cascaded?

Customer:
Can the system be expanded beyond four channels if needed?

Thor Fiber:
Yes. Multiple units can be cascaded using ASI in and ASI out, so you can build larger transport streams if necessary. But again, the real constraint is total ATSC bandwidth and maintaining good picture quality.

14. Alternative idea: receive off-air and remultiplex locally

Thor Fiber:
There is another possible approach in some locations.
If one transmitter site can receive another station off-air, then you could potentially:

1. Receive that RF signal

2. Demodulate it back to transport stream / ASI

3. Feed it into another transmitter

4. Modify or replace parts of the stream as needed

This can function somewhat like a translator arrangement.

Customer:
That’s interesting. So in some cases I could receive a station over the air, pull the ASI out of it, and then inject it into another transmitter while still modifying local IDs or local content as needed.

Thor Fiber:
Exactly. That is another architecture to consider depending on the site layout and signal coverage.

15. Customer’s actual project structure

Customer:
Part of the project is a co-channel network.
I’m planning to have four co-channel transmitters covering different areas, but because of licensing and local origination requirements, they still need to maintain different station IDs and separate control of their program streams.

In addition to that, I have several other transmitters that will operate as independent channels.

Thor Fiber:
That makes sense. In that case, separate stream generation for each site may still be necessary, especially where different IDs or local programming requirements must be maintained.

16. Final recommendation

Customer:
So the main takeaway is that I can either:

1. Use the H-4ADHD to generate a four-program MPTS over IP, then use an IRD at the transmitter site to convert it back to ASI, or

2. Buy transmitters that directly accept multi-program transport stream over IP

Is that correct?

Thor Fiber:
Yes, exactly.

And if you want the simplest and most familiar workflow, using ASI at the transmitter side with an IRD at the remote end is likely the most straightforward path.

17. Next step

Thor Fiber:
If you send an email to [email protected], I can send you links to the relevant products and an application drawing so you can visualize the setup.

Customer:
That would be great. I still need to talk with the transmitter manufacturers as well so I can compare options and pricing between ASI input and IP input.

Thor Fiber:
Of course. My name is Stan. If you have more questions, feel free to call back and I’ll be happy to explain further.

Customer:
Thanks very much. I appreciate it.

Main Technical Takeaways from the Call

Customer is trying to determine:

• How to distribute programming from one master control / headend

• To nine remote ATSC transmitters

• Each carrying about four subchannels

• While deciding whether to use:

  • ASI

  • IP transport

  • Or a mix of both

Main solution discussed:

• Use H-4ADHD units at the headend to create 4-program MPTS streams

• Send those streams over IP / UDP

• Use IRD receivers at remote locations to convert IP back to ASI

• Feed ASI into the remote transmitters

Important technical points clarified:

• ASI is not obsolete

• IP transport can carry the same MPTS content as ASI

• ATSC 1.0 requires MPEG-2, not H.265

• Public internet = point-to-point

• Private LAN = multicast possible

• More subchannels = lower bitrate per channel

• Four channels is a practical number for good quality