How to livestream an event to Android signage displays

Which streaming protocol should the event use?

Use HTTP Live Streaming, HLS, delivered over plain HTTP or HTTPS: it plays on Android signage players going back to version 4.4, and it crosses the proxies and firewalls on corporate LANs that stop RTSP.

RTSP is the wrong tool twice over. Most Android signage players refuse an RTSP URL outright, which why an RTSP stream will not play on an Android signage player walks through, and corporate networks block the ports it wants. For delivery to many players over ordinary networks, plain HTTP delivery wins on the same grounds.

HLS works because it is boring. The server cuts the video into short files, 6 seconds each as the common length, and publishes a text playlist, the .m3u8 file, that lists them. The player fetches each file over the same HTTP a web page uses. Any LAN, proxy or firewall that lets a display load a web page lets it play the stream, and the media stack in Android versions as old as 4.4 already handles it.

Should you stream from your own server or a public video platform?

Run your own media server for an internal event on your own displays, and embed a public video platform only when the event is already being broadcast there.

An embed puts the event inside a web view on the display, and three things stop being yours. Whether it autoplays is set by the platform's embed options, and those options change. The platform can put its own overlays and recommendations around your event. The platform picks the bitrate each display receives, so the bandwidth planning below goes out of your hands. With 25 displays, each embed opens its own session, so the stream count is the same either way. And anything you send to a public platform is public, which settles it for a town hall.

Your own server gives you the segment length, the bitrate, the ports and the playlist, and the display sees one plain URL you control. Commit to this for internal events: all-hands meetings, staff launches, plant-floor announcements. Embed the platform when the event is public there anyway and your screens are an extra outlet, not the main one.

What do you need to build the HLS stream?

A camera or encoder feeding one media server that writes 6-second segments and a playlist, plus one media entry in your CMS: that is the whole chain.

• Source: a camera with an RTSP output, a laptop capturing the venue switcher over HDMI, or the house feed. If the camera speaks RTSP, the media server converts it to HLS, and converting an RTSP camera stream to HLS for web playback shows the same conversion on an industrial screen.
• Encoder: ffmpeg on the capture machine sending one feed, or the camera's built-in encoder. One stream in, one HLS output.
• Media server: any streaming media server that writes HLS. It serves the segments and the playlist over HTTP on port 80, or over HTTPS on port 443 when the URL leaves your network.
• The URL: an address like https://your-server.example/hls/event.m3u8. Every display gets this one address.
• The CMS entry: one media item, published to a display group.

If some of the screens are our panel-mount units, be straight about what they do: the free IMD Signage Player described in the player category plays images and MP4 from a card and can sync a playlist from your own web server over HTTPS, and a live-stream entry is not something we claim for it. Those units can run a customer-installed CMS app instead, and that app's documentation says whether it plays a stream URL. A new-range model's software is confirmed with its quote. If you are still choosing displays for stream duty, the digital signage player guide lists what to check.

How far behind the camera will the displays be?

Plan on 15 to 30 seconds end to end: the segment buffering in classic HLS alone can put playback 15 seconds or more behind the camera, and encoder delay and player buffering add the rest.

Latency adds up in three places, and the formula is: segment length x segments held in the live window, plus encoder delay, plus the player's start buffer. At 6-second segments in a 3-segment window: 6 x 3 = 18 seconds of video held back, plus 1 to 2 seconds of encoding, plus 2 to 4 seconds of player buffer, so 21 to 24 seconds end to end. Call it 15 to 30 seconds across a real chain, and quote that number to the event organizer.

Low-latency HLS is built, by design, to land about 3 seconds behind the camera: the player loads partial segments before a file is finished, and the server holds a playlist reload until the next segment exists. The cost is player support. The app on the display has to implement it.

For signage, commit to classic HLS. Nobody in a lobby or at the end of a production line compares the screen to the room. Go low-latency only when a presenter will point at the screen and narrate what is on it right now, and every display's player supports it.

How much bandwidth does a 25-display scenario need?

50 Mbps of sustained egress from the media server: 2 Mbps per display times 25 displays, because each display pulls its own unicast copy across its own LAN.

The scenario: a company town hall, 25 displays across three buildings on three LANs, one stream at 1080p in H.264 at 2 Mbps. Two megabits per second is the planning figure for a 1080p event stream; video bitrate for a signage player: test before you deploy shows how to confirm it on your own displays.

Egress from the media server: 2 Mbps x 25 displays = 50 Mbps sustained. HTTP request overhead is small; plan for 60 Mbps. The usual planning rule is to keep sustained traffic under 70% of a link, so you need 50 / 0.7, about 71 Mbps of capacity, and a 100 Mbps uplink on the server side passes with room.

The check on the table: 20 + 18 + 12 = 50 Mbps, the same 50. Each building's 100 Mbps circuit runs at 20% or less.

Wireless displays each add their 2 Mbps to the airtime of their access point, on top of the phones and laptops already there. Wire the screens you can. Two ways to cut the count: where several displays hang in one room, one Android signage player driving multiple displays turns 3 streams into 1. Multicast would send one copy to everyone, but it stays inside a single LAN and needs switch configuration to stay there; across three LANs, unicast is the answer.

How do you put the stream on every display?

Create one media entry whose source is the playlist URL, put it alone in a full-screen layout region, and publish that layout to a display group holding all 25 displays.

1. Create the media entry. In the CMS, add a video or web media item whose source is the playlist URL, an address like https://your-server.example/hls/event.m3u8. Use HTTPS on port 443 with a current certificate once the URL crosses between buildings; plain HTTP on port 80 is fine inside one LAN.
2. Give the stream the whole screen. An Android player cannot show multiple videos at once, so keep promo video out of that region; still images beside the stream are fine.
3. Publish to a display group holding all 25 displays, the day before the event, and confirm every display reports the new layout.
4. Schedule the stream layout in the CMS to start 15 minutes before the event and end 15 minutes after, so early arrivals see the holding card.
5. Assign the standby playlist from the next section as that group's fallback.
6. Walk one display per building and watch 60 seconds of live video on each.

What plays on the screen when the stream drops?

A standby playlist: a looping MP4 of the event title card and a short 'live stream resumes shortly' slide, assigned so the region falls back to local media whenever the URL fails.

A stream drops at the encoder, at the server's uplink, or at one display's Wi-Fi. Local fallback media keeps something on the screen while you fix it.

Build the standby as an ordinary offline playlist: the event title card as an image, a 10-second MP4 loop with the event name and the words 'live stream resumes shortly', nothing with a time on it. Assign it as the fallback for the stream region. Test it in rehearsal by pulling one display's network cable for 60 seconds: the standby appears, and when the cable goes back the display rejoins on its next playlist reload, inside about a minute.

Two failure paths sit next door. A black screen while the URL still loads points at the video format, and the black screen on video page separates the causes. After a power cut, our own player is designed to start again within seconds and go back to playing, which power loss recovery for offline displays walks through.

How do you check the whole chain before event day?

Run four checks with numbers: a stopwatch latency test, a 30-minute soak at full bitrate, a reachability test from outside your LAN, and a forced dropout on one display.

1. Latency. Hold a running stopwatch in front of the camera and read the time on the furthest display. Read it three times; expect 15 to 30 seconds behind the watch. Three reads within a few seconds of each other means the chain is stable.
2. Soak. Run the full chain for 30 minutes at event bitrate and watch the server's egress hold near 50 Mbps for 25 displays. A slow climb means something is re-fetching; find it before event day.
3. Reachability. Load the playlist URL from a phone on cellular and from a laptop on the farthest LAN. Both must play. This catches the proxy and certificate problems that only show up off your own network.
4. Dropout. Pull the encoder feed for 30 seconds, then pull one display's cable for 60 seconds. The standby playlist must appear both times, and every display must rejoin the live window within about a minute of the feed returning.

Recommendation: for one event across several LANs, run your own media server writing classic HLS, 6-second segments in a 3-segment window at 2 Mbps per display, publish one playlist URL to a display group of all 25 displays, and keep a local standby playlist behind it. Choose low-latency HLS only when the player on every display supports it and someone will react to the screen in real time; embed a public video platform only when the event is already public there.

Questions