An Android signage player has no standard way to read an HDMI input: the platform ships no input interface, so the feature only exists where the screen maker built it into the operating system. A USB capture dongle or an HDMI-to-IP encoder brings a feed in, at about 67 ms or 0.5 to 2 seconds of lag. Choose by who acts on the picture.
A live feed on a floor board is a standing request: the camera above the cell, the test bench output, the laptop that walks in with a demonstration. On an Android signage player the port almost never takes it. The feed gets in by conversion, or it gets in because the screen's own operating system owns the input. This page sets out why Android has no input path of its own, what each workaround costs in lag and hardware, and which route fits which job.
Can an Android signage player show an HDMI input?
Almost never, and not because of the player: Android ships no standard API for reading an HDMI input, so a player maker cannot write one feature that works across Android devices, and only a display whose own operating system exposes the input can show it directly.
The documented Android display interfaces work on the output side: selecting display modes, driving a panel, talking to a TV over the connector. Nothing in the platform hands an application the frames arriving on an HDMI socket, because Android was written for phones and tablets that never carried one. Where an Android box does ship an HDMI-in socket, that socket is served by the maker's own software layer, written for that model and closed to other apps. A signage player would need a separate build per device to touch it, which is why cross-platform players leave the feature out.
Practical check before you buy any player for this job: ask the player vendor, for the exact device model, whether the app has an input or camera region. Get the answer against the model number, because a yes on one Android box says nothing about the next.
Why does the input feature come built into some smart-TV signage screens?
Because on a smart-TV signage platform the input lives in the operating system: the screen maker writes the input plumbing once for every panel of the model line, and a player app gets one documented call to place that input inside a layout region.
One operating system covers the whole model line, so the maker writes the input handling once and documents one interface for applications. A player can then place the live picture inside its own layout, next to the notices, on a timer the player controls.
What this changes on a real sign: the feature is bought with the screen. Write it into the specification and the quote, and make the supplier demonstrate the live input placed inside the player's layout region, switched on the player's schedule, not from a remote control. An input that only fills the screen from a menu is a different, cheaper product, and it will not run inside your layout.
Can a USB capture box bring an HDMI feed into an Android player?
Often yes, at the cost of a few frames: a capture dongle turns the HDMI feed into a USB webcam-class (UVC) device, and Android has supported UVC cameras in its platform since Android 9, if the box maker kept the camera stack in.
Two things decide it, and both are testable.
The first is the platform. Android has carried USB camera support in its camera stack since Android 9, so a dongle that follows the USB video class (UVC) can appear to apps as a second camera. Device makers can ship without that stack, and some do on locked-down boxes. The test costs nothing: plug the dongle into the player's USB port, open any camera test application, and look for the dongle listed as an available camera. If it lists, the platform side works.
The second is the player. The app needs a region type that draws from a camera device, and that is a feature to confirm with the player vendor before ordering anything. The guide to choosing a digital signage player covers how to pin features like this against a model before purchase.
Bandwidth decides the port. Raw uncompressed picture at 1920 × 1080 and 60 frames per second in the UVC YUYV format is 1920 × 1080 × 2 bytes × 60 = 249 MB/s, about 1.99 Gbps. A USB 2.0 port tops out at 480 Mbps, so on USB 2.0 the dongle falls back to compressed MJPEG or drops to 30 frames per second. A USB 3.0 port, rated 5 Gbps, carries raw 1080p60. Put the dongle in the fastest port the player has.
Worked example: how much lag does a capture chain add on a shop-floor board?
A 1080p60 camera on a USB capture dongle reaches the glass about 3 to 5 frames late, and one frame at 60 Hz is 16.7 ms, so plan on roughly 50 to 85 ms from machine to screen.
Scenario: a vision camera on the frame of a packing cell outputs 1080p60 over HDMI. A board beside the cell door, 2.5 m away on a passive USB 3.0 cable, shows the feed full width while the cycle runs, so the operator can watch reject stamps without leaning into the cell.
The arithmetic:
- One frame at 60 Hz is 1 ÷ 60 = 16.7 ms.
- Count 2 frames in the dongle's input buffer: 2 × 16.7 = 33.4 ms.
- Count 2 frames for the player's decode and display pipeline: 2 × 16.7 = 33.4 ms.
- Glass-to-glass lag: 33.4 + 33.4 = 66.8 ms, call it 67 ms.
Two frames per stage is the honest middle of the 1-to-3-frame range those stages hold, which is why the planning band reads 3 to 5 frames, about 50 to 85 ms. At 67 ms the operator sees the stamp two thirds of a blink late, fine for watching a process. The lag rule for the floor: observation feeds mirror, and guard decisions stay on the physical guard switch and e-stop, never on the picture.
The port arithmetic from the section above applies here too: 1080p60 raw needs about 1.99 Gbps, so this dongle sits in a USB 3.0 port, and the chain runs.
What does an HDMI-to-IP stream cost in lag?
Expect roughly 0.5 to 2 seconds from source to glass: the encoder holds the GOP and the player holds a decode buffer, so a stream trades delay for distance and for sharing one source across many screens.
The chain: an encoder box takes the HDMI output, compresses it to H.264, and serves it as an RTSP or HTTP stream; the player draws that stream in a video region. Distance stops being a cable question, and one encoder serves every screen on the network that can play the format.
The lag comes from buffers: the encoder holds picture data to fill its group of pictures and smooth the network, and the player holds a decode buffer to ride out jitter. With default encoder settings, plan on 0.5 to 2 seconds source-to-glass; low-latency encoder settings pull it toward the lower half, at the cost of resisting network hiccups less. Browsers play HTTP-based formats but have no RTSP support, so the client has to speak the protocol; what an RTSP feed asks of a client is laid out in a guide to RTSP live feed setup in an HMI video player.
Field test before committing: run a stopwatch on the source device, point a camera at source screen and signage screen together, and read the offset in one photograph. Whatever it reads is the number to design around.
Does the HDMI port on an Android signage screen take a feed in?
Check the port direction before you buy: on Android signage players, including ours, the HDMI port is an output that drives a second screen, and no feed can enter through it.
Output means output: the port drives a projector or a second screen from the player. On our own panel-mount units it is an output, and a live external feed only enters through a capture dongle in a USB port. What those units do natively is play their own images and video from microSD or USB with no subscription, which is the right tool when the floor needs notices and schedules instead of a mirror; the shop-floor screens range is built for that job.
For the newer wall and counter range, ports and features are confirmed in the project quote, and the same rule holds: an HDMI connector on a signage player is for driving a display unless the specification says otherwise in writing.
When is a live HDMI feed the wrong answer?
If the content starts as data, publish it as data: a dashboard or KPI feed rendered as a web page or image updates in seconds, costs no capture hardware, and sidesteps the input problem entirely.
Honest HDMI-in cases come from sources that only emit video: machine and vision cameras, test benches, set-top boxes, a laptop that arrives for a demo. When the source is a control system or a database, mirroring pixels is the expensive path. Push the values and render them at the screen; the choice between a live data render and a mirrored feed is set out in live factory data display: signage or dashboard?, and how to display a live dashboard on a signage screen covers the render side on a player.
Decision rule: if the content can be re-published as data, publish it; if the source only emits HDMI, convert it.
Which route should you buy?
The route follows who acts on the feed: operators reacting inside a cycle need the input feature bought in the screen, operators observing a process suit USB capture at about 67 ms, and wallboards that only inform suit a stream at 0.5 to 2 seconds.
| Route | Lag to glass | Extra hardware | Fits |
|---|---|---|---|
| Input bought in the screen | No added conversion lag | A screen whose operating system documents the input feature | Operators reacting inside a machine cycle |
| USB capture dongle | About 50 to 85 ms (3 to 5 frames) | UVC dongle, USB 3.0 port, camera region in the player | Operators watching a local process |
| HDMI-to-IP stream | About 0.5 to 2 s | Encoder, network, stream-capable client | Wallboards informing people at a distance |
Recommendation: for one screen within a few metres of a source that only emits HDMI, order a UVC capture dongle, put it in a USB 3.0 port, and confirm a camera region with the player vendor first; about 67 ms of lag is the cost. When several screens across a building share one feed, encode it once to a stream and accept 0.5 to 2 seconds. When an operator must act on the picture inside a machine cycle, buy the input as a documented feature of the screen's operating system, and have it demonstrated inside the player's layout region before the order.
Questions
Can one HDMI source feed several Android signage screens?
An HDMI splitter copies one source to many screens with HDMI inputs, and an Android player has none, so the splitter does not reach it. For several Android boards, give every board its own capture dongle, or encode the source once and stream it: the stream route scales across a building, and every screen shows the same 0.5 to 2 seconds of lag.
Does a USB capture dongle carry audio too?
Usually yes at the dongle: most capture sticks expose the picture as a webcam-class video device and the sound as a separate USB audio device. The catch is the player app, because many camera regions take video only. If the sound matters to the job, ask the player vendor to confirm audio from a capture device before you order the dongle.
How far can the HDMI source sit from an Android capture screen?
A passive USB 3.0 cable holds a reliable capture link for about 3 m, which covers a board mounted beside the machine it watches. For a source in another cabinet or room, put an HDMI-to-IP encoder at the source and cross the distance on the network, where the limit is the switch fabric rather than the cable.
Will a consumer TV solve it cheaper?
A consumer TV switches between its HDMI inputs from a remote, so the feed appears, but nothing schedules it. The TV cannot run the feed inside a signage layout, cannot attach notices next to it, and someone has to switch the input back. When the feed must sit inside a layout with other content, the capture or stream route is what makes that possible on Android.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.