Post edited to:<\/p>\n\n\n\n
For years people kept saying the same thing about Apple HLS streaming: \u201cgreat quality, terrible latency.\u201d<\/p>\n\n\n\n
And honestly, they were right.<\/p>\n\n\n\n
Traditional HLS setups could easily introduce 30, 60, sometimes even 90 seconds of delay between the broadcaster and the viewer. For sports, auctions, interactive streaming, gambling, live chat, or even nightlife streaming, that delay becomes a serious problem.<\/p>\n\n\n\n
Years ago I started experimenting with Wowza Streaming Engine to see how far I could push HLS latency without completely sacrificing stability. Back then, around 2019, getting HLS down to 3 to 5 seconds already felt almost magical.<\/p>\n\n\n\n
Now in 2026, after testing again on modern Wowza servers, I can confirm something important:<\/p>\n\n\n\n
HLS is still alive, still extremely compatible, and still one of the most stable streaming methods available. But the default Wowza settings are still very conservative and optimized for stability rather than speed.<\/p>\n\n\n\n
Out of the box, Wowza often uses 10-second chunks. That immediately creates large delays because the player waits for several chunks before playback begins.<\/p>\n\n\n\n
The good news is that this can still be dramatically improved.<\/p>\n\n\n\n
On one of our recent tests we reduced chunk duration from 10 seconds to 2 seconds, and the difference was immediately visible. Latency dropped massively while playback remained surprisingly stable.<\/p>\n\n\n\n
The interesting part is that modern servers, CPUs, and bandwidth are now much better than they were years ago. What was considered \u201caggressive\u201d low latency tuning in 2019 is much easier to handle today.<\/p>\n\n\n\n
Still, there are trade-offs.<\/p>\n\n\n\n
Smaller chunks increase server activity. The server has to create many more segments, update playlists more frequently, and handle more requests from players. CPU usage rises. Cache pressure increases. Weak servers may begin struggling. Poor internet connections may cause playback interruptions.<\/p>\n\n\n\n
This is why low latency streaming is always a balancing act between speed and stability.<\/p>\n\n\n\n
The settings we tested recently on Wowza Streaming Engine were:<\/p>\n\n\n\n
These values are much more aggressive than the Wowza defaults.<\/p>\n\n\n\n
The most important change is reducing:<\/p>\n\n\n\n
cupertinoChunkDurationTarget<\/code><\/pre>\n\n\n\nfrom:<\/p>\n\n\n\n
10000<\/code><\/pre>\n\n\n\nto:<\/p>\n\n\n\n
2000<\/code><\/pre>\n\n\n\nThis changes segment duration from 10 seconds down to roughly 2 seconds.<\/p>\n\n\n\n
After adjusting the normal Cupertino settings inside the \u201cCupertino Streaming Packetizer\u201d section, there is one additional setting that is not visible by default in Wowza. This setting must be added manually as a custom property.<\/p>\n\n\n\n
To do this, open Wowza Streaming Engine Manager, go to Applications ? live ? Properties, and then click \u201cCustom\u201d in the Quick Links section. Click Edit, then Add Custom Property. In the Path field, select or enter:<\/p>\n\n\n\n
\/Root\/Application\/LiveStreamPacketizer<\/code><\/pre>\n\n\n\nThen create the property using these values:<\/p>\n\n\n\n
Name: cupertinoMinPlaylistChunkCount
Type: Integer
Value: 3<\/code><\/pre>\n\n\n\nThis setting controls the minimum number of chunks Wowza waits for before sending the playlist to the player. Lower values help reduce latency because the player receives the playlist earlier instead of waiting for too many chunks to accumulate first. After saving the property, restart the live application so the new low-latency settings become active.<\/p>\n\n\n\n
Immediately after applying the settings and restarting the live application, the logs confirmed the improvement. Instead of generating 10-second chunks, Wowza started producing chunks around 2 seconds:<\/p>\n\n\n\n
duration:1967
duration:2066
duration:2000
duration:2634<\/code><\/pre>\n\n\n\nThat is exactly what we wanted.<\/p>\n\n\n\n
One important thing I learned again during these tests is that WebRTC still sounds wonderful in theory, but in practice it can become frustrating very quickly depending on browsers, codecs, firewalls, proxies, and SSL setups.<\/p>\n\n\n\n
We experimented heavily with Wowza WebRTC playback. UDP traffic was flowing correctly, ICE candidates were being exchanged properly, and the server was clearly attempting to establish sessions. Yet playback remained unstable and inconsistent.<\/p>\n\n\n\n
Meanwhile, properly optimized low-latency HLS worked almost immediately and far more reliably.<\/p>\n\n\n\n
That is why I still believe optimized HLS remains the best compromise between compatibility, stability, scalability, and latency for most commercial streaming deployments.<\/p>\n\n\n\n
Another important lesson was Nginx proxy behavior.<\/p>\n\n\n\n
During testing we discovered HTTPS playback instability caused by proxy behavior between Nginx and Wowza. Disabling proxy buffering helped significantly:<\/p>\n\n\n\n
proxy_buffering off;
proxy_read_timeout 60s;<\/code><\/pre>\n\n\n\nWithout this adjustment, playback through HTTPS sometimes produced delays, interruptions, or 502 gateway errors.<\/p>\n\n\n\n
This is something many administrators forget when placing Nginx in front of Wowza.<\/p>\n\n\n\n
Of course, none of this magically creates \u201cinstant\u201d streaming. Physics and buffering still exist. But with proper tuning, modern HLS latency can become surprisingly usable.<\/p>\n\n\n\n
In our tests, practical latency dropped into the roughly 6 to 12 second range while maintaining good playback stability.<\/p>\n\n\n\n
For many real-world applications, that is already a huge improvement over traditional HLS setups.<\/p>\n\n\n\n
And honestly, after spending years experimenting with RTMP, WebRTC, CMAF, and every \u201cnext big thing\u201d in streaming, I still keep coming back to the same conclusion:<\/p>\n\n\n\n
A properly tuned Wowza HLS setup remains one of the most practical and reliable streaming solutions available.<\/p>\n\n\n\n
And yes, after all these years, HLS is definitely still here to stay.<\/p>\n\n\n\n