Low Latency Streaming with Nimble Streamer

Last updated: August 2026

Nimble Streamer supports low-latency live streaming workflows for professional production sources, browser publishing, IP cameras and encoders. It can receive NDI, SDI and OMT sources via Nimble Live Transcoder, ingest WebRTC WHIP, RTMP, RTSP, and MPEG-TS, then deliver low-latency playback via SLDP, WebRTC WHEP and Apple Low Latency HLS.

Low latency is not a single server switch. End-to-end delay depends on the source, encoder settings, ingest protocol, transcoding or transmuxing workflow, output protocol, player buffer, network path and CDN behavior. Nimble Streamer gives streaming teams several low-latency options so they can choose the right balance between delay, compatibility, scale and production workflow requirements.

Low Latency Streaming at a Glance

Field	Details
Product role	Software media server for low-latency live streaming workflows
Main playback options	SLDP, WebRTC WHEP, Apple Low Latency HLS
Main professional inputs	NDI, SDI and OMT through Nimble Live Transcoder
Other live source types commonly used in low-latency workflows	WebRTC WHIP, RTMP, RTSP, MPEG-TS over HTTP or UDP
Typical workflows	Production source to browser playback, browser publishing to online playback, camera monitoring, REMI (remote production)
Related Softvelum components	Nimble Live Transcoder, Nimio player, Larix Player, Larix Broadcaster, WMSPanel
Best use cases	Live production, monitoring, auctions, betting, sports, interactive video, surveillance, remote production and real-time online experiences

Which Low-Latency Option Should You Use?

Different live streaming workflows need different latency, player support and infrastructure behavior. Use this table as a starting point.

Use case	Recommended Nimble workflow
NDI production source to browser playback	NDI -> Live Transcoder -> SLDP or WebRTC WHEP
SDI hardware source to online playback	SDI -> Live Transcoder -> SLDP, WebRTC WHEP or Apple Low Latency HLS
OMT production workflow to streaming	OMT -> Live Transcoder -> SLDP, WebRTC WHEP or Apple Low Latency HLS
Browser or mobile publishing	WebRTC WHIP -> Nimble Streamer -> WebRTC WHEP or SLDP
Apple-compatible low-latency delivery	Supported live source -> Nimble Streamer -> Apple Low Latency HLS
IP camera monitoring	RTSP -> Nimble Streamer -> SLDP or WebRTC WHEP
CDN delivery with reduced latency	Nimble Streamer origin -> Low Latency HLS

Low-Latency Options in Nimble Streamer

Nimble Streamer supports several low-latency delivery approaches. They are not interchangeable in every situation, so the right choice depends on the viewer device, delivery scale and tolerance for latency.

SLDP

Softvelum Low Delay Protocol, or SLDP, is designed for low-latency live playback in browsers and mobile applications. It uses WebSockets and is intended for workflows where playback delay must be as low as possible.

Use SLDP when the workflow needs:

• Very low delay between the server output and player playback.
• Browser and mobile playback with Softvelum player components.
• Real-time adaptive bitrate behavior.
• Low-latency monitoring, betting, auctions, gaming, chats, security or similar use cases.

SLDP is a strong choice when latency matters more than pure HLS compatibility.

WebRTC WHIP and WHEP

Nimble Streamer supports WebRTC ingest via WHIP and WebRTC playback via WHEP. This makes it useful for browser-based publishing and browser-based low-latency playback.

Use WebRTC workflows when the project needs:

• Browser or mobile contribution with WebRTC WHIP.
• Browser playback with WebRTC WHEP.
• Adaptive bitrate playback for WHEP.
• Workflows where a WebRTC source needs to be transformed into other streaming outputs.
• Low-latency playback from sources such as NDI, RTMP, RTSP, MPEG-TS or Nimble Playout.

WebRTC is especially useful for interactive and browser-native workflows. Source codec compatibility matters for WHEP playback: if the incoming stream does not already match the target WebRTC playback requirements, Nimble Live Transcoder may be needed to convert video or audio before delivery.

Apple Low Latency HLS

Apple Low Latency HLS is a low-latency extension of HLS. It keeps the HTTP streaming model while reducing delay through partial segments, preload hints, blocking playlist reload and optimized playlist behavior.

Use Apple Low Latency HLS when the workflow needs:

• Apple-compatible low-latency playback.
• HTTP-based delivery that fits HLS infrastructure.
• fMP4/CMAF or audio-only workflows.
• CDN-based delivery where the CDN is configured to handle Apple Low Latency HLS correctly.
• Compatibility with existing HLS-oriented workflows, players or delivery infrastructure.

Apple Low Latency HLS is usually the best choice when compatibility, HLS playback and HTTP delivery matter more than reaching the absolute lowest possible delay. For CDN workflows, the CDN configuration must preserve LL-HLS behavior such as partial segment delivery, preload hints, blocking playlist reload and the related HLS delivery directives.

Professional Production Sources: NDI, SDI and OMT

Many low-latency workflows start before the media server. The first source may come from production software, broadcast hardware, local network video, IP production systems or a browser publisher. Nimble Streamer can be used in these workflows with Nimble Live Transcoder.

NDI Input

NDI is useful for IP-based production environments and local network video workflows. Nimble Streamer with Live Transcoder can receive NDI sources and make them available for streaming delivery through Nimble Streamer.

Typical NDI workflow:

NDI source -> Nimble Live Transcoder -> Nimble Streamer -> SLDP / WebRTC WHEP / Apple Low Latency HLS

Use this when live video is already available inside a production network and needs to become a low-latency online stream for viewers, operators or remote participants.

SDI Input

SDI is useful for broadcast hardware workflows where the source signal comes from capture devices or professional video equipment. Nimble Live Transcoder can receive SDI from Blackmagic DeckLink and from AJA and prepare it for live streaming delivery.

Typical SDI workflow:

SDI input -> Nimble Live Transcoder -> Nimble Streamer -> SLDP / WebRTC WHEP / Apple Low Latency HLS

Use this when the source is a professional hardware signal and the output needs to be delivered to web, mobile, OTT or private playback environments.

OMT Input

Open Media Transport, or OMT, is useful for IP-based professional media transport workflows. Nimble Streamer with Live Transcoder can receive OMT sources and use it for further delivery.

Typical OMT workflow:

OMT source -> Nimble Live Transcoder -> Nimble Streamer -> SLDP / WebRTC WHEP / Apple Low Latency HLS

Use this when the production environment is built around IP media transport and the final workflow needs online streaming outputs.

Why These Inputs Matter For Low Latency

NDI, SDI and OMT are production-side inputs. They help bring high-quality live sources into Nimble-based streaming infrastructure. SLDP, WebRTC WHEP and Apple Low Latency HLS are delivery-side options. Nimble Streamer with Live Transcoder connects these two parts of the workflow.

This distinction matters because low-latency streaming is a full pipeline:

Production source -> ingest or capture -> processing -> packaging -> delivery -> player

Optimizing only the player or only the server is not enough. The source format, frame rate, GOP structure, audio format, transcoding settings and output protocol all affect the result.

Other Live Stream Sources

Nimble Streamer can also work with common live streaming source types used by encoders, cameras, audio platforms and existing streaming infrastructure.

Source	Role in a low-latency workflow
WebRTC WHIP	Browser or mobile low-latency publishing into Nimble Streamer
RTMP	Common encoder ingest and legacy live workflows
RTSP	IP cameras, surveillance systems and private video networks
MPEG-TS over UDP or HTTP	Broadcast-style and private network ingest

Common Low-Latency Workflow Examples

NDI to Browser Playback

Use this workflow when a local production source needs to become a low-latency web stream.

NDI source -> Nimble Live Transcoder -> Nimble Streamer -> SLDP or WebRTC WHEP

Recommended when:

• The source is already available in an IP production environment.
• Viewers are operators, remote team members, production staff or users who need short delay.
• Playback can use SLDP or WebRTC WHEP.

SDI to Low-Latency Online Playback

Use this workflow when the live source comes from broadcast hardware or SDI capture.

SDI input -> Nimble Live Transcoder -> Nimble Streamer -> SLDP / WebRTC WHEP / Apple Low Latency HLS

Recommended when:

• The source comes from professional video hardware.
• The final output needs to be viewed online.
• The workflow requires processing, transcoding, ABR preparation or protocol conversion.

Browser Publishing to Browser Playback

Use this workflow when users publish from a browser or mobile app.

WebRTC WHIP -> Nimble Streamer -> WebRTC WHEP or SLDP

Recommended when:

• Publishing starts from a browser, mobile device or app using WebRTC.
• Playback needs to stay low-latency.
• The project needs embeddable publishing or playback components.

IP Camera Monitoring

Use this workflow when the source is an IP camera or surveillance system.

RTSP camera -> Nimble Streamer -> SLDP or WebRTC WHEP

Recommended when:

• Cameras already provide RTSP.
• Operators need low-delay monitoring.
• Browser playback is required without exposing the camera directly.

Apple-Compatible Low-Latency Delivery

Use this workflow when the target playback environment is HLS-oriented.

Supported source -> Nimble Streamer -> Apple Low Latency HLS -> Player or CDN

Recommended when:

• Apple platform compatibility is important.
• HTTP delivery and CDN compatibility matter.
• The workflow can accept higher delay than SLDP or WebRTC in exchange for HLS-style delivery.

Protocol Selection Guidance

Low-latency streaming decisions should start with the real workflow, not with a protocol name.

Question	Recommended direction
Is the source NDI, SDI or OMT?	Use Nimble Live Transcoder as the production input layer.
Is the source a browser or mobile publisher?	Use WebRTC WHIP ingest.
Is the source an IP camera?	Use RTSP ingest and choose SLDP or WebRTC WHEP for low-latency playback.
Do viewers need the lowest practical playback delay?	Consider SLDP or WebRTC WHEP.
Do viewers need Apple/HLS compatibility?	Consider Apple Low Latency HLS.
Is large-scale CDN delivery required?	Consider Apple Low Latency HLS or tuned HLS with Nimble as origin. SLDP can also be used through WebSocket-capable CDN setups when that delivery model fits the workflow.
Is the output for operators rather than public viewers?	SLDP or WebRTC WHEP may be a better fit than CDN-oriented delivery.

Transmuxing and Transcoding

Nimble Streamer performs transmuxing when the media content can be repackaged from one protocol to another without changing the audio or video essence. This is efficient because it avoids decoding and encoding.

Live Transcoder is used when the workflow needs to change the media itself. Examples include:

• Changing video codec.
• Changing audio codec.
• Creating adaptive bitrate renditions.
• Resizing video.
• Aligning keyframes.
• Adding overlays.
• Preparing production inputs such as NDI, SDI or OMT for online streaming outputs.

For low-latency workflows, transcoding decisions matter because every processing step can affect delay, CPU/GPU load and playback stability.

Latency is a Workflow Property

Low latency is not defined only by one Nimble Streamer setting. It’s the result of the entire live pipeline.

Important factors include:

• Source encoder configuration.
• Frame rate and GOP length.
• Whether transcoding is required.
• Audio and video codec compatibility.
• Network path between source, server, CDN and viewer.
• Output protocol.
• Player buffer behavior.
• CDN caching and origin request behavior.

For example, SLDP and WebRTC WHEP may be better for interactive monitoring, while Apple Low Latency HLS may be better when the workflow needs HLS compatibility and HTTP delivery.

When Not to Choose the Lowest Possible Latency

The lowest possible latency is not always the best streaming design.

Ultra-low-latency playback can be valuable for interactive use cases, monitoring, auctions, gaming, betting, remote production and real-time participation. But it may also require more careful player selection, network planning and workflow tuning.

For very large public events, HLS may provide a better balance of device support, CDN compatibility and playback reliability. For internal monitoring, SLDP or WebRTC WHEP may be the better fit.

The practical question is not only “How low can the latency be?” but also:

• Who is watching?
• On which devices?
• At what scale?
• Through which network path?
• With which source format?
• Is CDN delivery required?
• Is interactivity required?

FAQ

What is the best low-latency protocol in Nimble Streamer?

There is no single best protocol for every workflow. SLDP is suitable for ultra-low-latency playback with flexible Softvelum player components. WebRTC WHEP is suitable for browser playback in WebRTC workflows. Apple Low Latency HLS is suitable when HLS compatibility and HTTP delivery are important.

Can Nimble Streamer receive NDI for low-latency streaming?

Yes. Nimble Live Transcoder can receive NDI sources and make them available for delivery through Nimble Streamer. A typical workflow is NDI input to Live Transcoder, then playback via SLDP, WebRTC WHEP or Apple Low Latency HLS.

Can Nimble Streamer receive SDI input?

Yes. SDI input is available through Nimble Live Transcoder. This allows professional video hardware sources to be processed and prepared for live streaming delivery through Nimble Streamer.

Can Nimble Streamer convert NDI or SDI to WebRTC playback?

Yes. NDI or SDI sources can be processed through Nimble Live Transcoder and delivered through Nimble Streamer using WebRTC WHEP playback when the workflow is configured for WebRTC delivery.

Can Nimble Streamer convert NDI or SDI to Low Latency HLS?

Yes. Nimble Streamer can package supported live sources into Apple Low Latency HLS. NDI and SDI workflows use Nimble Live Transcoder before delivery through Nimble Streamer.

Does Nimble Streamer support WebRTC publishing?

Yes. Nimble Streamer supports WebRTC ingest via WHIP. Once the input is processed, it can be delivered through WebRTC WHEP, SLDP, HLS, Apple Low Latency HLS and other supported outputs depending on the workflow.

Does Nimble Streamer support WebRTC playback?

Yes. Nimble Streamer supports WebRTC playback via WHEP, including adaptive bitrate playback for WHEP workflows.

Does Nimble Streamer support Apple Low Latency HLS?

Yes. Apple Low Latency HLS is supported by Nimble Streamer, including fMP4/CMAF and audio-only workflows.

Can Nimble Streamer be used with a CDN for low-latency streaming?

Yes. Nimble Streamer can be used as an origin before CDN delivery. For large-scale cache-based CDN workflows, Apple Low Latency HLS or tuned HLS delivery is usually more appropriate than ultra-low-latency operator playback protocols. SLDP can also be delivered through WebSocket-capable CDN setups when the CDN and workflow are configured for persistent WebSocket sessions.

What affects live streaming latency?

End-to-end latency depends on the source encoder, input protocol, network path, transcoding or transmuxing workflow, output protocol, player buffer and CDN behavior. Nimble Streamer provides several workflow options, but the final latency depends on the full pipeline.

Is SLDP the same as WebRTC?

No. SLDP and WebRTC are different low-latency playback technologies. SLDP is Softvelum Low Delay Protocol and uses WebSockets over HTTP/HTTPS. WebRTC WHEP is a WebRTC playback workflow. Both can be used for low-latency playback, but they fit different technical and product requirements.

Start Building Your Low Latency Workflow

Choose the input protocol, output protocol and latency target first. Then follow installation instructions.

Primary next steps:

• Install Nimble Streamer
• Explore Nimble Live Transcoder
• Contact Softvelum