Video bitrate for signage player: test before you deploy

Why does a video stutter in the signage app but play fine in VLC?

Because the two apps decode through different paths: the signage app plays 1920 x 1080 H.264 through the system media pipeline and its own rendering path, which stalls at high bit rates, while VLC carries its own decoder set and plays the same file fluently.

An Android screen box decodes video through the system media pipeline, and that path accepts only what the firmware's codec list exposes. A desktop player ships its own decoder set, software decoding included, so it can carry a file the system pipeline cannot. That is how one 1080p file loops cleanly in the desktop player and jerks through the signage app on the identical box, with nothing wrong in the file itself.

So the question is never whether the file is good; the desktop player answered that. The question is whether this box holds 1920 x 1080, 25 fps, H.264 at the file's rate, and the only test that answers it is the real file in the signage app. A clean desktop run is not proof about the app.

What symptoms point to a decode limit?

Stutter on a local file, an Unsupported Video message, and clean playback of the same file in a desktop player form the pattern: the first points to a rate the pipeline cannot hold, the second to a codec the capability check rejected, the third to a file that is itself valid.

• Jerky playback of a file stored on the device. Decode throughput is at its limit at that resolution, frame rate and bit rate. The file is local, so the network has no part in it; a read fault from a USB stick usually stops playback outright, a different fault covered on the USB video playback troubleshooting page.
• An "Unsupported Video" message with a failed capability check in the log. The app asked whether the device can decode the track and got no. On this failure the log names the check; a CanRun failure against an MPEG-2 track is the classic case. The bit rate never mattered, because the codec was never in the list.
• Clean playback in a desktop player. The file is valid; the limit sits between the app and the decoder. Where the app refuses the file outright instead of jerking, the video that plays over USB but not in the app page covers that case.
• Stutter that lands on the scene cuts. The instantaneous rate is the problem: a CBR encode is a target the encoder aims at, and encoders overshoot it at hard cuts, the mechanism behind why CBR encodes overshoot their target rate.

Desktop players word the refusal their own way, so the exact message text tells you nothing. The log's capability-check line is what separates a codec rejection from a rate problem.

Which codec, resolution and frame rate should the file have?

Encode H.264, the MPEG-4 AVC track that file inspectors show as avc1, in an MP4 container with AAC audio, at the screen's native resolution, 1920 x 1080 for a Full HD panel, at 25 fps: bench tests in this class of failure pass the H.264 files and reject MPEG-2 with Unsupported Video.

The standard behind the preference: Android's compatibility definition requires every compatible device to include an H.264 decoder. MPEG-2 decode carries no such requirement, so a player that reads the firmware's codec list can accept every H.264 file on the stick and refuse every MPEG-2 file, which is what the CanRun log line records. Shorthand used below: 1080p25 means 1920 x 1080 at 25 frames per second.

Frame rate: set 25 fps. Signage content is slides, price changes and slow pans, which 25 fps carries, and at equal per-frame quality it needs 1/1.2, about 17% fewer bits, than 30 fps, because 30/25 = 1.2. Keep 30 fps only for source footage shot at 30 that cannot be re-timed.

Codec alternatives: H.265 and VP9 cut the rate roughly in half on paper but depend on the unit. The player included with our panel-mount displays takes MP4, M4V or WebM and recommends H.264 MP4 for exactly this reason, treating H.265 and VP9 as unit-dependent. Build the H.264 master first, then bench-test anything fancier. What the firmware exposes decides what plays; the same rule, worked through for streams, is in the RTSP stream article.

How do you test the player before it goes on the wall?

Test the exact file, at the exact settings, in the signage app itself, on the bench, before mounting: load a 1920 x 1080, 25 fps H.264 CBR file at the top rate of your test set, play one full pass, and read the log for a capability-check failure.

1. Encode a three-file test set from one master. Export the same cut three times, H.264 MP4 with AAC audio, 1920 x 1080 at 25 fps, at three CBR targets: a top rate, two thirds of it, and a bit under half of it. The worked example below uses 10, 8 and 6 Mb/s. One master keeps the picture identical so only the rate changes.
2. Load them the way the screen will be fed in service. Device storage or card for a card-loaded player, USB stick if that is the update path.
3. Play one full pass of each in the signage app. Watch the first seconds, two or three cuts and the loop restart; note the lowest rate that plays clean start to finish.
4. Read the log after every pass. A codec rejection prints an Unsupported Video entry with a failed capability check (CanRun); a throughput limit jerks the picture while the log stays free of codec errors.
5. Write the passing rate on the box. That number is the encode standard for every file that screen plays.

A desktop pass does not mean the app will pass; skip it and go straight to the bench.

What does the bit-rate step-down example look like?

Take a 30-second 1920 x 1080, 25 fps H.264 loop encoded CBR at 10 Mb/s: it carries 400 kbit of data per frame, and stepping down to the 6 Mb/s target cuts that to 240 kbit per frame, a 40% reduction in the payload the decoder handles each frame.

Scenario: a cafe counter screen runs a 30-second promo loop, 25 fps, H.264 MP4 with a 128 kbit/s AAC track, encoded CBR at that top target. In the signage app the loop jerks through the pans and at every cut; the same file loops clean in the desktop player; the log shows no codec error. The capability check passed, so the codec is accepted and the rate is the suspect.

The arithmetic, video payload only:

• Bits per frame at the top rate and 25 fps: 10,000,000 / 25 = 400,000 bits = 400 kbit = 50 kB per frame.
• Loop size: 10 Mb/s x 30 s = 300 Mbit = 37.5 MB, plus 128,000 bit/s x 30 s = 3.84 Mbit, about 0.5 MB of audio.
• Re-encode at the middle target: 8,000,000 / 25 = 320 kbit (40 kB) per frame, 30 MB per loop.
• Re-encode at the lowest target: 6,000,000 / 25 = 240 kbit (30 kB) per frame, 22.5 MB per loop, a 40% cut against the top-rate file.

Result: the middle-rate encode plays a full loop clean and becomes the encode standard for that screen. Had the lowest rate still stuttered, the next lever is resolution: 1280 x 720 carries 921,600 pixels against 2,073,600 at 1080p, a factor of 2.25, so the lowest target divided by 2.25 gives the per-pixel-matched rate at 720p and frees most of the decode budget, at the cost of softer text on the 1080p panel.

How far can you drop the bit rate before quality suffers?

For slide-based signage, the lowest target in the set delivers 240 kbit per frame at 1080p25, enough for text, logos and slow pans; hold roughly twice that per-frame budget for full-motion video, and expect blockiness in moving footage once the frame budget falls to about 160 kbit.

The basis: broadcast practice has run full-motion 1080p H.264 at roughly 200 to 300 kbit per frame for years, and current platform guidance for 1080p uploads lands in the same range, as summed up in a guide to camcorder bitrate and codec specs for HD uploads. A signage loop is easier material: long stretches where almost nothing moves between frames are the cheapest case H.264 encodes, so 240 kbit per frame holds captions sharp and pans smooth. Below 160 kbit per frame, moving footage starts to block; spend that rate on throwaway test files only.

When the loop is text, prices and a logo, drop video altogether: images in JPG, PNG or WebP cost no video decode at all, and a slide build with gentle fades reads as motion on a price board.

When is the player box itself the problem?

If the H.264 capability check passes and 1080p25 still stutters at the lowest rate in the set, the box cannot hold 1080p H.264 at signage rates; replace it with a candidate that passes the same three-file bench test, and keep the stuttering box for desktop testing only.

Decide from the test result:

• Capability check fails, CanRun in the log: the codec was the problem, never the rate. Re-encode as H.264 MP4 and retest; the box stays.
• Check passes, stutter at the top rate, clean at the middle or lowest: the box stays, and the passing rate becomes its encode standard.
• Check passes, still stutters at the lowest rate: the box is out. Pick the replacement from the how to choose a digital signage player guide, then run the identical three-file test on the candidate before it ships.
• Only 720p passes at a usable rate: acceptable where the viewer stands well back; at counter distance, budget for the better box.

If the decision is new hardware: the IMD Signage Player included with our panel-mount displays plays images and MP4 video from microSD or USB with no subscription, and switching between portrait and landscape is one setting. The current wall and counter range is quoted per project, with software and formats confirmed in the quote; browse the panel-mount display range.

Recommendation: standardise on H.264 MP4, AAC audio, 1920 x 1080 at 25 fps, CBR at the top rate of the test set; bench-test that exact file in the signage app for one full pass before mounting; step down through the set if it stutters; encode every other file for that screen at the rate that passed; and replace the box when even the lowest rate still stutters while the capability check passes.

Questions