A four-region video layout shows one stream and three black windows because the box grants a limited number of decoder sessions at once: one on low-cost Android boxes, two to four on signage-grade hardware. Run a four-file layout test to find the count, then either tile the four camera feeds into one stream or serve still snapshots on a 0.5 to 1 s timer. The article works the bandwidth numbers for both fixes.
Put four camera feeds or four videos into four regions of one layout and most low-cost Android boxes show one video and three black windows. Which one survives changes between boots. The streams and the network are usually fine; the limit is the box's video hardware, which on these devices opens one decode session at a time. The number that decides it is the concurrent decoder session count: 1 on cheap TV boxes, 2 to 4 on hardware built as signage players. This article explains what the count is, gives you a layout test that separates a session limit from a slow network, and works through the fixes with numbers: still snapshots refreshed every 0.5 to 1 s, or one tiled stream replacing the four originals.
The number that decides it: concurrent decoder sessions
Every video that plays on an Android device holds one decoder session. The session is a slot in the chip's video hardware, granted by the device firmware. An app that wants four videos playing at once wants four sessions at once. When the firmware grants one, three of your four regions are refused, and the app draws them black. Which region wins can change between boots on a one-session box.
The app's theoretical escape, decoding on the CPU, rarely carries a layout like this. Android's low-level codec interface, the MediaCodec class, can open software decoder instances, and one test script reached 20 to 35 of them on a single device; the author's note is that the result will not run as expected. A software fallback that cannot keep up with the streams it opens is no fallback for a four-region wall.
The real ceiling sits in the video hardware. The maintainers of a widely used Android video player library state it plainly in a public issue about running several player instances at once: there is a maximum number of decoder instances you can instantiate, and four counts as generous. Low-cost TV boxes commonly grant one session. Boxes built as signage players commonly grant two to four. The count sits below the app: no setting in a signage app raises it, and reinstalling the app changes nothing.
Two details matter for a camera wall. The source makes no difference to the count: a local file and a camera stream each hold one session once they are decoding, so four regions fail identically whichever they contain. Getting the first stream to play at all is the separate problem covered in why an RTSP stream will not play on an Android signage player. And the count appears on almost no retail spec sheet; cores, RAM and a 4K badge get printed, sessions do not. Our guide to what a digital signage spec sheet tells you covers the numbers that do get printed.
Test the box with four local files
Take the network and the cameras out of the question before you conclude anything about them. Build a layout with four video regions and put a short local MP4 loop in each, at the resolution your cameras produce, say 1280 x 720. Push it to the box and watch.
- One video plays and three stay black: the firmware grants one session. The count is the limit, not the network.
- All four play: the box grants at least four sessions, and the original problem sits upstream in the streams, the bandwidth or the app's stream support.
- All four open but stutter, or the box restarts: the sessions exist and the CPU cannot carry them.
- Two regions play and three fail: step the region count up one at a time. The largest number that plays together is the session count.
If a local file refuses to play in any region, that is a different failure with its own causes; start with USB video playback troubleshooting for signage displays before blaming sessions.
Example: four camera snapshots refreshed every second on a 100 Mbit/s link
Scenario: a four-region wall shows four cameras on a player that tests at one session. You choose the snapshot route, with a 1 s refresh and 0.5 s as the fast option.
Inputs:
- 4 cameras, the layout in question.
- 100 KB per JPEG snapshot at 1280 x 720. A 720p JPEG lands between 50 and 150 KB depending on scene detail; use 100 KB as the planning figure and check one real snapshot's file size in the camera's web interface.
- Refresh interval 1 s, with 0.5 s as the fast option.
- 1 KB taken as 1,000 bytes; a wired 100 Mbit/s link from the switch to the player.
Rule in words: bandwidth per camera equals snapshot size divided by refresh interval. Total bandwidth is the camera count times the per-camera rate. Bytes convert to bits with a factor of 8.
Arithmetic:
- Per camera at 1 s: 100 KB / 1 s = 100 KB/s = 800 kbit/s = 0.8 Mbit/s.
- Four cameras: 4 x 0.8 Mbit/s = 3.2 Mbit/s.
- At 0.5 s the interval halves, so the rate doubles: 3.2 x 2 = 6.4 Mbit/s.
- Share of the link: 3.2 / 100 = 3.2%, and 6.4 / 100 = 6.4%.
Result: both rates fit the wired link with room to spare; the fast option uses under 7% of the line.
Decision: keep the whole snapshot load under about a quarter of the line rate, 25 Mbit/s here, so added cameras and other traffic keep headroom. Four cameras at 1 s sit at 3.2 Mbit/s, an eighth of that ceiling; at 0.5 s the 6.4 Mbit/s is still about a quarter. Start at 1 s and move to 0.5 s only when the faster update changes what the sign does for you. The snapshot route holds zero decoder sessions, so a one-session box shows all four regions unchanged.
Two notes on making it draw. Signage apps that render web regions through Android's embedded browser frequently fail to show an MJPEG stream even when the device's own browser plays the same address; fetch a plain JPEG on a timer, so each update is an ordinary image the browser can draw. And a hand-built page of four camera previews embedded in the app puts you back inside that embedded browser, exactly where this rendering fails. The tiled stream in the next section reaches the same single-session result with live motion.
Fixes for a box that grants one session
| Route | Decoder sessions | What the sign shows | Network load |
|---|---|---|---|
| Snapshot region per camera, 1 s refresh | 0 | Still image per camera, updated each second | 3.2 Mbit/s for four 720p snapshots at 100 KB |
| Snapshot region per camera, 0.5 s refresh | 0 | Still image, updated twice a second | 6.4 Mbit/s |
| One tiled 1080p stream from an NVR or encoder PC, 15 fps at 2 Mbit/s | 1 | Live motion, all four views in one video | 2 Mbit/s |
| Four separate camera streams | 4 | Live motion per region | 8 Mbit/s at 2 Mbit/s per stream |
The tiled stream is the fix when you need motion. An NVR or a small encoder PC combines the four feeds into a single 1920 x 1080 H.264 video, the player decodes one session, and all four views appear. Configure the encoder at 15 fps and 2 Mbit/s as a starting point. The same move cuts the network load: four separate 720p streams at 2 Mbit/s each add up to 8 Mbit/s, so the tile saves 6 Mbit/s. Prove the file or stream on the desk before installation, the way you would test video bitrate for a signage player before you deploy.
A player PC is the remaining route when per-region motion is a hard requirement. Player software on a Windows PC decodes on the CPU, so the ceiling is processor headroom, not firmware. The arithmetic: four 720p windows at 30 fps move 1280 x 720 x 30 x 4 = 110.6 million pixels per second, a bit less than two 1080p30 streams (1920 x 1080 x 30 x 2 = 124.4 million), a load desktop CPUs have carried in software for years. Run the same four-file layout on the intended PC before you mount it.
When one full-screen camera at a time is enough, none of this is needed: a playlist that rotates the feeds full screen holds one session, plays every camera in sequence, and runs on boxes that fail every multi-region layout.
What to spec for a four-camera wall
Recommendation: Run the four-file layout test on any box before you buy more of it, and ask for the concurrent decoder session count in writing whenever a supplier claims multi-video support. If the count is 1 and the sign must show live motion from four cameras, tile the feeds into one 1920 x 1080 H.264 stream at 15 fps and 2 Mbit/s on an NVR or encoder PC. If a once-per-second look is enough, serve plain JPEGs on a 1 s timer and keep the total under a quarter of a 100 Mbit/s link. When the sign's job is packaged files instead of live camera feeds, our free offline signage player plays images and MP4 from microSD or USB, and the concurrency question never comes up; live feeds remain the RTSP case covered above.
Questions
Does the video resolution change the decoder session count?
No. The count is fixed in the device firmware, and the same device grants the same number whether the videos are 480p or 1080p. Resolution changes how heavy each session is: smaller videos cost less memory and decode headroom, so a box that barely carries its sessions at 1080p can run them smoothly at 720p. The count decides how many videos can open; resolution decides whether they play smoothly once open.
How do I find a device's session count before buying it?
Retail sheets list cores, RAM and a 4K badge, and almost never decoder sessions; the figure lives in the chip maker's codec documentation, and resellers rarely know which chip is inside the box. Ask the seller for the concurrent decode session count in writing. If nobody can answer, buy one unit and run the four-file region test; one layout and a few minutes give you the number for that exact firmware.
Why does a different camera win after every reboot?
On a one-session box the single available slot is taken by one video region and the rest are refused, and which region takes it varies between boots. The changing winner is the session limit showing itself, not a failing camera or a bad cable. The cameras are healthy; four local files in four regions will reproduce the same one-winner behavior.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.