<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hls.js on Everyone Has a Story</title><link>https://bhaveshsgupta.com/tags/hls.js/</link><description>Recent content in Hls.js on Everyone Has a Story</description><generator>Hugo</generator><language>en-us</language><managingEditor>BhaveshSGupta@disroot.org (Bhavesh S. Gupta)</managingEditor><webMaster>BhaveshSGupta@disroot.org (Bhavesh S. Gupta)</webMaster><lastBuildDate>Tue, 06 Oct 2026 18:26:36 +0530</lastBuildDate><atom:link href="https://bhaveshsgupta.com/tags/hls.js/index.xml" rel="self" type="application/rss+xml"/><item><title>It only fails in Safari: two HLS engines, and how to debug across hops</title><link>https://bhaveshsgupta.com/blog/hls-cdn-4-only-fails-in-safari/</link><pubDate>Tue, 06 Oct 2026 09:03:00 +0530</pubDate><author>BhaveshSGupta@disroot.org (Bhavesh S. Gupta)</author><guid>https://bhaveshsgupta.com/blog/hls-cdn-4-only-fails-in-safari/</guid><description>&lt;p&gt;When a live stream breaks in Safari and plays in Chrome, the tempting conclusion is that Safari&amp;rsquo;s player is the problem. Often it isn&amp;rsquo;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.&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;In short:&lt;/strong&gt; 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.&lt;/p&gt;</description></item><item><title>Slide sync over HLS with ID3 timed metadata</title><link>https://bhaveshsgupta.com/blog/hls-cdn-3-id3-slide-sync/</link><pubDate>Tue, 06 Oct 2026 09:02:00 +0530</pubDate><author>BhaveshSGupta@disroot.org (Bhavesh S. Gupta)</author><guid>https://bhaveshsgupta.com/blog/hls-cdn-3-id3-slide-sync/</guid><description>&lt;p&gt;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 &amp;ldquo;now&amp;rdquo; from the presenter&amp;rsquo;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.&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;In short:&lt;/strong&gt; 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&amp;rsquo;s metadata text track, which works in hls.js and Safari.&lt;/p&gt;</description></item></channel></rss>