In some deployments, RTSP (Real-Time Streaming Protocol) streams on BrightSign players may exhibit higher latency than expected, even when the network connection is stable. This behavior is typically not caused by bandwidth limitations or stream configuration, but by the default buffering behavior of BrightSignOS.
By default, BrightSignOS prioritizes smooth playback by buffering incoming audio and video data before playback begins. While this helps prevent stuttering caused by network jitter, it also increases the delay between the live source and what is displayed on the screen.
For latency-sensitive applications, such as live camera monitoring or real-time event displays, you can adjust the buffering parameters to reduce this delay.
How It Works
BrightSignOS uses internal audio and video buffers to compensate for network jitter—the natural variation in packet arrival times.
By default, the player uses:
Latency: 0 ms (no latency reduction)
Jitter: 300 ms
This configuration provides the best playback stability by allowing the buffers to fill before playback starts. However, it also introduces additional delay between the live source and the displayed content.
To reduce latency, you can append playback parameters directly to the RTSP stream URL.
The available parameters are:
latency — Specifies the latency offset (in milliseconds) from the default configuration. Positive values reduce playback latency, while 0 preserves the default behavior.
jitter — Defines the size of the jitter buffer (in milliseconds).
buffersize, vcdbsize, acdbsize — Configure the size of the main, video, and audio buffers (in bytes). These settings are typically used together with more aggressive latency values to fine-tune playback performance.
Note: Reducing the jitter buffer lowers playback latency but also decreases the player's ability to compensate for network fluctuations. On unstable networks, overly aggressive settings may result in dropped frames or playback stuttering. Choose values that provide the best balance between responsiveness and playback stability for your environment.
Configuration
- On the Content page, click New and select App.
- In the App Gallery, open the Web & Media category and select Streaming Video Link. This app supports both RTSP and HLS streams.
- In the URL field, enter the stream URL and append the desired latency parameters. For example:
rtsp://<your-ip>:8554/live?latency=450&jitter=50 - (Optional) Configure the Check Interval field to control how often the app verifies that the stream is still active. Increase this value for slower streams, or set it to 0 to disable the check.
- Save the app and publish it to the player.
- Monitor playback for a period of time before validating the new settings. Field testing is recommended before deploying the same configuration to multiple players.
- If additional latency is required—for example, on slower or less stable networks—increase the latency value and, if necessary, adjust the buffersize, vcdbsize, and acdbsize parameters in the stream URL.
Platform Compatibility
This configuration is exclusive to BrightSign players and is supported only on devices running BrightSignOS 6.2.147 or later.
Android, Windows, and other supported platforms do not recognize these URL parameters because they use different streaming engines.
Troubleshooting
-
The stream still has high latency after the adjustment: The configured latency value may be too close to the default. Increase the value (for example, from
250to450, the minimum value recommended by BrightSign for latency reduction) and test again. - Playback begins to stutter after reducing latency: The configured jitter or buffer values are too low for the stream bitrate or network conditions. Increase the jitter value or use larger buffer sizes to improve playback stability.
- The latency parameters have no effect: Verify that the player is running BrightSignOS 6.2.147 or later. Earlier versions do not support these RTSP URL parameters.
- Only one player exhibits high latency while others do not: The issue is likely related to that player's local network or hardware rather than the stream configuration. Test the same stream URL on another player connected to the same network before modifying the parameters across your deployment.