Connecting a laptop to your TV over HDMI for live TV

An HDMI cable from a laptop to a television is the cheapest way to get this app onto a big screen, and it works. The cable is not the interesting part. What decides whether it looks right is what Windows tells the app about the display it has landed on.

Extend, not duplicate#

Duplicate mode forces both panels to a shared resolution and refresh rate, which usually means your television gets driven at whatever your laptop panel can do. That is how a 4K television ends up showing a soft 1080p image with judder, and why a 3840 by 2160 panel can report itself as 1920 by 1080 while connected.

Extend instead. Drag the player window onto the television and press F. The laptop panel stays yours for everything else, and the television gets its own native mode.

3 keys reach fullscreen: F, Alt+Enter and F11. Escape leaves it, with one layer in front: if the stream information panel is open, the first Escape closes that and the second leaves fullscreen.

Why the picture changes when you move the window#

Because the app asks the display it is actually on, not the display it started on.

HDR is decided per window against that window's monitor. Drag the player from a laptop panel to an HDR television and the app re-reads the colour space and can ask for a 10-bit surface; drag it back and it does not. This is deliberate. On a mixed desk, one panel should never inherit the other's state.

2 conditions have to hold before HDR is requested at all: the display has to report an HDR colour space, and the loaded player library has to be 3.0.21 or newer, probed at runtime rather than assumed. If either fails you get SDR, because SDR is the answer that cannot make anything worse.

Underneath that is a fallback ladder, tried in order:

1  R10G10B10A2 + Ignore        preferred, 10-bit
2  R10G10B10A2 + Unspecified   10-bit, different alpha handling
3  B8G8R8A8 + Unspecified      8-bit, identical to the previous behaviour

The third rung matters more than it looks. It is byte-for-byte the old configuration, so a machine that cannot compose 10-bit behaves exactly as it did before rather than failing. And if the surface cannot be created at all, that logs and leaves the surface unloaded rather than throwing out of a layout callback, which would take the whole app down.

We got this wrong once on the way here. The first version asked for 10 bits everywhere, on the reasoning that it costs the same 4 bytes per pixel either way, so why not. It was reverted once the running app showed why: the translucent transport controls composited visibly lighter over the 10-bit surface and ghosted through the video. Same bytes per pixel, different picture. That is why the depth is chosen per monitor, and why the option builder is told which precision the surface actually came up at rather than which one was asked for.

Refresh rate, and the judder nobody attributes correctly#

A 50 Hz broadcast on a 60 Hz display has to have frames repeated unevenly: 5 source frames stretched over 6 display refreshes, forever. The result is a small regular stutter on panning shots that is easy to blame on the stream. It is not the stream.

If your television supports it, set the display to match your content's rate, or turn on automatic refresh rate switching in Windows display settings. This is outside the app and the app cannot fix it, which is exactly why it is worth knowing: no amount of buffer tuning will change it. Fixing buffering and stuttering separates this from the failures that are ours to fix.

Audio#

HDMI carries audio, and Windows will usually switch the default output to the television when you plug in. Usually.

If you have a receiver in the chain and want it to decode the bitstream itself, turn on audio passthrough. Know one thing first: it opens the output device in exclusive mode, which is why it is limited to the primary player, and which also means other applications lose that device while it is active. On a laptop you also use for calls, expect that surprise.

What was actually tested#

Fullscreen and picture-in-picture were both exercised against real 4K sources in the same verification pass, resizing and migrating across windows while continuing to play, with 0 errors logged across the whole run. Moving a playing window between displays is a supported path, not a hopeful one.

If this becomes a habit rather than an occasional thing, a small dedicated machine beats reconnecting a laptop every evening: building a small home theatre PC covers what to buy, and starting the app with Windows makes it behave like an appliance.