A live streaming server sends one copy of the stream to every screen, so 100 screens at a 1080p encode pull 400 Mbps and about 65 TB a month, and a dropped link blanks the screens. A player that caches the playlist locally needs 88 MB per content change and keeps playing through network drops. Use streaming only for genuinely live content on a few screens.
A live streaming server looks like a neat way to fill every screen in a chain: encode once, point every display at the same address. For fixed content such as menu boards, price loops and promotions, it is the wrong architecture, and the numbers show it fast. Across the public internet, every connected screen pulls its own copy of the stream, so bandwidth grows with each screen you add, and one dropped link blanks every screen behind it. A player that keeps the playlist in local storage needs one short download per content change and keeps playing when the network goes down; the digital signage player guide covers choosing that hardware. This page compares the two paths, runs the arithmetic for a 50-restaurant estate, and marks the narrow cases where a streaming server still earns its place.
What a streaming server sends to each screen
A WebRTC or HLS media server is built for live content: one encoder pushes the stream up once, and the server hands a separate unicast copy to every viewer that connects. Across the public internet there is no shared broadcast, so ten screens are ten viewers and a hundred screens are a hundred viewers.
Plan on a lean 1080p encode. Google's live encoder guidance lists 4 Mbps as the recommended bitrate for 1080p at 60 frames per second and 12 Mbps as the maximum, so take that as the working figure per screen. Each screen then holds a steady download at that bitrate for every hour it plays. Two menu boards in one restaurant pull 2 × 4 Mbps = 8 Mbps of download, every open hour, on the same line that carries the card payments and the mobile tills. Host the server in the cloud and the traffic leaves the cloud; host it on a machine at head office and your uplink carries it. That is the hosting question the does an on-premise signage CMS server need internet article works through for update pulls.
Scenario: 50 restaurants, two screens each
The whole comparison in one bill. Estate: 50 restaurants, two menu boards each, 100 screens, all showing the same loop.
Streaming path:
- Encode: 1080p at the 4 Mbps working figure above; the listed maximum is 12 Mbps.
- Server output: 100 screens × that bitrate = 400 Mbps for as long as the screens play.
- Per restaurant: 8 Mbps of spare download, every open hour.
- Monthly traffic at 12 open hours a day: 400 Mbps ÷ 8 = 50 MB/s; 50 MB/s × 3,600 s = 180 GB per hour; 180 GB × 12 h = 2,160 GB per day, about 2.2 TB; 2.2 TB × 30 days = about 65 TB a month, estate-wide.
Cached path, same loop:
- 30 slides: 29 images at about 2 MB each and one 60-second clip encoded as H.264 MP4 at the same per-screen bitrate.
- Images: 29 × 2 MB = 58 MB. Clip: that bitrate × 60 s = 240 Mb ÷ 8 = 30 MB. Total: 58 MB + 30 MB = about 88 MB per screen.
- One download per screen per content change: 100 × 88 MB = 8.8 GB; with weekly changes, four a month, about 35 GB a month.
The streaming architecture moves about 65 TB a month to deliver a loop that fits in 88 MB per screen, roughly 1,800 times more traffic. When a restaurant's link drops, both of its screens freeze on the last frame or go black until each client reconnects; a cached player rides through the same outage from storage.
Side by side
| Live streaming server | Local caching player | |
|---|---|---|
| What each screen receives | Its own unicast copy of the stream | A downloaded playlist, played from storage |
| Traffic at 100 screens | 400 Mbps out of the server; 8 Mbps per restaurant, every open hour; about 65 TB a month | 88 MB per screen per content change; about 35 GB a month estate-wide |
| Site internet drops | Screens freeze on the last frame or go black until the clients reconnect | Screens keep playing from storage; the next update lands when the link returns |
| Latency | Built for sub-second delivery, which only genuinely live content needs | No delay that matters; slides change on your schedule |
| What a new screen adds | Its own unicast copy at the per-screen bitrate | Nothing moves until you change content |
| Best fit | Live feeds and events, a handful of screens, one managed LAN | Menu boards, promos and notices across many sites on ordinary broadband |
Where a live streaming server wins
Commit a streaming server when the picture is live by nature: a match, a ceremony, a countdown, a camera feed the whole room watches at the same moment. WebRTC exists to get delivery under about a second, and that matters for exactly this kind of content. A handful of screens on one managed local network is the other fit: the bandwidth bill stays small and you control the switches.
Streaming still needs care. Public issue reports for one open-source WebRTC server describe freezes of 2 to 3 seconds every 20 to 30 seconds until the settings are tuned. After a dropout, a stream client has to rebuild its connection before the picture returns. And many signage players are built to play files, not streams, which is one more reason a loop belongs in storage: see why an RTSP stream will not play on an Android signage player.
Consumer streaming sticks often get proposed as the cheap receiver for this job. They are living-room devices, and the streaming stick or dedicated digital signage player comparison sets out where they stop.
Where a local caching player wins
Anything that changes on your schedule belongs in storage at the screen: menus, price lists, promotions, allergen charts, shift notices. The player pulls the updated playlist on a timer, keeps a local copy, and plays with no network at all. One content change reaches every screen as one short download, and nothing on screen depends on the link staying up. For how long a cached schedule keeps playing between updates, see offline signage schedule caching: how long playback lasts.
This is how our panel-mount units play: images in JPG, PNG or WebP, video in MP4, M4V or WebM, read from microSD or USB with no subscription, and a copy kept in internal memory so the show carries on when the card comes out. Encode video as H.264 MP4; that is the format we recommend and the encode the numbers above assume. Menu boards are the classic use, and the digital menu boards that run from a card category shows that setup end to end.
The decision
For a chain of restaurants, the everyday screens are not live, so the streaming server is the wrong architecture for them. Run the loops on caching players, encode at the bitrates above so files stay small, and let each screen pull its updates on a timer. Keep the streaming server for the few screens that show something genuinely live, with a cached loop behind them. At the 100-screen scale, that choice removes the steady 400 Mbps of server output, cuts estate traffic by a factor of about 1,800, and takes the internet link out of the failure path for every menu board.
Recommendation: put the menu loops on players that cache locally and pull updates on a timer; use a streaming server only where the content is genuinely live and the screens sit on one managed LAN. For 50 restaurants with two screens each, that means one download per content change instead of a live feed per screen, and menu boards that keep playing when the link drops.
Questions
Does one upload to a streaming server save bandwidth?
No. The upload happens once, but every connected screen pulls its own copy. One ingest at the per-screen bitrate feeding 100 screens is 400 Mbps of server output, and a cloud host charges for that output month after month. Multicast sends one copy to many receivers, but it works only inside one managed local network and stops at the router; across the public internet, delivery is unicast. Caching the playlist at each screen is what actually cuts traffic: the whole loop travels once per content change.
What does a menu-board screen show during a stream dropout?
Usually the last decoded frame, frozen, or a black screen until the client rebuilds the connection. A frozen frame is easy to miss: the backlight is still lit, so staff see a working screen and nobody reports the fault. Public issue reports for one open-source streaming server describe stalls of 2 to 3 seconds every 20 to 30 seconds even before a full dropout. A caching player has no reconnect step, so the loop simply carries on.
Can I mix live streams and cached menu loops?
Yes, and it is the sensible split. Keep menus, prices and promotions on players that cache locally, and point a stream only at screens that show something genuinely live, such as an event feed or a kitchen camera. Treat the live part as a bonus with its own failure mode: give those screens a cached loop to fall back on, and expect to tune encoder and server settings until the stream holds steady.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.