Engineering on Everyone Has a Story

It only fails in Safari: two HLS engines, and how to debug across hops

BhaveshSGupta@disroot.org (Bhavesh S. Gupta) — Tue, 06 Oct 2026 09:03:00 +0530

When a live stream breaks in Safari and plays in Chrome, the tempting conclusion is that Safari’s player is the problem. Often it isn’t. Both browsers receive the same files from the same CDN. They differ in what they do when one of those files is wrong, so a delivery fault that Chrome quietly recovers from becomes a Safari bug report.

In short: Chrome, Edge and Firefox usually play HLS through hls.js, which retries failed requests and skips small gaps; Safari uses its native player, which surfaces the same faults as errors or stalls. Both get identical bytes, so a problem that only shows in Safari is usually a delivery problem. Find it by measuring each hop separately: compare responses at the origin and the CDN, probe from many regions, group logs by browser, and inspect the segments.

Slide sync over HLS with ID3 timed metadata

BhaveshSGupta@disroot.org (Bhavesh S. Gupta) — Tue, 06 Oct 2026 09:02:00 +0530

A webcast with slides has to change the slide at the moment the presenter does, as the viewer sees it. Viewers are 10 to 30 seconds behind live, each by a different amount, so a message sent “now” from the presenter’s page arrives at the wrong time for everyone. The fix is to put the slide change inside the stream itself, at the right timestamp. In HLS that means ID3 timed metadata.

In short: To change slides at the exact moment the presenter did, put the change inside the stream as ID3 timed metadata. Each tag rides in the segment on its own data stream with a presentation timestamp, so the player fires it at the right frame however far behind live the viewer is. Put every tag in every quality, re-send the current slide regularly for late joiners, and read the tags through the video element’s metadata text track, which works in hls.js and Safari.

Putting a live HLS origin behind a CDN

BhaveshSGupta@disroot.org (Bhavesh S. Gupta) — Tue, 06 Oct 2026 09:01:00 +0530

A CDN in front of a live HLS origin should mean each segment leaves your server a handful of times, however many people watch. Whether it does depends on details that are easy to get wrong and hard to see: the URLs your origin hands out, the headers on each kind of file, and every layer between the origin and the viewer that has its own opinion about caching.

In short: A CDN only protects a live origin if every viewer requests the same URLs: no per-viewer session ids, and no query strings in the cache key. Give media playlists about a one-second lifetime, segments about a minute, and errors no-store so an early 404 isn’t served to everyone. Check headers at every hop, send CORS headers when the player is on another domain, and confirm request collapsing and an origin shield with the CDN that pulls from you.

HLS for backend engineers: playlists, segments and keyframes

BhaveshSGupta@disroot.org (Bhavesh S. Gupta) — Tue, 06 Oct 2026 09:00:00 +0530

If you run the servers behind a live stream, you don’t need to know much about codecs. You do need to know what files a player asks for, how often, and what decides their size and timing. That’s what this post covers, with commands you can run against any HLS stream.

The series is about standard HLS, with MPEG-TS or fragmented MP4 (CMAF) segments. The same principles carry over to Low-Latency HLS, though its partial segments and blocking playlist reloads aren’t covered here. Real-time streaming, such as WebRTC at under a second of delay, works differently and isn’t covered at all: it has no playlists or segments for a CDN to cache.

In short: A live HLS stream is a master playlist of qualities, one media playlist per quality, and short segments. Each segment must start on a keyframe, so a fixed keyframe interval of 1 or 2 seconds keeps segments even. The target duration is the ceiling on segment length; players reload about once per target duration and start three target durations behind live, so it sets your latency. Every quality needs the same boundaries and timestamps for switching to be smooth.