Low latency depends on where you measure it and what viewers need to do. LL-HLS and low-latency DASH are approaches for delivering video to viewers over HTTP; SRT is generally used to move a contribution feed between production and distribution points. They solve different parts of a workflow, so there is no single protocol winner for every channel.
For a 24/7 YouTube channel built around a prepared programme, a small delay is often acceptable and reliability matters more than live interaction. If you need a live question-and-answer session or synchronised participation, the boundary you care about is much tighter. Compare each stage, check that your encoder, delivery service and player all support the intended mode, and test the complete path rather than trusting a protocol label.
Define latency and the boundary you are measuring
“Latency” can refer to several different intervals. A viewer may mean the time between a camera capturing an event and the image appearing on a screen: often called glass-to-glass delay. A contribution engineer may mean transport delay between an encoder and a remote destination. A player developer may be concerned with how far playback trails the live edge. These are related measurements, but they are not interchangeable.
The full camera-to-screen path includes capture, encoding, packaging or multiplexing, transfer over one or more networks, buffering, decoding and display. A number describing just one of those steps cannot describe the whole journey. For example, an SRT buffer setting is about transport buffering, not a promise for the time from camera to viewer. Haivision’s SRT documentation explicitly defines the protocol’s latency in terms of delay introduced by sending over the network. Read Haivision’s explanation of SRT latency before comparing its setting with a viewer-side delay.
Choose the boundary before you compare options. If the goal is to keep a remote production feed steady on its way to a studio, measure the contribution link. If viewers need to see a live event close to real time, measure from capture to playback on their devices. For a prerecorded devotional or ambience loop, your practical measure may instead be whether the stream remains watchable and stable; shaving seconds off a delay viewers do not notice may not justify added compatibility work.
Published figures need the same care. Apple’s WWDC 2020 presentation described LL-HLS as capable of stream delay of two seconds or less; that is Apple’s stated capability, not a deployment-independent guarantee. Apple’s 2019 presentation described a one-to-two-second design target from live at scale over the public internet under stated conditions, including a reasonable round-trip time. Those historical statements help explain the design goal, but they are not independent benchmarks or assurances about your channel.
LL-HLS for viewer delivery
Low-Latency HLS is Apple’s extension to HLS for reducing the delay experienced by viewers while retaining an HTTP-based delivery model. The mechanism depends on media becoming available in smaller pieces before a conventional full segment has completed, alongside playlist features that let a player follow the live edge more closely. Apple documents partial media segments, playlist delta updates, blocking playlist reloads, preload hints and rendition reports as parts of the low-latency approach. Apple’s LL-HLS documentation describes the coordinated features rather than a switch that can be enabled in isolation.
That coordination is the main practical trade-off. The production and packaging side must generate the expected partial segments and playlist information; the origin and delivery path must handle the relevant requests; and the player must understand the mode. If one part of the path is not configured for the low-latency profile, Apple notes that a client may fall back to regular-latency playback. This is useful resilience, but it also means that seeing an HLS stream play does not by itself prove that it is playing with low delay.
For a viewer-facing event, LL-HLS can make sense when the ecosystem you use supports it end to end and you want HTTP delivery characteristics. It still needs testing on actual devices and networks. A phone on a congested mobile connection, a television app and a desktop browser may not behave identically. Record both the playback delay and whether the stream remains smooth when the network varies; a lower live-edge delay is not useful if it causes repeated stalls for your audience.
A steady music or sleep stream usually has little interaction that depends on seeing the programme immediately. In that case, ordinary playback stability, content continuity and predictable device compatibility may be more valuable than an LL-HLS target. If the challenge is the programme itself repeatedly cycling through too little material, see how to avoid repeating the same short clip in a sleep stream; delivery latency will not fix a short playlist.
Low-latency DASH for viewer delivery
Low-latency DASH also targets delivery to viewers over HTTP, but it uses DASH signalling and delivery practices rather than HLS playlists. The aim is to make media available to a player earlier, including through CMAF chunks and HTTP chunked transfer, with consistent signalling in the MPD (Media Presentation Description) and a client capable of acting on it. The DASH Industry Forum describes these as elements of a low-latency DASH workflow. Its overview of low-latency DASH is a useful starting point for understanding why the player, packaging and delivery path have to agree.
DASH is designed to work with existing HTTP infrastructure, including servers, CDNs, proxies and caches. That is an architectural advantage, not a guarantee that every intermediary will deliver partial media as intended. A proxy or cache configuration that waits for a complete object can defeat the purpose of early availability. Ask the delivery provider which low-latency behaviour is supported, and check how its configuration interacts with caching and the player rather than assuming that generic HTTP support is sufficient.
CMAF is often part of this discussion, but it is not itself a streaming protocol. It is a media format that can be used by both HLS and MPEG-DASH. Apple explains that HLS and a DASH MPD can reference shared CMAF media objects when packaging and delivery are compatible. Apple’s CMAF documentation makes the distinction clear: a shared media object can reduce duplicated packaging work across platforms, but the manifests and player behaviour still differ.
The practical comparison with LL-HLS is therefore not simply a contest over the lowest delay. Ask which packager, delivery service and player stack you already have, whether the devices your viewers use support it, and who will diagnose problems when the player falls behind or stalls. MPEG describes DASH as a standards suite using available HTTP infrastructure. MPEG’s DASH overview provides the standards context, but your provider’s supported profile and your own playback tests determine whether a specific low-latency deployment works.
SRT as contribution transport
SRT belongs at a different workflow stage in most comparisons. It is a transport approach for carrying a feed over IP networks, often from a remote contribution point towards a studio, gateway or distribution system. Its packet recovery and buffering are designed to cope with jitter, packet loss and changing network conditions. That makes it relevant when you need to move a production feed across a variable link; it does not, by itself, select how the eventual audience watches the stream.
The configured SRT latency is a buffer allowance for transport recovery. Haivision’s version 1.5.4 documentation, as listed on Haivision’s site in September 2026, gives a configurable range of 20–8000 ms. The appropriate value depends on the link conditions and how much recovery time you need. Haivision also gives four times round-trip time as a rule of thumb for a fairly good network with 0.1–0.2% loss and no significant burst loss. These are vendor guidance and a qualified rule of thumb, not a universal tuning formula or a camera-to-screen result. See Haivision’s SRT latency guidance.
More buffer can give packets more time to be recovered, but it adds delay at that transport boundary. Less buffer may reduce that part of the delay while leaving less room to absorb jitter or loss. You need to test the actual contribution path, including the encoder and receiver, under conditions representative of the link. If a remote camera feed arrives at a production system over SRT and is then packaged as LL-HLS for viewers, the two technologies are handling separate links in the chain.
This separation is useful when scoping equipment. A remote operator may need an encoder or gateway that supports SRT; a viewer-facing service may separately need an HLS or DASH delivery path. Check each device and service’s own documentation before buying or configuring anything. SRT support at the contribution end does not establish that the viewer player supports LL-HLS, low-latency DASH or any particular playback delay.
Match technology to interaction and workflow
Start with the human requirement, then map it to the stage that controls it. A one-way devotional stream or local news loop can usually tolerate some viewer delay. A live host responding to questions needs a more current view of chat and programme timing, but the relevant delay is still the whole route from production to the viewer. A remote correspondent feeding a studio has a separate contribution requirement. There is no reason every stage must use the same technology.
| Need | Stage to examine | Relevant approach | What to verify |
|---|---|---|---|
| Move a remote production feed across a variable IP link | Contribution transport | SRT may suit this transport role | Encoder and receiver support, link loss and jitter, buffer setting, end-to-end contribution delay |
| Deliver live video to viewers over HTTP with low-delay features | Viewer delivery | LL-HLS or low-latency DASH, depending on the ecosystem | Packaging, server/CDN behaviour, player and device support, measured playback delay |
| Share media objects across HLS and DASH workflows | Packaging and delivery | CMAF can be used with either format | Compatible packaging, manifests and delivery; do not treat CMAF as a protocol |
| Run a prepared 24/7 loop with little time-critical interaction | Whole channel workflow | Prioritise continuity and supported playback before pursuing lower delay | Restart and recovery plan, playlist duration, device playback and ordinary latency |
Use the table as a shortlist, not a procurement specification. A channel built around a prerecorded programme may need no specialist contribution transport at all. Conversely, a remote event production could use SRT upstream and an HTTP-based viewer delivery approach downstream. The question “What is the lowest latency streaming protocol?” has no useful universal answer until you specify the boundary, audience devices, network conditions and the interaction that depends on the result.
For a small channel, operational capacity belongs in the comparison. A feature that needs several systems to be configured together can be a poor fit if nobody is available to check it overnight. If your stream is primarily a scheduled loop, the more important design choice may be how you build and validate the programme schedule; testing a 24/7 playlist schedule before switching channels is relevant to that work. For a channel with a spare PC doing the encoding, consider whether its maintenance and power requirements are acceptable; running a devotional stream from a spare PC describes a different operational boundary from choosing a delivery protocol.
Plan end-to-end testing and fallbacks
Write down what you are measuring before the test. For glass-to-glass delay, use a visible clock or another repeatable event in the camera view and compare it with the viewer display, noting the devices and network used. For contribution, measure the source-to-receiver path separately. Record whether the player entered a low-latency mode, whether it fell back, and whether buffering or quality changes occurred. Repeat the test on the actual audience devices you care about rather than treating one desktop playback as representative.
Test the system in stages so a failure has a likely owner. Confirm that the encoder emits the intended output, that the packager creates the expected media and signalling, and that the origin or CDN handles requests as required. Then test a compatible player. If you use SRT upstream, test its receiver path and buffer under the kind of jitter and loss you expect. A good result at one stage does not demonstrate the behaviour of the complete chain.
Decide in advance what fallback is acceptable. Apple documents that an LL-HLS client may fall back to regular-latency playback when the server does not meet the relevant configuration profile. That can preserve viewing while increasing delay. For a scheduled channel, regular-latency playback may be a sensible fallback; for a time-critical interactive segment, it may mean the presenter needs to adjust how they respond. Document the response so a viewer delay does not become a late-night guess about whether the stream is broken.
A 24/7 channel also needs continuity planning separate from latency tuning. Check what happens if the source feed stops, an encoder restarts or the scheduled content reaches its end. A setup that runs only while a particular computer stays on has a different operational burden from one that can continue without that machine. StreamNeo removes the specific burden of keeping your own computer switched on to carry an uploaded file as a YouTube live stream, which can matter when overnight operation is the concern; it does not change the distinction between contribution transport and viewer delivery or remove the need to check your stream and content.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
What is the lowest-latency streaming protocol?
There is no universally lowest-latency choice established by the evidence here. LL-HLS and low-latency DASH address HTTP-based delivery to viewers, while SRT generally addresses contribution transport. Define the measurement boundary and interaction first, then test the relevant complete path.
What is the difference between LL-HLS and low-latency DASH?
Both are viewer-delivery approaches built around HTTP, but they use different signalling and player workflows. LL-HLS extends Apple’s HLS with features such as partial segments and playlist updates; low-latency DASH uses DASH signalling and delivery guidance, including CMAF chunks and client support. Your packager, delivery path and playback devices determine which is practical.
Can HLS and DASH use the same CMAF segments?
They can reference shared CMAF media objects when packaging and delivery are compatible, as Apple’s documentation describes. CMAF is a media format, not a protocol, and HLS playlists and a DASH MPD remain distinct signalling formats. Verify the implementation across your packager, delivery service and players.
How much latency does SRT add?
SRT’s configured latency concerns its transport buffer, not the whole camera-to-screen delay. Haivision documents a 20–8000 ms setting range for version 1.5.4, as listed on its site in September 2026, and offers a qualified rule of thumb based on round-trip time and network loss. Measure your actual link and include the rest of the production and playback chain separately.