Last updated: August 2026
Nimble Streamer supports a wide range of streaming protocols for ingest, processing and delivery. It can receive SRT, RTMP, RTSP, MPEG-TS, WebRTC WHIP, NDI, SDI, OMT, Zixi, RIST, HLS pull, Icecast and SHOUTcast sources, then output HLS, Low Latency HLS, MPEG-DASH, WebRTC WHEP, SRT, RTMP, RTSP, MPEG-TS, NDI, SDI, OMT, Zixi, RIST, SLDP and Icecast workflows.
This page is a high-level protocol matrix for the latest version of Nimble Streamer. Use it to identify which protocols can be used for contribution, live ingest, playback, CDN delivery, low-latency streaming, broadcast hardware workflows, production routing and audio streaming.
For a broader product overview, see What Is Nimble Streamer? and Nimble Streamer live streaming reference.
Protocol Support at a Glance
| Protocol / format | Input | Output | Typical use | Related page |
|---|---|---|---|---|
| SRT | Yes | Yes | Reliable contribution, transport and distribution | SRT in Nimble Streamer |
| RTMP / RTMPS | Yes | Yes | Encoder ingest, playback and re-publishing | RTMP in Nimble Streamer |
| SLDP | No | Yes | Softvelum low-latency playback | SLDP in Nimble Streamer |
| RTSP | Yes | Yes | IP cameras, pulled sources, announced streams and playback | RTSP support |
| MPEG-TS | Yes | Yes | Broadcast transport over HTTP, UDP, TCP, RTP and related workflows with SRT, RIST, and Zixi | MPEG-TS streaming |
| WebRTC WHIP | Yes | No | Browser, mobile and WebRTC publisher ingest | WebRTC in Nimble Streamer |
| WebRTC WHEP | No | Yes | Low-latency browser playback | WebRTC in Nimble Streamer |
| HLS | Pulled input | Yes | Broadcast live/VOD playback and CDN delivery | HLS support |
| Low Latency HLS | No | Yes | Apple and CDN-friendly low-latency delivery | Low Latency HLS |
| MPEG-DASH | No | Yes | OTT live and VOD playback | MPEG-DASH support |
| NDI | Yes | Yes | IP production workflows | Nimble Streamer NDI support |
| SDI | Yes | Yes | Broadcast hardware input and output workflows | Nimble Streamer SDI support |
| OMT | Yes | Yes | Open Media Transport production workflows | OMT support |
| Zixi | Yes | Yes | Managed contribution and transport workflows | Zixi at Softvelum |
| RIST | Yes | Yes | Reliable Internet Stream Transport workflows | RIST in Nimble Streamer |
| Icecast | Yes | Yes | Audio streaming workflows | Icecast and audio streaming |
Which Protocol Should You Choose?
| Need | Recommended protocol or workflow |
|---|---|
| Reliable contribution over public or unstable networks | SRT, RIST |
| Browser playback with very low latency | WebRTC WHEP |
| Browser or mobile WebRTC publishing | WebRTC WHIP |
| Apple-compatible low-latency HTTP delivery | Low Latency HLS |
| Large-scale CDN playback | HLS or MPEG-DASH |
| OTT playback with DRM workflows | MPEG-DASH and/or HLS depending on device requirements |
| Broadcast hardware ingest or output | SDI |
| Studio/IP production routing | NDI, SDI or OMT depending on infrastructure |
| IP camera ingest | RTSP; RTMP(S) only if supported by the camera/encoder |
| Legacy encoder ingest or re-publishing | RTMP(S) |
| Broadcast transport over UDP/TCP/RTP | MPEG-TS |
| Audio-only streaming | Icecast, SHOUTcast, HLS, SLDP or WebRTC WHEP depending on latency and player requirements |
| Softvelum ultra-low-latency playback | SLDP |
| Managed contribution with error correction | Zixi, RIST or SRT depending on the environment |
Input Protocols
Nimble Streamer can receive live sources from encoders, mobile apps, IP cameras, broadcast hardware, production systems, audio servers and other media servers. The exact configuration depends on protocol, mode, codec, network topology and whether Live Transcoder is required.
SRT Input
SRT input is used for reliable contribution from encoders, mobile live streaming apps, remote production systems and other servers. Nimble Streamer supports SRT workflows such as Listen, Pull and Rendezvous modes.
Common SRT input workflows:
- Larix Broadcaster -> SRT -> Nimble Streamer;
- hardware encoder -> SRT -> Nimble Streamer;
- remote server -> SRT -> Nimble Streamer;
- SRT input -> HLS or MPEG-DASH delivery;
- SRT input -> WebRTC WHEP playback;
- SRT input -> MPEG-TS, RTMP or another output protocol.
Related pages:
RTMP Input
RTMP is commonly used for encoder ingest, legacy workflows, re-publishing and compatibility with existing live streaming tools. Nimble Streamer can receive published or pulled RTMP/RTMPS streams and process them for delivery through other protocols. Nimble Streamer support s Enhanced RTMP spec which allows delivering more codecs than its original version.
Common RTMP workflows:
- RTMP encoder -> Nimble Streamer -> HLS;
- RTMP encoder -> Nimble Streamer -> MPEG-DASH;
- RTMP encoder -> Nimble Streamer -> WebRTC WHEP;
- RTMP source -> Nimble Streamer -> RTMP re-publish;
- Enhanced RTMP codec workflows with various codecs.
Related page: RTMP in Nimble Streamer
RTSP Input
RTSP is often used for IP cameras, surveillance sources and network video devices. Nimble Streamer can pull or get the pushed RTSP streams and convert them into formats suitable for web playback, CDN delivery or downstream processing.
Common RTSP workflows:
- IP camera -> RTSP -> Nimble Streamer -> HLS;
- IP camera -> RTSP -> Nimble Streamer -> WebRTC WHEP;
- RTSP source -> Nimble Streamer -> SRT output;
- RTSP source -> Nimble Streamer -> DVR recording.
Related page: RTSP support
MPEG-TS Input
MPEG-TS is used in broadcast and transport workflows. Nimble Streamer supports MPEG-TS input over HTTP and UDP streams, with metadata passthrough such as KLV and captions supported in relevant workflows.
Common MPEG-TS workflows:
- MPEG-TS UDP input -> Nimble Streamer -> HLS;
- MPEG-TS input -> Nimble Streamer -> DASH;
- MPEG-TS input -> Nimble Streamer -> SRT output;
- MPEG-TS input with KLV or captions -> Nimble Streamer -> downstream delivery.
Related page: MPEG-TS streaming
WebRTC WHIP Input
WHIP is used for WebRTC ingest. Nimble Streamer can receive WebRTC streams from compatible publishers and process them for low-latency playback, recording, repackaging or conversion to other delivery protocols.
Common WHIP workflows:
- browser publisher -> WHIP -> Nimble Streamer -> WHEP playback;
- mobile WebRTC publisher -> WHIP -> Nimble Streamer -> HLS/DASH recording workflow;
- WHIP ingest -> Nimble Streamer -> CDN-compatible output.
Related pages:
NDI Input
NDI input is used in production workflows where video sources move through IP-based studio infrastructure. Nimble Streamer can use NDI via Live Transcoder.
Common NDI workflows:
- NDI source -> Nimble Streamer -> WebRTC WHEP;
- NDI source -> Nimble Streamer -> HLS or DASH;
- NDI source -> Nimble Streamer -> SRT output;
- NDI source -> Nimble Streamer -> SDI output.
Related pages:
SDI Input
SDI input connects broadcast hardware workflows with IP streaming. Nimble Streamer supports SDI through Live Transcoder, including DeckLink and AJA device workflows described in Softvelum’s current SDI documentation and posts.
Common SDI workflows:
- SDI input -> Nimble Streamer -> WebRTC WHEP;
- SDI input -> Nimble Streamer -> SRT output;
- SDI input -> Nimble Streamer -> HLS or MPEG-DASH;
- SDI input -> Nimble Streamer -> NDI output;
- SDI input with embedded audio and captions -> Nimble Streamer -> downstream delivery.
Related pages:
OMT Input
Open Media Transport can be used in production workflows where compatible systems exchange media using OMT. Nimble Streamer supports OMT via Live Transcoder.
Related page: OMT support in Nimble Streamer
Zixi Input
Zixi is a reliable transport protocol used in contribution and managed transport workflows. Nimble Streamer provides integration with Zixi Broadcaster in order to create a bridge between the Zixi protocol and all the technologies that are supported by the Nimble Streamer live streaming feature stack.
Related pages:
HLS Pull Input
Nimble Streamer can use HLS as a pulled live source. This is useful when an upstream system provides HLS and Nimble Streamer needs to process, repackage, restream or deliver it through other workflows. Notice that ABR is not supported. Read details here: Pulling HLS streams.
RIST Input
Nimble Streamer can take RIST as input. It’s used for production transport and reliable contribution/distribution workflows.
Related pages:
Icecast and SHOUTcast Input
Icecast and SHOUTcast input is used for audio streaming workflows. Nimble Streamer can receive audio streams and deliver them through supported output workflows, including audio streaming and low-latency playback scenarios. Notice that Nimble Streamer uses an application/stream naming model rather than the Icecast mount point concept.
Related page: Icecast and audio streaming
Output Protocols
Nimble Streamer can output streams to players, CDNs, downstream media servers, broadcast systems and production environments. Output selection depends on playback requirements, latency target, device support, CDN strategy, monetization needs and whether transcoding is required.
HLS Output
HLS is used for broad live and VOD playback compatibility. Nimble Streamer supports HLS output for live and on-demand workflows, including ABR, fMP4, audio-only and MPEG-TS container workflows. Nimble Streamer can deliver HLS over HTTP/1.x, HTTP/2 and HTTP/3. Nimble DVR delivers content for playback via HLS and DASH.
Use HLS when:
- broad device compatibility matters;
- CDN delivery is required;
- live and VOD workflows need standard HTTP playback;
- DRM, DVR, SSAI or subtitles are part of the workflow;
- Cache-aware re-streaming is supported.
Related page: HLS support, HTTP re-streaming
Low Latency HLS Output
Low Latency HLS is used when teams need lower latency while keeping Apple and CDN-friendly HTTP delivery. Nimble Streamer supports LL-HLS for fMP4/CMAF and audio-only workflows.
Use LL-HLS when:
- Apple ecosystem playback matters;
- CDN delivery is required;
- latency needs to be lower than standard HLS;
- WebRTC is not the best fit for the audience size or distribution model.
Related page: Low Latency HLS with Softvelum
SLDP Low Latency Output
SLDP is Softvelum’s low-latency playback protocol based on WebSockets.
Basic features are:
- Nearly one second delay between origin and player.
- Codec-agnostic. Play whatever your end-user platform has: H.264, H.265/HEVC, AV1, VP8, VP9, video, AAC, MP3, Opus, FLAC audio.
- ABR real-time support. Switching channels takes just a GOP time and each channel may use its own codec.
- Simultaneous synchronized playback among multiple browsers and mobile devices.
- CEA-608/708 closed captions are supported with HTML5 Player SDK.
- Buffer offset support for decreasing zap time (start latency).
- Latency tolerance support to handle network glitches.
SLDP brings flexibility combined with versatility and low latency.
We also provide Nimio player for embedding into your website and mobile players for iOS and Android.
Related pages:
- SLDP in Nimble Streamer
- SLDP in Softvelum products
- Nimio player
- Low Latency Streaming in Nimble Streamer
MPEG-DASH Output
MPEG-DASH is used for OTT playback, ABR delivery and DRM workflows. Nimble Streamer supports MPEG-DASH output for live and VOD workflows. Nimble Streamer can deliver MPEG-DASH over HTTP/1.x, HTTP/2 and HTTP/3. Nimble DVR delivers content for playback via HLS and DASH.
Use MPEG-DASH when:
- OTT playback workflows require DASH;
- Widevine or PlayReady DRM workflows are needed;
- ABR delivery is required;
- Playback environment supports DASH;
- Cache-aware re-streaming is supported.
Related page: MPEG-DASH support, HTTP re-streaming
WebRTC WHEP Output
WHEP is used for WebRTC playback. Nimble Streamer can output WHEP playback for compatible clients, including low-latency browser playback workflows and adaptive WHEP workflows.
Use WHEP when:
- browser playback latency is critical;
- you need WebRTC last-mile delivery;
- sources come from SRT, RTMP, RTSP, MPEG-TS, NDI, Icecast or WHIP workflows;
- the target devices and browsers support the required codec path.
Related page: WebRTC in Nimble Streamer
SRT Output
SRT output is used for server-to-server transport, reliable distribution and delivery to SRT-compatible receivers. Nimble Streamer supports SRT output modes such as Push, Listen and Rendezvous.
Use SRT output when:
- a downstream system expects SRT;
- you need reliable transport over unstable networks;
- you are connecting contribution, production or delivery systems;
- you need to move streams between Nimble instances or partner endpoints.
Related page: SRT in Nimble Streamer
RTMP / RTMPS Output
RTMP and RTMPS output can be used for re-publishing, playback and compatibility with legacy or external platforms. RTMP remains useful where downstream systems still expect RTMP. Enhanced RTMP spec is supported for delivering various codecs.
Use RTMP output when:
- re-publishing to another RTMP endpoint;
- streaming to platforms that accept RTMP;
- supporting legacy playback or workflow requirements.
Related page: RTMP in Nimble Streamer
RTSP Output
RTSP output is useful for workflows where downstream systems, devices or applications expect RTSP playback or re-publishing.
Related page: RTSP support
MPEG-TS Output
Nimble Streamer supports MPEG-TS output in multiple forms, including UDP, TCP, RTP and related transport modes. MPEG-TS is commonly used in broadcast, contribution and internal transport workflows. Nimble Streamer can deliver HTTP MPEG-TS over HTTP/1.x, HTTP/2 and HTTP/3.
Related page: MPEG-TS streaming
NDI Output
NDI output is used when Nimble Streamer needs to send streams into IP production environments. This is useful for studio, REMI and production workflows where NDI is part of the routing layer.
Related page: Nimble Streamer NDI support
SDI Output
SDI output is used when Nimble Streamer sends a processed live stream back to broadcast hardware. SDI output is useful for studio output, monitoring, playout-to-hardware workflows and IP-to-SDI bridge scenarios.
Related page: Nimble Streamer SDI support
OMT Output
OMT output is used when Nimble Streamer needs to send streams into IP production environments. This is useful for studio, REMI and production workflows where OMT is part of the routing layer.
Related page: OMT support
Icecast Output
Icecast output is used for audio streaming workflows. Nimble Streamer can deliver Icecast over HTTP/1.x, HTTP/2 and HTTP/3.
Related page: Icecast and audio streaming
RIST Output
Nimble Streamer can output RIST. It’s used for production transport and reliable contribution/distribution workflows depending on the receiving system.
Related pages:
Zixi Output
Nimble Streamer can output Zixi. It’s used for reliable contribution workflows.
Related pages:
Protocol Conversion Workflows
One of Nimble Streamer’s main roles is to bridge protocols. It can receive one protocol and deliver another, either by transmuxing compatible media or by using Nimble Live Transcoder when media conversion is required.
Transmuxing vs Transcoding
Transmuxing changes the streaming protocol or container without changing the compressed video or audio codec. This is efficient because the media does not need to be decoded and encoded again.
Transcoding changes the media itself, such as codec, bitrate, resolution, frame rate, pixel format, audio format or channel layout. Nimble Live Transcoder is required when the output workflow needs codec conversion, ABR ladders, scaling, overlays, filters, audio conversion, SDI, NDI or OMT processing or other media transformation.
| Situation | Transcoder needed? |
|---|---|
| Repackage compatible video/audio into another protocol | No |
| Playback platform does not support the source codec | Yes |
| Need ABR ladder | Yes |
| Need resolution or frame rate conversion | Yes |
| Need audio codec or channel layout conversion | Yes |
| Need SDI, NDI or OMT processing | Yes |
| Need overlays, filters or picture-in-picture | Yes |
Related page: Nimble Live Transcoder
Protocol Groups by Use Case
Reliable Contribution and Transport
Use these when the priority is moving a live stream between locations or systems:
- SRT;
- RIST;
- Zixi;
- MPEG-TS UDP;
- RTMP / RTMPS where legacy compatibility is required.
Low-Latency Playback
Use these when viewer latency matters:
- WebRTC WHEP for browser-based low-latency playback;
- SLDP for Softvelum low-latency playback workflows;
- Low Latency HLS for Apple and CDN-friendly low-latency delivery;
- SRT for transport, not direct browser playback.
Related page: Low Latency Streaming in Nimble Streamer
CDN and OTT Delivery
Use these when the stream needs to be delivered through HTTP/CDN infrastructure:
- HLS;
- Low Latency HLS;
- MPEG-DASH;
- HTTP/2 and HTTP/3 delivery where supported;
- CDN-friendly HLS/DASH origin workflows.
Related page: Nimble Streamer as a CDN Origin
Broadcast and Production
Use these when Nimble Streamer connects with studio, broadcast or production infrastructure:
- SDI;
- NDI;
- OMT;
- SRT;
- MPEG-TS;
- Zixi.
Audio Streaming
Use these for online radio, music, audio-only live streams and speech workflows:
- Icecast;
- HLS audio-only;
- SLDP audio;
- WebRTC WHEP audio;
- RTMP or MPEG-TS audio workflows.
Codec Considerations
Protocol support and codec support are related but not identical. A protocol can be supported while a specific codec still depends on player, browser, hardware, operating system, container, or transcoding settings.
Protocol support answers how the stream moves. Codec support answers whether the video and audio inside that stream can be passed through, played, repackaged or transcoded for the target workflow.
For codec planning, use the dedicated codec resources:
Related Nimble Streamer Resources
- What Is Nimble Streamer?
- Nimble Streamer
- Nimble Streamer as a CDN Origin
- Nimble Streamer live streaming reference
- Nimble Live Transcoder
- Nimble Streamer configuration and control
FAQ
Which protocols does Nimble Streamer support?
Nimble Streamer supports many live and VOD streaming protocols, including SRT, RTMP, RTSP, MPEG-TS, HLS, Low Latency HLS, MPEG-DASH, WebRTC WHIP/WHEP, NDI, SDI, OMT, Zixi, RIST, SLDP and Icecast workflows.
Does Nimble Streamer support SRT input and output?
Yes. Nimble Streamer supports SRT input and output for contribution, reliable transport and server-to-server workflows. SRT sources can also be converted to HLS, Low Latency HLS, MPEG-DASH, WebRTC WHEP, RTMP, MPEG-TS and other supported outputs, depending on codec/container compatibility; transcoding may be required.
Does Nimble Streamer support WebRTC WHIP and WHEP?
Yes. Nimble Streamer supports WebRTC WHIP ingest and WebRTC WHEP playback. WHIP is used for WebRTC publishing into Nimble Streamer, while WHEP is used for low-latency WebRTC playback.
Can Nimble Streamer convert SRT to WebRTC WHEP?
Yes. Nimble Streamer can receive SRT input and deliver WebRTC WHEP playback where the workflow, codecs and player requirements are configured correctly. Nimble Live Transcoder may be required if codec or audio conversion is needed.
Can Nimble Streamer convert RTSP to HLS or WebRTC?
Yes. Nimble Streamer can receive RTSP sources, such as IP cameras, and deliver them through HLS, MPEG-DASH, WebRTC WHEP, SRT or other outputs. Transcoding may be required depending on codec and playback requirements.
Does Nimble Streamer support Low Latency HLS?
Yes. Nimble Streamer supports Apple Low Latency HLS for fMP4/CMAF and audio-only workflows. LL-HLS is useful when teams need lower latency while keeping HTTP/CDN-friendly delivery.
Does Nimble Streamer support SDI and NDI?
Yes. Nimble Streamer supports SDI and NDI workflows through Nimble Live Transcoder. These workflows connect broadcast hardware and IP production systems with streaming outputs such as SRT, WebRTC WHEP, HLS, MPEG-DASH, NDI and SDI.
Does Nimble Streamer support MPEG-DASH?
Yes. Nimble Streamer supports MPEG-DASH output for live and VOD workflows. DASH is often used in OTT playback and DRM workflows.
Does Nimble Streamer support Icecast?
Yes. Nimble Streamer supports Icecast and SHOUTcast workflows for audio streaming. Icecast can be used as input and delivered as output, including HTTP/1.x, HTTP/2 and HTTP/3 delivery.
When do I need Nimble Live Transcoder?
You need Nimble Live Transcoder when the workflow requires codec conversion, bitrate ladder generation, scaling, frame rate conversion, audio conversion, filters, overlays, picture-in-picture, SDI, NDI or OMT processing or other media transformation. If the workflow only changes the protocol or container while preserving compatible codecs, transmuxing may be enough.
Start Building Your Protocol Workflow
Choose the input protocol, output protocol and latency target first. Then confirm codec compatibility, player requirements, CDN strategy and whether Live Transcoder is needed.
Primary next steps: