Turning a Slow Spare Laptop into a Free AirPlay Receiver

NetworkCastHub

An old Windows laptop with a weak processor, turned into a wireless screen for an iPhone, an iPad and another laptop. No cables, no subscription, no trial timers.

3 senders, 1 receiverUDP 5353 discoveryTCP 7000 handshakeGPU does the decodingabout 10 min to set up

The itch

I had a Windows laptop sitting in a drawer. Its processor is too weak for real work, but the screen is fine and it still runs Windows. I also had an iPhone, an iPad and a second laptop that I kept wanting to show on a bigger display.

So the plan was simple: plug the spare laptop into a monitor, and make it a wireless receiver. Anything I want on the big screen gets cast to it, with no cables, no subscriptions and no trial timers.

That last part mattered. I tried a few Store apps first. One worked but started a 15 minute trial countdown the moment the stream began. Out it went.

What I ended up with

I wrapped everything in a small repo called NetworkCastHub. It does three things:

AirPlay screen mirroringFrom iPhone or iPad to the spare laptop, with audio.

YouTube castingThrough a TV-style receiver page, because plain mirroring blanks out protected video.

One-click hotspot toggleSo the other laptop can join through the spare machine when there is no shared network.

The actual AirPlay receiver is an open source Windows engine (native C++, SDL2, hardware video decode). My repo is the glue: installer, shortcuts and a small menu.

One spare laptop becomes the screen for every device

Same Wi-Fi, or the hotspot toggle when there is no shared network.

iPhone

iPad

Other laptop

The receiver

Spare Windows laptopReceives the stream
Decodes on the GPU
Shows it in a window

ScreenIts own, or an attached monitor

How casting actually works

When you tap Screen Mirroring on an iPhone, four things happen in order.

Four steps from tap to picture

The phone does the encoding. The laptop only decrypts, decodes and draws.

DiscoveryUDP 5353Phone asks who offers AirPlay

HandshakeTCP 7000Pair, swap keys, agree on format

The streamH.264 / HEVCEncrypted, sent over the network

Decode, showCPU + GPUDecrypt on the CPU, decode on the GPU, draw the window

Ports 5353 and 7000 are only the start: audio and timing use extra dynamic UDP ports.

1. Discovery. The phone does not know your laptop exists. It sends a multicast DNS query on the local network asking who offers AirPlay. The receiver listens on UDP port 5353 and answers with two service names, one for video and screen mirroring and one for audio. That is why the laptop shows up in the list with no setup.

2. Handshake. After you tap the receiver, the phone opens a control connection to the laptop on TCP port 7000. The two sides pair, exchange keys and agree on resolution, frame rate and which ports to use for the media streams. Mirroring also goes through Apple's own key exchange, which open receivers have reimplemented.

3. The stream. The phone compresses its screen with its hardware encoder into H.264 or HEVC and sends it over the network, encrypted. It uses additional dynamic UDP ports for audio and timing, which matters later for the firewall.

4. Decode and display. The laptop decrypts the packets, hands the video to the GPU's hardware decoder, and draws the frames in a window. Pressing F toggles fullscreen.

The key point for a weak machine: the laptop never has to encode or think about your content. It only decrypts and decodes, and decoding is exactly what GPU video blocks are built for.

Why a weak CPU is fine

A slow processor hurts when it has to do general work: compiling, browsing with twenty tabs, running an IDE. A receiver does a narrow job. Network packets arrive, get decrypted (cheap), get decoded on the GPU's video engine, and get shown. The heavy lifting is on the phone, which encodes the stream, and on the laptop's video decoder, which is separate silicon from the CPU cores.

That is why an old machine can mirror a phone smoothly even when it struggles with everyday apps.

Where the RAM goes

The receiver is a native program, not a browser engine wrapped in an app. Its memory goes to a handful of places:

The program and its librariesThe engine, SDL2 and the graphics runtime.

Network buffersIncoming packets held briefly so the video stays smooth.

Decoder surfacesA small pool of frames the decoder works with. Many live in video memory, not system RAM, a big reason system RAM stays low.

The window and swap chainWhatever is needed to draw one window at your resolution.

DiscoveryThe mDNS listener is tiny.

YouTube TV modeA different story: it runs a full browser window, so expect it to cost noticeably more than the AirPlay receiver.

Don't take my word for the numbers. Measure on your own machine while mirroring:

Get-Process airplay-windows | Select-Object Name,
  @{n='WorkingSet_MB'; e={[math]::Round($_.WorkingSet64/1MB)}},
  @{n='Private_MB';    e={[math]::Round($_.PrivateMemorySize64/1MB)}}

For GPU use, open Task Manager, go to the Details tab, and add the GPU and Dedicated GPU memory columns. Watch the Video Decode engine in the Performance tab.

Attaching the other laptop

The second laptop only needs to reach the receiver. If both are on the same Wi-Fi, nothing special is needed. When they aren't, the hub's hotspot toggle turns on Windows Mobile Hotspot through the Windows Runtime tethering API, and the second laptop joins it. Whether the Wi-Fi card can stay on your home network and run a hotspot at the same time depends on the driver, so check yours.

I tested iPhone mirroring. The iPad uses the same AirPlay protocol, so the same path applies.

The gotchas I hit

ProblemEmpty Screen Mirroring list

FixMy Wi-Fi was set to a Public network, and Windows blocks unsolicited inbound traffic there. Setting it to Private fixed discovery.

ProblemFirewall rules

FixAirPlay uses more than ports 5353 and 7000, because audio and timing use dynamic UDP ports. Allowing the program through the firewall is more reliable than opening ports one by one.

ProblemNo window appeared

FixThe stream connected but nothing showed. Launching the receiver from the interactive desktop (for example through Explorer) fixed it.

ProblemBlack screen on YouTube

FixProtected video is not rendered into a mirror. I pair the phone with a TV-style receiver page using YouTube's Link with TV code instead. The phone becomes a remote and the video plays directly on the laptop.

Setting it up

Clone the repo and run setup.bat. It downloads the receiver engine and creates desktop shortcuts.
Set your Wi-Fi to a Private network, then launch the AirPlay shortcut.
On the phone, open Control Center, tap Screen Mirroring, and pick the receiver.

Limits worth knowing

It is mirroring, not full AirPlay video hand-off, so protected video apps may show black.
The receiver engine is a third-party project. Read its license and pin the version you trust.
The YouTube TV trick depends on YouTube keeping that page working.
Hotspot sharing depends on your Wi-Fi driver.

Wrap-up

A spare laptop with a weak processor is a perfectly good wireless screen. The receiver does little work, the GPU decoder does the rest, and the memory footprint stays small. If you have a drawer laptop and a monitor, it takes about ten minutes.

NetworkCastHub: installer, shortcuts and the cast menuView the code on GitHub