Android signage player shows a black screen on video

Why does a video play in another app but black-screen in the signage player?

The player asks the Android system's own media stack to decode the file, while the app that played it carried its own decoder, so the other app's success tells you the file is intact and nothing about what the built-in stack can decode.

Android documents MediaPlayer as the framework's playback engine and MediaCodec as the interface to the board's decoder components. A signage player built on the framework can use only the decoder components the board exposes. A media app that ships its own decoder set skips that list entirely, which is why the same file can behave two different ways on the same board in the same minute.

The black region is the failure shape to expect: the framework has no decoder it can use for that file at that path, the video surface stays empty, and the rest of the layout keeps rendering. Images playing normally tell you the app, the layout and the panel are fine, which narrows the fault to the video decode path.

What does each symptom point to?

Video tiles that stay black while the soundtrack runs point at the decoder; a file that plays in the board's default player but not from the player's own folder points at the storage location; images that play while every video fails point at the Android version.

• Plays in a media app, black in the signage player. The media app used its own decoder. Read the board's built-in decoder list next.
• Plays in the board's default player, black in the signage player. Decode works, so where the file sits is the suspect. Some old boards play video only from the emulated SD card path.
• Images play, every video is black. The layout and the player are working, and the decode stack or the Android build falls short of the CMS player's stated minimum.
• One video is black, its siblings play. Look at that file: a profile the decoder does not accept, or a copy cut short. An MP4 carries its playback index at the end of the file, so an interrupted copy leaves a file some players refuse to start; the guide to recovering truncated MP4 files shows what that looks like on disk.
• The file sits on USB and never reaches the show. That is the loading path, not the decoder. The fix for a video that plays over USB but not in the player app has its own page.

How do you check what the board can decode?

Install a codec-listing app from the app store, open the decoder list, and look for an H.264/AVC entry: an entry there means the board can decode an H.264 MP4 and the black screen has another cause, while a missing entry means no framework-based player will show that file.

Android's MediaCodec documentation describes apps enumerating the decoder components the board provides, and a codec-listing app prints exactly that set. Codec Info is one such app. Read the profile line on the AVC entry: a decoder that lists Baseline only refuses a file exported at Main or High profile, and that mismatch black-screens the video in a framework player while a bundling app plays it happily. Matching the export profile to the listed profiles removes the guesswork.

If AVC is absent, the framework has no H.264 decoder at all. Re-encoding to a smaller file cannot help, and the board is either below the player's minimum Android version or carrying firmware that was never suited to video work.

Which storage location should the player use on an old board?

Point the storage setting at the emulated SD card, the folder path that starts /storage/emulated/0, because some older boards play video only from that location and refuse files held in the player's private storage.

The setting lives in the player app's own settings screen as its storage location choice. Copy the video set into a folder on the emulated card, point the setting there, and reload the show. Where those copies land, and why private storage splits behaviour on old builds, is the subject of the page on where an Android signage player stores downloaded media.

Our own player takes a different route: it plays images and MP4 from microSD or USB and keeps a copy in internal memory, so the show carries on when the card comes out, and if the app stops it is designed to start again within seconds and go back to playing. The card builder section covers building a card load for it. What this page describes is how the software is designed to behave. It has been tested on the Android 12 emulator, and testing on a real unit is pending.

What encode settings decode reliably on Android 4.x?

Encode H.264 MP4 at Baseline profile: AVC, the MP4 container and AAC audio sit on Android's documented core format list, HEVC and VP9 are not safe assumptions on a 4.x board, and a 640 x 360 file serves a 600-wide region at a quarter of the decode work of 720p.

Three settings carry the fix:

• Container and codec. MP4 with H.264 and AAC audio. AVI is not on the core list, so a re-wrap to MP4 is part of the fix.
• Profile. Old boards commonly list the AVC decoder at Baseline only. The codec-listing app settles what your board accepts in a minute, and the export matches it.
• Size and bitrate. A 16:9 video filling a 600 px wide region shows 600 x 338 of picture, because 600 x 9/16 = 337.5. Encode 640 x 360 and the player scales 640 to 600, a 0.94 factor nobody sees. Start at 1.5 to 2 Mbps for 640 x 360 and 4 to 5 Mbps for 1280 x 720, typical H.264 targets for loop playback, and run the deciding test on the board; the page on testing video bitrate before you deploy walks that test.

If the video is built from slides, exporting the slides to video for an offline signage player starts from these same settings.

Scenario: why does a 720p video black-screen in a 600 x 782 region on Android 4.4.2?

A 720p file in a 600 x 782 region on Android 4.4.2 decodes at its native 1280 x 720 and then scales down, so the region size never decides playback; check the AVC decoder and the storage location, and re-encode at 640 x 360 if the board struggles.

The board is a full-HD portrait panel, 1080 x 1920. The layout places a video region 600 x 782. The file is a 1280 x 720 H.264 MP4 exported from a motion-graphics tool, and it plays in a media app on the same board.

The decoder list shows an AVC decoder with Baseline and Main profiles, so decode support exists. The region never enters the decode step: the file decodes at 1280 x 720 and the surface scales afterwards, 600 ÷ 1280 = 0.469 and 720 x 0.469 ≈ 338 px of picture height inside the 782 px region. Nothing in that arithmetic points at the region.

Storage is the failing layer: the CMS holds its media in app-private storage, and this old build reaches only the emulated card. Copy the file set to /storage/emulated/0, point the storage location setting there, and reload. The video plays.

Re-encode while you are there, because the board is decoding four times the pixels the region shows: 1280 x 720 = 921,600 px per frame, 640 x 360 = 230,400 px per frame, and 230,400 ÷ 921,600 = 0.25. At Baseline profile and 1.5 Mbps with AAC audio, the on-screen result is identical, 600 ÷ 640 = 0.94 giving 600 x 338, and the decode load drops to a quarter. Every future file for that board encodes the same way.

When is the Android version the problem rather than the file?

A signage player app publishes a minimum Android version, and one widely used CMS player draws that line at Android 4.4.2; the board's Android build cannot be changed from the app, so below the line the paths are a firmware update from the board maker or new hardware.

Read the minimum from the CMS player's requirements page and the board's build from its settings screen. The vendor sets that line where its own video handling is supported, and its documentation points at unsupported codecs below it, so no file change crosses the line. The upgrade path is the board maker's own firmware, obtained from the maker or its authorised distributors. If no build is offered for the board any more, the board has reached its end and the show moves to current hardware.

What should you do when the board cannot play the file at all?

If the decoder list shows no AVC entry, the firmware cannot be updated, and moving the files to the emulated card changes nothing, retire the board and move the show to current signage hardware that documents its video support.

Work the checks in order and stop at the first one that holds: storage location, encode profile, re-encode size, then the Android version line.

A replacement screen is chosen from the seating first. The common planning figure is 30 ft of viewing distance per inch of capital letter height, with 20 ft per inch the safer figure for fast reading, on the FHWA basis. The guide on what size digital signage screen you need carries the table for your distances.

If the replacement is one of our panel-mount displays, the included player plays MP4 from microSD or USB with H.264 as the recommended encode and no subscription. If you need to keep your CMS, that route stays open too: a customer may install their own cloud CMS app on our units instead of the included player. For a current wall model, have the video support confirmed in the quote.

Recommendation: Move the video set to the emulated SD card and re-encode to H.264 Baseline MP4 sized to the region before touching anything else: 640 x 360 at about 1.5 Mbps with AAC audio serves a 600-wide region. Replace the board only when the decoder list shows no AVC entry, the profile cannot be matched, or the Android build sits below the CMS player's stated minimum.

Questions