A passthrough player with a video-input overlay keeps live TV within 0.1 s of the source. An HDMI-to-IP encoder or a tuner-to-IPTV gateway shows the same picture in a player window, adding seconds of delay that decide sports-bar jobs. This comparison gives the delay each route adds, the hardware each needs and where each wins.
Live TV and a scrolling ticker can share one signage screen. The route you choose decides how far behind the broadcast the sign runs, from a fraction of a second to as much as two seconds. This page compares the three routes: a passthrough player with a video-input overlay, an HDMI-to-IP encoder shown in a player window, and a tuner-to-IPTV gateway, with the delay each adds, the hardware each needs and where each wins.
Can a signage player show live TV and a scrolling ticker on one screen?
Yes, by three routes. A passthrough player with a video-input overlay adds under 0.1 s. An HDMI-to-IP encoder shown in a player window adds roughly half a second to two seconds. A tuner-to-IPTV gateway serves many screens with a similar delay. All three keep two zones on one panel: a video zone for the TV picture and a band across the top for the ticker text. The route decides how far behind the live broadcast the sign runs, how many screens one feed can reach, and what the player has to be able to do. The table sums them up; if no player is chosen yet, the guide to choosing a digital signage player covers the basics this page leaves out.
| Route | Added delay | What the player needs | Where it wins |
|---|---|---|---|
| Passthrough player with video-in overlay | Under 0.1 s | A capture input plus a documented interface that places the incoming picture in a window | Any room where the sign is watched next to another TV |
| HDMI-to-IP encoder | About 0.5 to 2 s | Any player or app that renders a network stream in a window | One or two signs fed from a rack |
| Tuner-to-IPTV gateway | About the same, plus headend processing | The same windowed-stream player on every screen | Several signs on channels off one antenna or dish |
Which route adds the least delay to the live picture?
The passthrough route wins. The TV signal crosses the capture chip without a re-encode, so the sign runs about two frames at 30 fps behind the source, under 0.1 s. The IP routes re-compress the picture and can add up to two seconds of lag.
Treat that range as a planning figure with three parts. The encoder holds a few frames while it fills its buffer. The LAN crossing takes a few milliseconds. The player holds 0.5 to 1 s of stream to ride out network jitter. Dedicated encoder hardware keeps the range at its low end because compression runs on its own silicon off the CPU; a general-purpose computer encoding in software drifts toward the top. The setting that moves the number most is the player's buffer: tightening it from 1 s to 0.2 s buys back delay and risks stutter on a busy network.
The delay matters exactly when the same channel plays on another screen in the room, because the other TV shows the goal before the sign does. That one fact settles most sports-bar jobs.
Which players can take HDMI in and show it under a ticker?
Only the players sold for this job. They pair a capture input with a documented interface the signage app calls to place the incoming picture in a window, and the vendor should demonstrate both with a bench demo of your ticker running over live video before any order. Ask for three things in writing: the name of the interface in the player's developer documentation, the maximum input resolution the capture path accepts, and a demo unit or a recording of your own ticker file running over a live channel.
The demo should also let you set the band's font, size, color and scroll speed, since a fixed-style band fails this job quietly. If your feed carries emoji, check those glyphs in the same run, because a font without them shows empty boxes.
There is a hard limit at the other end of the market. An ordinary Android signage unit, such as the player units in our catalog, takes no HDMI in at all. The HDMI port on that class of hardware is an output, so the passthrough route calls for a different player. Our own units run the playlist side of a sign from a card, and you can install your own Android app on them; an app that renders an RSS band covers the content side, while the live picture still has to arrive by one of the other two routes. The page on why an HDMI input on an Android signage player rarely works goes through that limit in detail.
How does an HDMI-to-IP encoder feed the ticker layout?
A small encoder box takes the TV box's HDMI output, compresses it to H.264 and puts it on your LAN as a stream. Any player app that renders a network stream shows it in a window below the ticker, adding half a second or more end to end. Plan the network at 4 to 8 Mbps per 1080p channel, the range broadcast-quality H.264 needs. One channel is a rounding error on a gigabit LAN; ten channels add up to 80 Mbps, which wired links carry without strain. Before you deploy, push a test clip through the same encoder settings and watch it on the real screen; the page on video bitrate for a signage player sets out what to test.
The encoder side of the delay is fixed at purchase; the player's network buffer is the setting to tune. Start it at 1 s, stand in the room with a stopwatch against another TV on the same channel, and tighten it only while the picture stays steady.
Picture quality on fast motion varies by app and by stream settings, so judge it at the bench: push a sports clip through your chosen encoder and player, and look for blur and lip-sync drift on the real screen. The page on blur and sync drift in signage player video engines shows what those faults look like. The window itself is ordinary player configuration, a stream URL, a decoder and a buffer; a walkthrough of configuring a video player component for a live stream shows the settings such a window takes.
When is a tuner-to-IPTV gateway the better buy?
From about three screens, or whenever the channels arrive on one antenna or satellite feed, a tuner-to-IPTV gateway at the headend beats stacking encoders. It tunes each channel once and serves every player on the LAN, with the same order of delay as a single encoder. You buy tuner capacity: ten screens on four channels need four tuners and ten ordinary windowed players, and screens 5 to 10 add no new headend gear.
Gateways deliver the streams as multicast, one copy of each channel that every player joins, or as unicast, one copy per player. Unicast stays sensible for a handful of screens and turns wasteful past a dozen; match the mode to the switch gear in the rack.
The split points: one screen on one channel takes a single encoder and nothing else. Two screens on the same channel share one encoder. Different channels on different screens is gateway territory from about three channels up.
One note belongs here once: the sign moves the picture around the building and changes nothing about what the venue is licensed to show. A bar or gym fitting several screens sorts out its commercial TV licence before the first screen goes live.
Worked example: how big are the ticker band and the video window on a 50-inch screen?
On a 50-inch 16:9 screen read from 12 ft, a 120-pixel ticker band across the top of a 1920 x 1080 layout leaves a 1920 x 960 video window, and 0.6-inch capitals in the band meet the safer legibility figure for that distance.
A 50-inch 16:9 panel measures 43.6 in wide and 24.5 in tall, so 1080 pixels spread over 24.5 in works out at about 44 pixels per inch. The FHWA planning figure is 30 ft of viewing distance per inch of capital height, with 20 ft per inch the safer choice for fast reading. At 12 ft: 12 / 30 = 0.4 in capitals, 12 / 20 = 0.6 in capitals. On this panel 0.6 in is 26 pixels, and the 1.7 line-spacing rule gives a line pitch of 1.7 x 26 = about 44 pixels, so a 120-pixel band holds the line with padding to spare.
The video zone takes the rest: 1080 - 120 = 960 pixels tall at the full 1920 wide. A 16:9 channel fitted to that height fills 960 x 16 / 9 = about 1707 pixels of width, so it pillarboxes with a bar about 107 pixels wide on each side, or crops if the app allows it.
Set the scroll so the band crosses the 1920-pixel width in about 16 s, which is 1920 / 120 px/s = 16 s, a pace where a phrase can be read as it passes. Budget the delay into the room too. On the IP routes this picture runs about 1.5 s behind the bar's other TV at typical settings, 0.5 s of encoder plus 1 s of player buffer, while the passthrough route sits under 0.1 s behind. If the same channel plays on two screens, that difference settles the route before any layout does. A band that shivers while it scrolls is a separate fault with its own causes; the page on why RSS ticker scrolling looks jerky works through them.
Where does each route win, and which one should you pick?
Passthrough wins wherever the live picture is compared against another screen. The IP encoder wins one or two signs fed from a rack. The gateway wins multi-screen venues on a shared antenna. The room's tolerance for one to two seconds of lag is the number that decides. Concretely:
- Passthrough with a video-in overlay: sports bars and any room where people glance between two screens. The low delay buys a short player list, so run the bench demo before the order.
- HDMI-to-IP encoder: a cafe, salon or gym with one or two signs. The TV box stays in the rack, the LAN already reaches the wall, and the app needs only a stream window.
- Tuner-to-IPTV gateway: hotels, gyms and bars with several signs on different channels off one dish or antenna.
Recommendation: If the sign must match another TV in the same room within a second, buy a passthrough player with a documented video-input interface and have the vendor demonstrate your ticker file over live video before you pay. If the room has one or two signs and no second TV on the same channel beside them, run an HDMI-to-IP encoder and any player that renders a stream in a window, budgeting for the two-second worst case. At three or more screens, or every channel off one antenna, put a tuner-to-IPTV gateway at the headend and keep the same windowed layout on every player.
Questions
What encoder settings keep the live picture sharp?
Encode 1080p H.264 at 4 to 8 Mbps with a keyframe interval of 1 to 2 seconds, and keep the encoder buffer small, because every frame it holds adds straight to the glass delay. Match the stream resolution to the window it fills: a 1080p feed in a 1920 x 960 window stays clean, while a smaller encode goes soft when the player upscales it.
Can the ticker text still be updated by text message?
Yes, with a small service in the middle: a script receives the message, appends it to an RSS or Atom file, and the ticker app pulls that feed on a timer. A refresh every 1 to 5 minutes keeps a manually fed banner current, and the timer lives in the ticker app, not the player. Test the full chain once, message to screen, before it goes on a wall.
Do any of these routes need an internet connection?
No. Passthrough never touches a network. The encoder and gateway routes run on the building LAN, so the video stays inside, and the ticker feed can live on a small server in the same rack. The only internet use is the feed update itself, if you choose to publish the ticker text from off site.
What should the ticker do when the live picture freezes?
Keep the band independent: put it in its own layer so a stalled stream leaves the text scrolling on its last content. Pick a player whose stream window is designed to reconnect when packets flow again, ask the vendor how the window behaves after a drop, and watch it in the bench demo by unplugging the source for 30 s.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.