Why an RTSP stream will not play on an Android signage player

What RTSP asks of an Android sign

RTSP, the Real-Time Streaming Protocol, was published as RFC 2326 in 1998, and it is the protocol IP cameras and encoders speak. A player given an RTSP address does three things. It opens a TCP session to the camera on port 554, the well-known RTSP port. It negotiates the stream over that session. It then decodes the video frames the camera sends. A second common default port is 8554, and the address must carry the port number when a server uses it.

The first two steps belong to an RTSP client, which the player app can carry itself. The decode step belongs to the firmware: Android offers every app only the codecs its build includes. That split is the whole diagnosis. When the firmware has no decoder for the stream's codec, no app can supply one. When the firmware decodes fine, the missing piece is only the client.

Symptoms and what each points to

The behaviour on screen narrows the fault before you touch a cable:

• The playlist runs, the stream tile stays black or is skipped. The app cannot open the source: no RTSP client, or no decoder for the codec behind it.
• The same address plays on a laptop on the same network. Camera, address, port and network path all work; the fault is inside the sign.
• A local MP4 of the same content also fails. The firmware lacks the decoder, and only a firmware or Android update from the display maker changes that.
• The local MP4 plays and only the stream fails. The firmware decodes fine, and the signage app lacks an RTSP client.
• A dedicated RTSP app on the sign plays the stream. Same conclusion: the codec layer works and the signage app is the piece missing the client.

Checks in order

1. Open the RTSP address on a laptop on the same network, in a desktop RTSP player. If it plays, the camera, the port (554, or 8554 where the camera uses the other default) and the network path are all good.
2. Read the Android version on the sign in the device-information screen. Android 4.4.4 is a 2014 release. In the same breath, ask the display maker whether a firmware or Android update exists for that model. If none does, the codec set is frozen.
3. Play a local 1920 x 1080 H.264 MP4 from USB or microSD on the sign. This is the decision point. If the file also fails, the decoder layer is the fault. If it plays, the firmware is capable and the fault is protocol or content. A file that itself plays but the app refuses is a separate fault, covered in fixing a video that plays over USB but not in the player app.
4. Install a dedicated RTSP player app on the sign and open the address there. If the picture appears, the firmware decodes and your signage app is the piece without a client. Dedicated clients are built for this job: one lightweight Android RTSP client library documents about 20 msec of video decode latency on some streams.

Example: a 10-inch door sign on Android 4.4.4 that must show a lobby camera

Inputs. A 10-inch door-sign panel runs Android 4.4.4, a 2014 build with no update offered for it. Local H.264 video from USB plays; the camera's RTSP address does not. The camera serves RTSP on the default TCP port 554. The sign is on 8 hours a day, and its content, the lobby view plus the day's message, changes once a day. For the fallback clip, assume 1920 x 1080 H.264 at 4 Mbit/s, a mid-range setting for that resolution; every result below scales in direct proportion to the bitrate you actually have, so at 2 Mbit/s you halve them.

Rule. Data moved by streaming equals bitrate times on-time, divided by 8 to turn bits into bytes. A copied file moves its own size once per refresh and nothing more.

Arithmetic.

• One minute of clip: 4 Mbit/s × 60 s = 240 Mbit; 240 ÷ 8 = 30 MB.
• Streaming the camera through the day: 4 Mbit/s × 3600 s = 14,400 Mbit per hour; 14,400 ÷ 8 = 1,800 MB per hour; 1,800 MB × 8 h = 14,400 MB per day.
• The daily copy: 30 MB, once.
• Ratio: 14,400 ÷ 30 = 480. Streaming moves 480 times the data of the daily copy.

Result. A 30 MB refresh once a day replaces the whole live feed's traffic on that sign. Even an hourly refresh, 24 copies × 30 MB = 720 MB a day, stays small.

Decision. The local path wins whenever a refresh interval of an hour or a day is acceptable, and for a door sign it is: load the H.264 MP4 loop on the card and update it daily. The moment the content must be live within seconds, no file copy can deliver that, and the fix moves to the maker's firmware update or a separate streaming-capable device in front of the screen.

The fix, layer by layer

Decoder missing (the local MP4 also fails). The display maker's firmware or Android update is the only fix, because an app cannot add a codec. Ask for the update for that exact model. If none exists, keep the panel for still images: JPG and PNG slides need no video codec at all.

Decoder fine, client missing (the local MP4 plays). Three routes, cheapest first:

1. Feed files instead of a stream. Our own player is designed for this: images and H.264 MP4 from microSD or USB, no network needed, with a copy kept in internal memory so the show carries on when the card comes out. Export the loop as H.264 MP4; preparing images and video for a sign covers the settings that matter.
2. Bridge the stream. If the software on the sign has a web video widget, a small server-side box can re-wrap the RTSP feed into HLS for it; an RTSP to HLS conversion guide shows one setup. The bridge fixes the protocol only, and it cannot put a decoder back into old firmware.
3. Run a dedicated RTSP app full screen in place of the playlist. You lose the mixed layout, and startup control becomes its own job; keeping a single-purpose display on one app at power-on covers that part.

The HDMI attempt. Plugging the camera into the sign's HDMI socket fails before it starts, because that port on a signage player is an output. Why HDMI input rarely works on Android signage players has the full picture.

Door signs and lobby panels. A slide deck refreshed once a day is what these signs need in practice, and that is the job our lobby display line and offline signage player are built for.

The decision

Recommendation: Play a 1920 x 1080 H.264 MP4 from USB on the sign before anything else. If that file also fails, the firmware has no decoder, so ask the display maker for a firmware or Android update for the model, and until one exists run the sign on JPG or PNG slides; no app setting changes this outcome. If the file plays, take RTSP off the plan and load a daily H.264 MP4 loop or a slide deck on the card: on an 8-hour sign that is a 30 MB copy in place of a 14,400 MB streaming day. Reserve live streaming for content that must be current within seconds, and for that case buy the firmware update or a separate streaming-capable device, not another app.

Questions