ZeroDelay: a Manifest V3 extension that pulls YouTube live streams back to the edge

The delay problem ZeroDelay targets, and who it is for

A YouTube live stream with DVR enabled plays behind the live edge whenever the player's buffer runs thin. The player does not catch up on its own. It sits at whatever delay it accumulated, and the only fix a viewer has is to drag the progress bar forward, which risks a stall because the buffer is already the reason the stream fell behind. ZeroDelay automates that recovery. The README describes it as an extension that helps YouTube live streams get back to real time when the player falls behind.

The audience is narrow and specific: people watching live events on YouTube who care about being seconds behind rather than tens of seconds behind. Sports, auctions, earnings calls, anything where a chat message or a notification spoils the moment before the video reaches it. The README frames the trade-off in terms of connection quality. Modes that keep less buffer sit closer to live but need more bandwidth, and the mode table gives a recommended range for each. Balanced wants roughly 5 to 10 Mbps, Close wants a stable 15 plus, Extreme wants fast and stable 50 plus. Automatic, the default, measures the connection and adjusts. If you watch live streams on a connection that fluctuates, Automatic is the mode the project intends you to leave alone.

How the catch-up engine actually works

The mechanism is playback rate, not seeking. The README states that the accelerator raises speed only as much as needed, a gentle 1.25x, to consume content that is already downloaded and pull the viewer back to real time. Once the delay closes, it returns to 1.0x. That is the whole loop: act in short bursts, rest, act again after the next stall. Raising the rate consumes buffered content faster than the network refills it, which is how the delay shrinks.

There is one implementation detail that matters more than the rest. Modern YouTube live streams, which the README calls SABR or manifestless, ignore direct writes to video.playbackRate. The engine instead calls the player's own setPlaybackRate() API. Without that, catch-up would silently do nothing on exactly the streams most people watch. The repository layout reflects this separation: engine/ holds the logic, inject.js runs in the page context where the player API lives, content.js and overlay.js handle the YouTube UI, and background.js runs the extension service worker.

The second mechanism is the anti-stall brake. In every mode, including the aggressive ones, the brake slows playback slightly below 1.0x to rebuild the cushion when the buffer runs thin, rather than only resting at 1.0x. That is a deliberate choice: it means a mode can momentarily play slower than real time to avoid a freeze. The README says the lowest possible latency is the stream's own live edge, the encoding to ingest to transcoding to server CDN floor, and that no viewer-side tool can beat it. That is an honest boundary and it should shape expectations.

Installing ZeroDelay and getting to a first catch-up

The README points to two distribution channels and does not document a manual unpacked install in what is shown here. For most readers the store route is the intended one.

Chrome users install from the Chrome Web Store listing linked in the README, and Firefox users from the Firefox Add-ons listing. The manifest is Manifest V3, with a separate manifest.firefox.json in the repository for the Firefox build. Once installed, the extension adds controls that blend into the standard YouTube player bar and stay available in fullscreen, and the README notes it also works in the embedded player.

The fastest first use is the keyboard shortcut. The README gives Alt+Shift+Y to toggle on and off, and Alt+Shift+L to jump to live, with Command+Shift replacing Alt+Shift on Mac. Both are remappable at chrome://extensions/shortcuts.

Alt+Shift+Y   # toggle ZeroDelay on/off
Alt+Shift+L   # jump to live

If you would rather tune it, open the popup and pick a mode. Automatic is the default and the one the README marks with a star. Custom exposes a 1 to 6 second slider for the target buffer, held by the same anti-stall brake. If you want to see what the engine is doing, enable the optional player indicators for playback rate, live latency and buffer health, which appear next to the live badge. The README also mentions a latency badge on the toolbar icon, per-tab and off by default, for checking at a glance whether you are at live without opening the popup.

If you build from source, the repository requires Node 22.2 or newer and exposes a test script.

npm test
npm run build

The build script runs scripts/validate.mjs before scripts/build.mjs, so a validation failure stops the build. A Firefox build and lint path exists separately through npm run build:firefox and npm run lint:firefox, which wraps web-ext.

Where ZeroDelay stops helping

The most important limitation is stated by the project itself: the lowest achievable latency is the stream's own live edge, and no viewer-side tool can change the encoding, ingest, transcoding and CDN pipeline. If a broadcaster adds ten seconds of delay upstream, ZeroDelay cannot remove it. It can only close the gap the player added on top.

The second limitation is bandwidth. Every mode below Automatic keeps a fixed, small buffer, and the README pairs each with a recommended connection. Close at roughly 3 seconds of buffer wants a stable 15 plus Mbps; Extreme at roughly 2 seconds wants 50 plus and a fast, stable link. On a connection that dips, those modes will trigger the brake repeatedly, and playback will spend time below 1.0x. The mode that keeps the least buffer is the mode that stalls first. That is a real trade-off, not a marketing position.

The third is scope. This is a playback-rate tool for DVR-enabled YouTube live streams. It does not record, it does not download, it does not work on platforms other than YouTube, and the README does not claim otherwise. If the stream has DVR disabled, there is no buffer to spend and no delay to close. And because the engine depends on the player's setPlaybackRate() API to work on SABR or manifestless streams, any future change to that player API is a failure mode the extension cannot control. The README documents the dependency; it does not document a fallback.

How ZeroDelay differs from live-catch-up

The README is unusually direct about lineage. ZeroDelay is a derivative work of the live-catch-up extension by yudai-tiny-developer, originally licensed under MIT and Apache-2.0, relicensed here under GPL-3.0 with those notices preserved. So the honest comparison is not ZeroDelay against some unrelated competitor. It is ZeroDelay against the extension it grew out of.

The difference visible in the documentation is the operating model. ZeroDelay presents one-tap modes with a stated buffer target and a recommended bandwidth range for each, an Automatic mode that measures bandwidth, buffer stability and stalls and adjusts the target on the fly, a Custom slider for 1 to 6 seconds, and an anti-stall brake that dips below 1.0x to rebuild the cushion. It also adds player indicators and a jump-to-live threshold, on by default at 30 seconds. The version history backs this up: v1.3.0 is titled around a Custom mode and a brake applied in all modes, and v1.4.0 and v1.5.0 followed within about a week. That is a project iterating on its tuning surface, not on its core idea.

If you want the original, smaller codebase with the MIT and Apache-2.0 terms, live-catch-up is the one to read. If you want the mode table, the adaptive target and the brake, ZeroDelay is the one that has them. The licence difference matters for anyone embedding either in a larger product.

Maintenance, upgrade cost and the GPL-3.0 boundary

The repository is not archived, and the last push was on 2026-07-14. The most recent release, v1.5.0, is dated the same day, with v1.4.0 on 2026-07-07 and v1.3.0 on 2026-07-06. Three releases in roughly a week, then nothing recorded after that date. Anyone evaluating this should read that pattern as a burst of tuning work rather than a promise of a release cadence, because nothing in the repository shows one.

Upgrade cost for users is low. Store-delivered extensions update themselves, and the README does not document a migration step between versions. For contributors, the cost sits in the build chain: Node 22.2 or newer, a validation gate, a separate Firefox manifest and build path, and locale checks through npm run check:locales. The devDependencies include puppeteer and web-ext, so a full local setup pulls browser automation tooling.

On licensing, the package declares GPL-3.0-or-later and the README states GPL-3.0 with no warranty. Because the project is a derivative of MIT and Apache-2.0 code, those notices must be preserved, and the repository keeps them in THIRD-PARTY-NOTICES.md. The bundled QR generator in vendor/qrcode.js is MIT and described as GPL-compatible. None of this is legal advice; if you plan to redistribute a modified build, read LICENSE and THIRD-PARTY-NOTICES.md together before you decide what you can ship.

Editorial conclusion

ZeroDelay is for viewers on stable connections who watch DVR-enabled YouTube live streams and want the delay under a few seconds without touching the player manually. It is not for anyone who wants to record, download or watch without DVR, and it will not help on a connection that cannot hold a buffer. Before adopting it, read the mode table and pick the buffer target your bandwidth actually supports, check that your stream is not manifestless in a way the setPlaybackRate() path fails on, and confirm the jump-to-live threshold of 30s is where you want it, since it is on by default. The source is GPL-3.0-or-later with MIT and Apache-2.0 notices preserved from live-catch-up; if you fork it, keep THIRD-PARTY-NOTICES.md intact.

Frequently asked questions

Official sources

1. Issues
2. joaogfc/ZeroDelay on GitHub
3. License: GPL-3.0
4. README
5. Releases