Guide

rtp2httpd FCC: Faster Channel Changes on Apple TV

Updated October 28, 2026

If you relay multicast IPTV with rtp2httpd, you can turn on FCC (Fast Channel Change). To do this, add ?fcc=<FCC server IP>:<port> to the channel addresses in your M3U. You don’t need to change anything in Revue. In our tests, between channels with the same display mode, the picture of the new channel started to move after about 1.7 seconds instead of about 2.3 seconds. The cost is that live playback runs 1–2 seconds further behind than without FCC.

This guide assumes that rtp2httpd already relays your IPTV multicast and that the channels play in Revue. To add a playlist to Revue, see IPTV on Apple TV: Add Your M3U Playlist and EPG.

What FCC does

With plain multicast, a channel change is slow because the player waits for a keyframe. Only keyframes carry a full picture. The frames after a keyframe need it to decode. When the relay joins the multicast of the new channel, the first data it gets is usually not a keyframe, so the player must wait for the next one. Keyframes usually come every 1 to several seconds.

With FCC, when you change channels, rtp2httpd first asks an FCC server on the IPTV network for the channel. The FCC server sends the channel by unicast, starting from a keyframe in its cache. It sends a little faster than normal playback speed (we measured about 1.2× for about 10 seconds). When the unicast catches up with the multicast, rtp2httpd switches back to multicast and closes the unicast. The player gets one continuous stream the whole time and doesn’t notice the switch.

What you need

• rtp2httpd. udpxy doesn’t have FCC.
• The address and port of the FCC server on your IPTV network. Like multicast addresses, they depend on your local IPTV network, and this guide doesn’t list any. The rtp2httpd guide Fast Channel Change Configuration explains how to find them.
• rtp2httpd must be able to reach the FCC server. According to the rtp2httpd documentation, the relay device usually needs an address on the IPTV network (from DHCP, IPoE, or PPPoE), and upstream-interface must point to the network interface on the IPTV side.
• If rtp2httpd runs behind NAT, for example on a NAS or a secondary router, the default FCC type also needs fcc-listen-port-range and port forwarding on the upstream router. See the same rtp2httpd guide. If the relay device connects directly to the IPTV network, you don’t need this.

Step 1: Add the FCC parameter to the M3U

Add ?fcc=<FCC server IP>:<port> to the end of each rtp2httpd channel address:

#EXTM3U
#EXTINF:-1 tvg-id="<channel id in the guide>" group-title="HD",<channel name>
http://<relay device IP>:5140/rtp/<multicast address>:<port>?fcc=<FCC server IP>:<port>

• fcc-type selects the FCC protocol. You can leave it out. Then it is telecom. According to the rtp2httpd documentation, this works in most cases. Some networks need &fcc-type=huawei at the end of the address.
• An address can have only one ?. If the address already has other parameters, join them with &.
• If rtp2httpd rewrites your playlist with external-m3u, add the parameter to the addresses in the source playlist: rtp://<multicast address>:<port>/?fcc=<FCC server IP>:<port>.
• To turn on FCC for only some channels, change only the addresses of those channels.

After you change the playlist, press Play/Pause on the channel list in Revue to reload it.

Step 2: Check that FCC works

You can’t reliably tell by feel. Use one of these two methods.

Check the response header (rtp2httpd 3.16.0 or later). In a terminal on a computer, run:

curl -s -o /dev/null -D - --max-time 3 "http://<relay device IP>:5140/rtp/<multicast address>:<port>?fcc=<FCC server IP>:<port>"

This command prints only the response headers and stops after 3 seconds. Find the R2H-FCC-Status line:

• active: this playback started from the FCC unicast. FCC works.
• fallback: the FCC server didn’t respond, so rtp2httpd used plain multicast. See Common questions.
• No such line: the address has no fcc=, or rtp2httpd is older than 3.16.0.

Don’t use curl -I. For a HEAD request, rtp2httpd doesn’t contact the FCC server, and the response has no R2H-FCC-Status line.

Check the status page. In a browser, open http://<relay device IP>:5140/status. Change the channel on the Apple TV, then look at the row of that Apple TV at once. Find it by the IP address of the Apple TV in the Client column.

• If the address in the Service column ends with ?fcc=…, Revue uses the changed address.
• If the State column shows FCC Unicast Active in the first 10 seconds or so after the change, FCC works. After that, it shows Multicast Active. This is normal after the switch back to multicast.

If you see only Multicast Active after each channel change, check again with the curl command above.

How much faster

We tested 6 channels, including 4K HDR channels, with one Apple TV and rtp2httpd 3.17.2. We changed channels only between channels with the same display mode: 24 times with plain multicast and 24 times with FCC. The table shows the median time from the button press:

On each channel, the picture started to move 0.4–0.9 seconds earlier with FCC. Keyframe intervals are different on each network and channel, so your results will be different.

Why FCC doesn’t feel faster in some players

The first data from FCC starts with a keyframe. But the information that tells the player which audio and video the stream contains (PAT/PMT) often arrives a few tenths of a second later. Some players drop all data that arrives before this information, and the first keyframe goes with it. Then they must wait for the next keyframe, so FCC makes little difference.

Revue keeps this data and uses it when the information arrives, so it can use the first keyframe from FCC. With plain multicast, Revue also uses a keyframe that arrives before this information.

When FCC can’t help

• If Match Content is on in tvOS, and you change between an SDR channel and a 4K HDR channel, or between channels with different frame rates, the TV must switch its display mode first. This takes several seconds, depending on the TV, and FCC can’t make it shorter. You clearly notice FCC only between channels with the same display mode.
• If the FCC server doesn’t respond, rtp2httpd waits only 80 milliseconds and then uses plain multicast. The channel still plays, but not faster.

The cost: live playback runs 1–2 seconds behind

With FCC, the picture in Revue is 1–2 seconds further behind live than without FCC. This is because FCC data starts from a slightly earlier keyframe. Revue plays from that frame at normal speed, so it stays that far behind. The delay stays until the next channel change. Revue doesn’t play faster to catch up with live.

If live timing matters to you, for example when you watch a match and follow the score on your phone, turn on FCC only for the channels you change to often, or don’t turn it on.

Common questions

For other playback problems, see IPTV Not Working on Apple TV? How to Fix It.