What if “live” no longer really meant live?
In a world where a notification, a scoreboard update, or a social media comment can reach viewers within seconds, latency is no longer just a technical consideration.
It is also part of the viewing experience.
But that doesn’t mean every project needs to achieve sub-second latency.
The real question is:
how much latency does your streaming project actually need?
Latency is also part of the experience
When we talk about live streaming, it is common to assume that the lower the latency, the better the experience.
But that isn’t always the case.
The right question shouldn’t be “What’s the lowest latency we can achieve?” but rather:
How much latency does our project really need?
In certain scenarios, just a few seconds can make a significant difference. When content arrives too late, interaction decreases, spoilers can occur, and the experience no longer feels truly live.
But reducing latency isn’t as simple as pressing a button. Latency is the result of an entire streaming architecture: from signal capture and ingest to transcoding, packaging, distribution, and final playback.
That’s why choosing the right latency level is an architectural decision.
From conventional latency to near-real-time experiences
In conventional streaming, latency can reach several dozen seconds. Optimizing the architecture can significantly reduce this delay.
With low-latency HLS, it is possible to achieve around 3–5 seconds, while retaining many of the features that have made HLS one of the most widely adopted streaming protocols: compatibility, scalability, and CDN integration.
For some use cases, however, even a few seconds may be too long.
When interaction needs to happen almost in real time, we enter the realm of Under Second architectures, designed to achieve latency below one second under optimal conditions and depending on the project’s architecture.
When is low-latency HLS enough?
Not every project needs sub-second latency.
In many cases, the goal is to deliver a much more responsive live experience without sacrificing device compatibility, scalability, or integration with existing infrastructure.
This is where low-latency HLS can be an appropriate option.
HLS offers a widely adopted ecosystem, with compatibility across devices and browsers, CDN integration, and the ability to distribute content to large audiences.
Optimizing the entire workflow—from capture and ingest to packaging, CDN distribution, and playback—makes it possible to reduce latency while retaining these advantages.
Some scenarios where it can make sense:
- OTT platforms
- Broadcast
- Radio
- Corporate events
- Large audiences
- Live sports broadcasts
- Live shopping
In these cases, the priority may be to strike a balance between latency, quality, compatibility, and distribution capacity.
HLS isn’t a “worse” version of ultra-low latency.
It’s a different tool for a different need.
Conventional streaming
30 - 45s
Conventional viewing experience
For content where a delay of a few seconds does not significantly affect the experience.
Content latency is not necessarily a critical factor.
Low-latency HLS
3 - 5s
A balance between latency, compatibility, and scalability
For experiences where reducing delay matters, while maintaining a balance with compatibility and distribution.
Under a second latency
<1s
Near-real-time interaction
For experiences where immediacy is essential, such as interactive events, betting, live shopping, and remote production.
When do we really need sub-second latency?
There are projects where latency is no longer simply a matter of viewing quality. It becomes part of the functionality itself.
Imagine a live sports match.
If viewers receive the stream several seconds after a play has happened, they may find out the result before seeing it on screen. In a purely audiovisual experience, this may be an annoyance. In an interactive experience, it can directly affect participation.
The same applies whenever there is an interaction between what happens on screen and the user’s response.
These are some of the scenarios Flumotion identifies for ultra-low-latency architectures.
Sports
Bring the viewer’s experience closer to the actual moment of the event and reduce the risk of spoilers.
Remote production
Make coordination and communication easier for teams that need to work almost in real time.
Interactive events
Reduce the delay between speakers and audiences to make interaction feel more natural.
Live Shopping
Shorten the time between a product demonstration and the viewer’s response.
Auctions and transactional experiences
When synchronization between an action and a response can be especially important.
Lower latency doesn’t automatically mean a better solution
Reducing latency should never become a goal in isolation.
Every technological decision has implications.
An ultra-low-latency architecture needs to consider more than just how long it takes for a signal to reach the viewer. It must also account for:
- Playback stability
- Image quality
- Scalability
- Compatibility
- Existing infrastructure
- CDN
- Player
- The specific requirements of the project
For an Under Second architecture, for example, Flumotion designs an end-to-end solution covering everything from ingest to playback, incorporating technologies such as WebRTS when a project requires latency below one second.
That’s why the architecture should be designed around the experience we want to deliver, not the other way around.
So, what latency does your project need?
There is no single answer.
The decision depends on what the experience actually requires.
The best architecture isn’t the one that achieves the lowest latency. It’s the one that delivers the right latency for the project.
Designing the right architecture
At Flumotion, we see streaming as a complete system.
Before choosing a technology, we analyze each project’s needs: the type of content being distributed, the audience, the level of interaction, the required scale, and the experience we want to deliver.
From there, we design and integrate the most suitable architecture.
Because there is no one-size-fits-all solution in streaming.
HLS may be the right choice when the goal is to balance latency, compatibility, and scalability. In other projects, an Under Second architecture may be necessary when immediacy is an essential part of the experience.
Technology matters.
But understanding the project matters even more.
Does your project need low or ultra-low latency?
If you’re designing a new streaming project and aren’t sure what latency level you need, Flumotion can help you assess your architecture and determine which combination of technologies best fits your requirements.
The right latency depends on your project.
Let’s talk about the architecture that makes sense for your project.
