Multicast to Unicast on a NAS: Choosing Between udpxy, msd_lite, and rtp2httpd

Multicast to Unicast on a NAS: Choosing Between udpxy, msd_lite, and rtp2httpd

NAS教程
17NAS17NAS
2026/9/18
178 reads

Goal: let any device on your LAN (computer, phone, TV) watch IPTV live directly, with no set-top box
Result: deploy once and every device in the house can watch; you control channel-switch speed and how many concurrent streams you run
Difficulty: Moderate — you must first put your ONT into bridge mode, then run one Docker container on your NAS
Time required: about 30 minutes

1. Why you need multicast-to-unicast

What multicast is

Carrier IPTV uses multicast: one data stream is sent once from the source, and
every device on the network that has "subscribed" to that channel receives it at the same time.

The benefit is bandwidth savings — if 100 people watch the same channel, the carrier sends the data only once.

The problem: ordinary devices can't play multicast

Multicast relies on the IGMP protocol, and that protocol only works inside a LAN.
The trouble is:

  • Phones, tablets, and smart TVs** mostly do not support IGMP**
  • Even if they do, they do not support the carrier's VLAN-tagged multicast
  • Across subnets (Wi-Fi devices, for instance) it simply cannot play

The result: your set-top box can watch, but your phone, computer, and Apple TV cannot.

What multicast-to-unicast solves

Run a forwarding service inside the LAN, and it:

  1. Subscribes to the multicast stream over IGMP
  2. Converts the multicast stream into an ordinary HTTP unicast stream
  3. Any device that can open an HTTP address in a player can watch
ISP multicast stream  ->  [forwarding service on the NAS]  ->  HTTP unicast  ->  any device
rtp://239.x.x.x:4120              http://NAS_IP:5893/rtp/239.x.x.x:4120

For the prerequisite ONT bridge-mode steps, see the ONT bridge mode guide.

2. Prerequisites (both must be done first)

1. Put the ONT into bridge mode

This step is mandatory. If the ONT is still in router mode, the IPTV VLAN traffic never reaches your NAS.

For the full steps see the ONT bridge mode guide; here are just the key points:

  • Obtain the ONT superadmin password
  • Back up the original configuration
  • Change the internet VLAN to bridge mode and let your own router handle dial-up
  • Critical: leave the IPTV VLAN untouched — do not bridge it along with the rest

2. Enable IGMP proxy on your router / software router

In your router's IPTV settings, turn on IGMP Proxy (sometimes called IGMP Snooping or multicast proxy).

Where to find it by system:

System Location OpenWrt Network → Interfaces → IPTV interface → tick IGMP Proxy iKuai Advanced Applications → Multicast Settings ASUS Internal Network → IPTV → Enable IGMP Proxy Synology Router usually no extra configuration needed

3. Obtain the carrier's multicast addresses

Multicast addresses vary by region and carrier; there is no universal value. How to get them:

  1. Packet capture: while the set-top box plays normally, capture packets on the router and look for IGMP Join messages
  2. Search online: search for "[your city] [carrier] iptv multicast address"
  3. Ask the installer: sometimes they can tell you directly

You need two things:

  • VLAN ID (for example 85 or 3961; it differs by carrier)
  • Multicast IP and port (for example 239.125.2.66:4120)

While you are at it, check your current network environment:NAT type testing tool

3. Choosing among the three options (the core section)

The conclusion first:All three tools do the same job; the difference is maintenance status and performance.

Option 1: udpxy — the oldest, with the most documentation

This has been the go-to in the Chinese IPTV community for over a decade.

Item Notes Pros Mature Docker image (ifmm/udpxy with 19,691 pulls), the most tutorials, and a complete record of pitfalls Cons upstream has not been maintained for 4 years Best for first attempts, single-device viewing

A fact you must know: udpxy's own README says so:

udpxy has not been extended or supported for 4+ years,
having been replaced by Gigapxy - a superior enterprise-oriented product.

that does not mean it is unusable — it ran stably for over a decade, it is simply no longer updated.
But if you want better performance or newer features, look at the next two.

Option 2: msd_lite — the modern replacement for udpxy

The name comes from Multi Stream daemon, and the community widely accepts it as the udpxy replacement.

Item Notes Pros lighter, lower resource usage, better performance Cons less Chinese-language material than udpxy Best for OpenWrt routers and long-term stable operation

If you search "udpxy alternative" on forums like Enshan, this is the first thing recommended.

Option 3: rtp2httpd — the most feature-complete

This project positions itself as "the modernized version of udpxy", and the author announced it on V2EX.

Item Notes Pros supports the FCC fast channel-change protocol and multiple protocols including RTP/RTSP Cons configuration is slightly more involved than udpxy Best for multiple concurrent devices and anyone who cares about channel-switch speed

Comparison summary

Dimension udpxy msd_lite rtp2httpd Maintenance stopped (4+ years) active active Learning curve lowest medium medium-high Resource usage medium low medium Channel-switch speed average good best (FCC) Chinese documentation most medium little Recommended for first attempts long-term operation best experience

My recommendation:

  • First time trying this: use udpxy — plenty of material, easy to search when something breaks
  • Running stably and want to optimize: switch to msd_lite
  • Multiple devices and you care about channel-switch speed: go with rtp2httpd

The demo below uses udpxy because it is the easiest to get started with, and migrating to the other two follows exactly the same logic.

4. Hands-on: deploying udpxy with Docker on a NAS

Why use a NAS instead of a router

A router can run it too, but a NAS has several advantages:

  • Usually a stronger CPU, so multiple concurrent streams are more stable
  • Runs 24 hours a day, so you don't load down your router
  • Easy Docker management, with simple upgrades and rollbacks
  • It can run other things too (a media library, for instance)

docker-compose.yml

Create a new udpxy folder under your NAS's Docker directory and put this file in it:

version: "2"
services:
  udpxy:
    image: ifmm/udpxy
    container_name: udpxy
    network_mode: host
    restart: always

Then start it:

docker-compose up -d

Need to generate a more complex compose configuration? Use the docker-compose generator.

Three things you must get right

1. network_mode: host is mandatory

This is the easiest trap to fall into. udpxy needs to listen to multicast traffic directly, and
if you use Docker's default bridge network, it will not receive multicast packets at all.

So network_mode: host cannot be omitted.

2. Port 5893

udpxy always uses port 5893 and provides two functions at once:

Path Purpose http://NAS_IP:5893/status/ view running status and current subscriber count http://NAS_IP:5893/restart/ restart the service http://NAS_IP:5893/rtp/multicast-IP:port the playback address after unicast conversion

3. NAS network configuration

You must ensure the NAS and the IPTV VLAN are on the same Layer 2 network.
Two common approaches:

  • Dual-NIC NAS: one port on the regular network, one on the IPTV VLAN
  • Switch trunk: pass the IPTV VLAN through the switch to the NAS

If you use a bypass router setup, see the OpenWrt bypass router deployment guide.

Verifying success

Step one: open the status page in a browser

http://NAS_IP:5893/status/

If you can see statistics, the service is running.

Step two: test one channel

# assume the multicast address is 239.125.2.66:4120
curl -I 'http://NAS_IP:5893/rtp/239.125.2.66:4120'

A return of HTTP/1.0 200 OK means forwarding works.

5. Using it in a player

Address format

Just remember this conversion rule:

Original multicast address Converted playback address rtp://239.125.2.66:4120 http://NAS_IP:5893/rtp/239.125.2.66:4120

On a computer

Player How to use VLC Media → Open Network Stream → paste the address PotPlayer Ctrl+U → paste the address MPV mpv http://NAS_IP:5893/rtp/...

TV / set-top box

  • Kodi: install the PVR IPTV Simple Client add-on and import an m3u playlist
  • Smart TV: use the built-in player or install VLC for Android TV
  • Apple TV: use VLC or Infuse

Recommended practice: collect every channel address into a single .m3u file,
so the player only needs one import to see all channels instead of typing addresses each time.

#EXTM3U
#EXTINF:-1, CCTV-1 General
http://NAS_IP:5893/rtp/239.125.2.66:4120
#EXTINF:-1, CCTV-2 Finance
http://NAS_IP:5893/rtp/239.125.2.67:4120

6. Which NAS units can handle it

Good news: multicast-to-unicast is an I/O-bound task, so it does not demand much CPU.

Bad news: with multiple concurrent 4K streams, both CPU and network matter.

Rough guidance (not measured; verify against your own setup)

Scenario Rough hardware requirement One 1080p stream almost any NAS works (including low-end ARM models) 2-3 streams of 1080p an x86 NAS at the Intel N100 level handles it easily One 4K stream N100 or above Multiple concurrent 4K streams J4125 or above recommended, plus a 2.5G network port

A few easily overlooked points:

  1. The network port matters more than the CPU — a gigabit port gets tight at three 4K streams
  2. Other services on the NAS compete for resources — if Plex transcoding runs at the same time, leave headroom
  3. ARM NAS units can run it too — the ifmm/udpxy image supports arm64 and armv7

Want benchmark numbers for a specific model? See the CoreMark data in the NAS CPU performance ranking.

7. FAQ

Q1: It won't play and just keeps spinning?

Troubleshoot in this order:

  1. Test the status page first (/status/) — if it won't open, the container isn't running
  2. Confirm network_mode: host — this is the most common cause
  3. Confirm the multicast address is correct — verify by packet capture, don't rely on memory
  4. Confirm IGMP proxy is enabled on the router
  5. Confirm the NAS is on the IPTV VLAN

Q2: It plays but stutters badly — how do I troubleshoot?

First determine whether it is "the source" or "the network":

  • Try another channel — if only one channel stutters, it is a source problem
  • Try a wired connection — if Wi-Fi stutters but wired does not, it is a wireless bandwidth problem
  • Check the traffic statistics on the status page — confirm forwarding itself is not dropping packets

Q3: Channel switching takes 3-5 seconds. Is that normal?

Yes, it is normal. The channel-switch delay in multicast-to-unicast mainly comes from:

  • The player reissuing the HTTP request
  • The service re-joining via IGMP
  • Waiting for a keyframe (I-frame)

To go faster: use rtp2httpd, which supports the FCC fast channel-change protocol.

Q4: Why can I only watch some channels?

Common causes:

  • Incomplete channel list — the multicast addresses you captured were only what the set-top box was subscribed to at that moment
  • Some channels are encrypted — they need set-top box authorization and cannot be forwarded
  • Wrong VLAN — some carriers put live TV and catch-up VOD on different VLANs

Q5: Can I watch on my phone over Wi-Fi?

Yes, as long as the phone and the NAS are on the same LAN.
But if the NAS is on the IPTV VLAN and the phone is on the regular network, your router needs to do cross-VLAN routing.

Q6: Does it use a lot of bandwidth?

A key concept: within the LAN, multicast occupies only one stream's worth of bandwidth no matter how many people watch.
But once converted to unicast, each viewer takes one stream's worth.

Scenario LAN bandwidth used One 1080p stream about 8-15 Mbps One 4K stream about 25-40 Mbps Three 1080p streams at once about 24-45 Mbps

A gigabit LAN is more than enough, but on Wi-Fi you need to watch signal quality.

Q7: Will the carrier notice I'm forwarding inside my LAN?

Technically: the forwarding happens inside your own LAN, so what the carrier sees is the same IGMP subscription as your set-top box.
In practice: some carriers limit the number of simultaneous subscriptions (allowing only 2 streams, for example), and reject anything beyond that.

Recommendation: don't run excessive concurrent streams — it hurts the experience and may trigger those limits.

Q8 addendum: Does multi-dial affect IPTV?

Yes. If you also use single-line multi-dial, the multiple WAN outlets it creates can interfere with the IPTV VLAN,
causing the set-top box to fail IGMP multicast.

Recommendation: exclude the IPTV interface from mwan3 load balancing; for specifics see
the OpenWrt single-line multi-dial guide: aggregating bandwidth with mwan3.

Q8: Do Synology / QNAP / Zspace all work?

All of them do, as long as they can run Docker.

Brand Notes Synology import the compose file directly in Container Manager QNAP Container Station supports compose Zspace supports Docker, but the UI is more restrictive UGREEN / fnOS both supported

The only difference is how networking is configured — single-NIC and dual-NIC setups differ.

8. Summary

The three options in one line each

Option One line udpxy veteran and stable, the most documentation — pick it for your first attempt msd_lite lighter and faster — switch to it once things are stable rtp2httpd fastest channel switching — pick it for multiple devices and the best experience

The three most common pitfalls

  1. Forgetting network_mode: host — no multicast received, which shows up as "spinning forever"
  2. The ONT is still in router mode — the VLAN never reaches the NAS, so bridge it first
  3. IGMP proxy not enabled on the router — multicast packets never enter your LAN

The core value

The essence of this setup is freeing the carrier's IPTV from "a single set-top box" and
turning it into "one HTTP stream on your LAN" — after which any device can watch,
and you can choose your player and organize your channel list however you like.

The deployment cost is essentially zero (your NAS is already running), and the improvement in experience is very noticeable.

Back to article list