User manual

1 Introduction

A live stream always plays a few seconds behind what the streamer is doing right now. That gap grows every time your connection hiccups, and it never shrinks on its own.

Slipstream Live measures how much video your browser has loaded ahead — the buffer — about 50 times per second, and nudges the playback speed up or down to close the gap without letting the video stall.

Once installed, no operation is required while you watch.

2 System requirements

3 Installation

3.1 Chrome / Edge / Brave / other Chromium browsers

Install from the Chrome Web Store.

After installing, open the puzzle-piece menu in the toolbar and pin Slipstream Live so its icon is always visible.

3.2 Firefox

Install from Firefox Add-ons.

3.3 Installing from source (developers / manual installation)

Chromium browsers

1. Download the repository as a ZIP and extract it (or git clone it).
2. Enter chrome://extensions in the address bar.
3. Turn on Developer mode with the toggle in the top-right corner.
4. Click Load unpacked and select the extracted folder — the one containing manifest.json.

Firefox — temporary install (disappears when Firefox closes)

1. Open about:debugging#/runtime/this-firefox.
2. Click Load Temporary Add-on….
3. Select the manifest.json file inside the extracted folder.

Firefox — permanent install (Developer Edition / Nightly only)

1. ZIP the contents of the folder.
2. In about:config, set xpinstall.signatures.required to false.
3. In about:addons, click the gear icon → Install Add-on From File… → choose your ZIP.

3.4 Verifying the installation

1. Open a live stream on YouTube, Twitch, TwitCasting, TikTok LIVE, DAZN, or Kick. A VOD or clip will not work. On DAZN and Kick, press Enable on this site in the popup first (see “Using DAZN and Kick” in section 6).
2. Click the Slipstream Live toolbar icon.
3. In the All sites panel, turn on Show playback rate.
4. A small 1.00x appears in the player's control bar, changing colour as Slipstream Live works.

4 Parts of the settings screen

Click the toolbar icon to open the settings popup. The same screen can also be opened as a full tab from your browser's extensions management page (Options).

• Changes take effect immediately. There is no Save button.
• Rows that are not currently in use are greyed out. For example, Speed-up start buffer threshold (sec) and Speed-up stop buffer threshold (sec) are disabled while Auto-adjust buffer threshold is set to anything other than Off.
• On the Twitch tab only, an explanatory note about that site's larger default threshold appears at the bottom of the panel, along with a Recover from player errors switch that has no equivalent on the other sites.
• On the Kick tab only, a note explaining why that site's defaults differ from the others appears at the bottom of the panel, along with a Recover from endless loading switch.
• On the TikTok tab only, an Allow speed changes in Chrome switch appears at the bottom of the panel (see “TikTok LIVE on Chrome” in section 6).
• On the DAZN and Kick tabs, until you have allowed access to the site, an Enable on this site button appears at the top of the panel (Enable on DAZN or Enable on Kick when the popup is opened on any other page; see “Using DAZN and Kick” in section 6).

5 Reading the on-screen badges

All three badges are off by default. Turn them on in the All sites panel. They appear in the player's control bar; if that bar cannot be found, they fall back to a small dark strip in the top-left corner of the player.

6 The three control modes

Higher-priority modes always win. The 0.15x floor speed is deliberately not configurable — it is a safety net, not a preference.

Each threshold carries hysteresis in the direction of the current mode, so speed and volume don't chatter when the buffer sits exactly on a boundary. The width is 0.2 s at every level. On top of that, starting a speed-up is rate-limited to once every 2 seconds. Nothing else is delayed — not leaving a speed-up, not entering Floor, not leaving it. Only the direction that increases intervention is treated cautiously; backing off and falling back to safety always take effect at once. Widening a threshold alone can't stop the chatter, because the value being compared against it moves as well.

Recovering from a dead player

On Twitch the player occasionally stops outright with a numbered error — #3000 is the common one. The usual cure is a page reload, which costs you the chat and your place in it. Slipstream Live watches for that error and presses Twitch's own reload button instead, so playback comes back in about a second with the page untouched. It waits a moment first in case the player rights itself, tries a few times at widening intervals, and then stops rather than hammering a stream that has simply ended. This is on by default and can be switched off on the Twitch tab.

On Kick, playback sometimes stays on the loading spinner and never resumes, typically after video data has stopped arriving for a while. No error is raised, so Kick's own reconnect logic never kicks in either, and the usual cure is again a page reload. When the position hasn't moved for about 6 seconds while loading, Slipstream Live has Kick's player reload the stream — the same steps Kick takes itself when recovering from an error. If the player is stuck on a seek that never completed, it first seeks again to the current position to finish it. The page stays as it is, so the picture comes back within a few seconds. It tries a few times at widening intervals and then stops, and never acts while you've paused, during ads, or on VODs. If the playback token has expired, Kick's own reconnect logic fetches a fresh one and loads it (Slipstream Live never makes a request itself). This is on by default and can be switched off with Recover from endless loading on the Kick tab.

TikTok LIVE on Chrome

TikTok picks one of two playback methods when the page opens. On Chrome 122 or later with 6 or more CPU cores (Edge excluded), it decodes the video itself and only shows the result in the <video> element as a MediaStream. That always plays at 1.0x by definition, so its speed cannot be changed by any means. Everywhere else — Firefox, Edge, Chrome with fewer cores — TikTok uses ordinary playback whose speed can be changed just as on YouTube.

So, before any of TikTok's own scripts run, Slipstream Live has TikTok pages see at most 4 CPU cores, and TikTok picks the same standard method it uses on Firefox and Edge. This only happens on TikTok's own pages in Chromium browsers and doesn't reach other sites. It is on by default; switch Allow speed changes in Chrome off on the TikTok tab to let TikTok choose on its own. The choice is made when the page loads, so reload the page after changing the setting.

Using DAZN and Kick

DAZN and Kick are the two sites that don't work straight after installing. Open a DAZN (or Kick) page, click the toolbar icon, and press Enable on this site at the top of the DAZN (or Kick) tab. Your browser asks for access to www.dazn.com — for Kick, to kick.com and player.kick.com (the player other sites embed) — and once you allow it, Slipstream Live starts working right away, including on pages that are already open (reload the page if it doesn't). You can withdraw the access at any time from your browser's extension settings.

These sites work this way so that adding a site never asks every user to approve new permissions: Chrome disables the extension until they do, and Firefox doesn't grant host permissions that an update adds.

DAZN's player only reads about 12 seconds ahead, even when the newest point of the stream is much further on. So while Slipstream Live speeds up, buffer health barely drops until it reaches the live edge — only the latency shrinks.

Kick's low-latency streams normally keep only 1.3–2.5 seconds of video loaded. Kick often stops delivering video for around 10 seconds; once it resumes, playback carries on about that far behind, and Kick's player doesn't catch up by itself. Slipstream Live uses the video that piled up to get back to the live edge — in testing, from about 12 seconds behind to about 1.6 seconds in roughly 40 seconds at 1.25x. Because the gaps are so frequent, Kick's defaults keep about 5 seconds of video loaded and bridge the last 2 seconds at 0.15x (see Why are Kick's defaults different? in chapter 7). If playback still stalls on the loading spinner, the stream is reloaded automatically (see Recovering from a dead player). Kick only builds its control bar while you move the mouse over the player and removes it a few seconds later, so the badges come and go with it.

What Slipstream Live leaves alone

• Archived videos (VODs), clips, and ad breaks are never touched. Only live playback is controlled.
• YouTube premieres are skipped by default. A premiere plays a pre-recorded video on a live schedule, and while one is running it is indistinguishable from a live stream — but the point of a premiere is that everyone watches the same moment together, so catching up only puts you ahead of the chat. Turn Control premieres on at the bottom of the YouTube tab to have them treated like any other live stream.
• TwitCasting low-latency streams are out of scope. They arrive over WebRTC, which has no read-ahead buffer to measure and ignores playback-rate changes entirely. Such streams are already close to real time, so there is nothing to catch up on.
• On TikTok, only LIVE pages (/live and /@name/live) are watched. Videos in the feed are never touched.
• On Kick, VODs (including the VOD of a stream that's still live) and clips are left alone, and so are the ad breaks Kick inserts into a live stream — the player announces them, and control resumes when they end.
• On YouTube and TwitCasting, if you choose a speed other than 1.00x in the player's own menu, Slipstream Live hands control back to you and stops adjusting. Set the speed back to normal to resume automatic control. Twitch, TikTok LIVE, DAZN, and Kick have no such menu, so Slipstream Live stays in charge there — and on Twitch and Kick, whose players come from the same family, it also suppresses the player's own built-in catch-up so the two don't fight. On DAZN's low-latency streams, where the player tries to speed up and slow down by itself, Slipstream Live's decisions take precedence in the same way.

7 Settings reference

7.1 Site settings (stored separately per site)

FF = the default used on Firefox, which reports buffer levels differently. Twitch is the only site where it differs.

7.2 The four auto-adjust levels

7.3 All-sites settings

8 How it works

Every 20 milliseconds (once a second while paused) Slipstream Live measures buffer health — how many seconds of video are loaded and ready to play — and picks one of the three modes from that number.

The hard part is knowing when speeding up is safe. Buffer health is never steady: video arrives in chunks ("segments"), so the buffer jumps when a chunk lands and then drains until the next one. Plotted over time it looks like a sawtooth. A single reading taken at a peak would suggest plenty of room, leading to a speed-up that hits the very next trough with nothing left.

So instead of trusting one reading, Slipstream Live estimates statistically where the troughs are, over a window that adapts to each stream, and only allows a speed-up while that estimated headroom stays above the buffer level you have asked it to protect — your maximum slowdown threshold plus the level's added margin, or one segment's worth of buffer if maximum slowdown is switched off. Because the safety factor is large, headroom only opens up when the troughs are consistent — an unstable connection naturally suppresses speed-ups, and while there isn't enough data yet, Slipstream Live simply does nothing.

One shortcut sits above that test. Once buffer health passes 20 seconds — or your maximum slowdown threshold plus 10 seconds, whichever is higher — the trough estimate is no longer what limits the decision, so Slipstream Live speeds up without waiting for it, and returns to the statistical test below 15 seconds. This is what keeps it responsive right after you seek, when the buffer refills so quickly that the statistics are temporarily unusable. The shortcut applies to the automatic levels only; with auto-adjust Off, the speed-up simply begins the moment buffer health reaches your threshold and ends the moment it drops below.

All of that answers "is there enough buffer to speed up safely?" — a different question from "is there any point in speeding up?" Live video is produced in real time, so the buffer refills at 1.0x no matter how fast you play it. Once the cushion is spent you are at the live edge, and holding a higher rate there makes playback outrun each arriving segment and stall for a fraction of a second, over and over. Buffer health can't see this, because every stall lets the buffer refill. So Slipstream Live compares the gain the speed-up should have produced against the gain the playhead actually made, over a 12-second window, and stands down when the latter falls below half the former. It re-arms once latency grows past a threshold — one that scales with the site's segment length, so it means the same thing on sites whose baseline latency differs by more than tenfold — or after 30 seconds.

Badges are redrawn at most 10 times per second and all statistics are smoothed, so the speed does not visibly oscillate. When there is nothing to control, the loop drops to a 1-second watch mode instead of stopping, because ads play through the same video element and end without firing any media event. It also runs once immediately when the tab becomes visible again.

9 Troubleshooting

10 Collecting a debug log

If you need to report a problem, a debug log makes it far easier to diagnose.

1. Open the stream page and press F12 to open the browser console — the page console, not the extension's own console.
2. Run the line below.
3. Wait about 30 seconds while the problem is happening, then copy the output.

Once per second you will see the current mode, the real playback rate, buffer health, the short-term and trough statistics, the room calculation, the shortcut level ample, the accumulated excess consumption drift, the stationarity verdict calm, and the speed-up effectiveness gain.

• Buffer figures shown as ---- mean the value is unavailable, usually because the browser reports an empty buffer.
• A persistent calm=NO means the stationarity gate is rejecting samples, so room stays ---- as well. A speed-up can still happen while buffer health is above ample.
• lat= is the latency the site reports. sd is the standard deviation over a 5-second window and jump is the largest change seen in the last second. In practice sd stays at or below 0.11 and jump below 0.2 while latency is steady. A jump that stays well above that means the latency reading is noisy enough to re-arm speed-ups that were correctly stood down.
• gain= reads "seconds actually gained / seconds the speed-up asked for". When the right-hand figure passes 1 second and the left-hand one is under half of it, FUTILE is appended and speed-ups are being skipped.
• timer stopped means the extension is switched off. During playback it should never appear.

11 Privacy

Slipstream Live makes no network requests whatsoever. It requests three permissions:

• storage — to save your settings locally on your device.
• activeTab — to see which supported site the popup was opened on, so it can select the right tab.
• scripting — to register DAZN's or Kick's scripts once you allow that site (nothing is registered for sites you haven't allowed).

Access to DAZN (https://www.dazn.com/*) and to Kick (https://kick.com/* and https://player.kick.com/*) is an optional permission, granted only when you press Enable on this site on that site's tab. You can revoke it at any time from your browser's extension settings.

No analytics, no telemetry, no identifiers, no ads. Full details are in the privacy policy.

12 Support

When reporting a bug, please include: the site, browser and version, extension version, OS, what happened, steps to reproduce, any settings changed from the defaults, and a debug log if possible.

13 License

Dual-licensed under the Apache License 2.0 or the MIT License, at your option.