Fix video that stutters on a 4K monitor but not on 1080p

Why the same file behaves differently on each screen

Decoding and drawing are separate jobs, and only one of them changes when you swap the screen. Decoding turns the H.264 file into frames at the file's own resolution: a 1920 × 1080 file produces 1920 × 1080 frames whatever the panel is. Drawing puts every frame, together with the rest of the desktop, onto the panel at the panel's resolution and refresh rate, and at the panel's full rate that draw job quadruples between the two screens.

Windows' default display driver draws a desktop but carries none of the chip's video acceleration, so the extra fill lands on the CPU. Display scaling adds a stretch between the layout and the panel, and every stretch costs memory bandwidth somewhere in the chain.

The quick tell: play the same file at the same moment in the signage player and in the desktop video app that ships with Windows, on the same screen. A smooth desktop app beside a stuttering player clears the file, the decode and the cable in one move, and leaves the draw path.

Symptoms and what each one points to

• Smooth on the 1080p screen, stutter on the 4K screen, same files: the desktop draw is the limit. Start with the driver and the scaling setting.
• The desktop video app plays the same file smoothly while the signage player stutters, on the same screen: decode and cable are fine. The fault is in the driver or the player's window.
• The stutter follows the file: a 4K source stutters on every screen while 1080p files play everywhere. The decode load is the limit; re-encode 4K sources to 1080p.
• Steady judder on camera pans with little CPU load, only on the 4K screen: the link settled on a 30 Hz mode. Read the reported refresh rate first.
• The stutter cleared but text and edges went soft: the layout is stretched on the way to the panel. Size the layout to the screen's pixel grid.

Checks before you change anything

Shut the player down and pull its plug before you swap cables or move the box.

1. Read the mode on the display settings page. It should report the panel's native 3840 × 2160; anything at 30 Hz moves the link to the top of the list.
2. Confirm the cable is rated for HDMI 2.0, the 18 Gbit/s generation. An older cable can still show a picture at a reduced mode, which appears as judder rather than dropped frames.
3. Open the player PC's device manager and read the display adapter entry. A basic display adapter listed there means the chip vendor's driver was never installed.
4. Read the scaling value on the same settings page; 150 percent is the common value a 4K panel ships with.
5. Run the two-app test from the section above and note which side stutters.

The fix, in order

1. Install the graphics driver package for the exact chip from the chip maker's own site and restart. This step clears most cases with these symptoms: the vendor package restores the chip's video acceleration, and the extra pixel fill stops landing on the CPU. Re-run the two-app test afterwards.
2. Set display scaling to 100 percent. Scaling exists so text is readable on a desktop monitor; a sign builds its text at the size the room needs, so the stretch is pure cost. Leave the desktop mode at the panel's native resolution while you do it: setting the mode down to 1080p on a 4K panel softens every edge on the wall.
3. Match the layout to the screen. Build the layout at 3840 × 2160 when viewers read from closer than about 3 times the screen diagonal, the distance past which a 1080p canvas stops resolving; keep it at 1920 × 1080 when they read from farther away. The fit check in checking portrait signage layout fit on a screen takes minutes and catches a mis-sized canvas before the screen is on the wall.
4. Keep files at 1920 × 1080 H.264 in MP4 and deploy them at the bitrate you tested; the checks in video bitrate for a signage player: test before you deploy apply to a Windows player the same way.
5. Re-encode 4K source files to 1920 × 1080 before they enter the playlist. On this class of hardware a 4K H.264 source can outrun the decode block and drop to the CPU, and no screen setting recovers that.

Worked example: four times the pixels, the same chip

Scenario: a lobby sign driven by a small quad-core x86 player with integrated graphics and 8 GB of RAM, one 3840 × 2160 TV at 60 Hz over an HDMI 2.0 link, playlist of 1920 × 1080 H.264 files at 30 frames per second, scaling at 150 percent.

Decode is set by the file. Each frame is 1920 × 1080 = 2,073,600 pixels, decoded 30 times per second, and the panel changes none of it.

Draw on the 1080p monitor: 2,073,600 pixels per frame × 60 = 124,416,000 pixels per second, about 124 million.

Draw on the 4K TV: 3840 × 2160 = 8,294,400 pixels per frame × 60 = 497,664,000 pixels per second, about 498 million. Four times the work on the same chip.

Scaling at 150 percent stretches the full-screen layout to 1920 × 1.5 = 2880 wide and 1080 × 1.5 = 1620 high, so the layout covers 2880 × 1620 = 4,665,600 pixels, 2.25 times the area of a true 1080p desktop, before the final stretch to the panel's 8.29 million.

With the chip vendor's driver installed, the integrated graphics composites 498 million pixels per second and the 1080p playlist holds every frame slot. With the default driver the stretch lands on the CPU, frames miss their slot, and the same playlist that ran smoothly on the small screen stutters on the large one.

If the settings are right and the stutter stays

Then the hardware class is the limit, and it is worth saying plainly: a low-power quad-core x86 player with integrated graphics is a 1080p machine. Its decode block and fill rate are sized for 1080p-class H.264, so that is the file class to feed it.

Three ways out:

• Re-encode to 1080p and keep the hardware. For a sign read at room distance, the 4K source adds nothing on the wall.
• Move the job to a desktop-class x86 PC with the vendor driver installed, when the design needs a native-resolution canvas with video at close range.
• Drop the PC for a looping sign. A display that plays from a card has no display driver to miss: our panel-mount Android displays play images and MP4 from microSD or USB with no subscription and bring the show up on their own at power-on, and wiring 12 to 36 V DC power to a signage display covers the hookup.

Tell one other fault apart from this one: if the player holds its output at 1080p on the 4K panel however the layout is built, that is a rendering cap in the player, not the draw-path overload here, and why a 4K signage player renders at 1080p covers it.

The decision for each case

Recommendation: Install the chip vendor's graphics driver first and restart, then set display scaling to 100 percent. Keep the desktop at the panel's native resolution, feed the player 1920 × 1080 H.264 files in MP4, and build the layout at 3840 × 2160 only when viewers come closer than about 3 times the screen diagonal. Keep an HDMI 2.0-rated link between player and screen. A low-power x86 player is a 1080p machine: re-encode 4K sources instead of feeding them to it, and treat 3840 × 2160 canvases with close-range video as a job for desktop-class graphics.

• Files that stutter only on the 4K screen: driver, then scaling, then layout. The files stay.
• A smooth desktop video app beside a stuttering player: driver, then set the player's window full screen at the layout's size.
• A 4K source that stutters everywhere: re-encode to 1920 × 1080. This class of player has no setting that carries a 4K H.264 file.
• Judder with 30 Hz reported on the 4K screen: replace the link path with an HDMI 2.0 cable and confirm the native 3840 × 2160 mode on the settings page before touching the software.

Questions