DEV Community: Hui

I built an AI-powered video speed controller for online courses

Hui — Wed, 22 Jul 2026 05:32:24 +0000

I was taking 12 online courses in 3 months. Python, machine learning, web development — all while working full-time.

Every platform had a different video player. Udemy's speed control had 4 steps. Coursera's shortcuts were different. LinkedIn Learning didn't remember my settings. I was spending more time fighting the players than actually learning.

So I built CourseSpeed.

What it does

CourseSpeed is a Chrome extension that gives you:

Precision speed control (0.25x–16x) with per-platform memory — Coursera stays at 1.5x, Udemy at 1.75x
AI study notes — one click captures audio and generates timestamp-linked notes you can export anywhere
Learning analytics — shows your real efficiency, not just "hours watched"
Keyboard shortcuts for everything — no mouse needed

The tech stack

Manifest V3 Chrome extension
Vanilla JS (no framework — extension needs to be fast and lightweight)
AI note generation via speech-to-text + LLM summarization
All data stored locally in Chrome storage — zero server costs

What I learned

Chrome's MV3 migration is painful but worth it. Service workers replace background pages, and the new API surface takes time to learn.
Course platforms don't want you to control speed. Most of them strip or override custom speed controls. Getting CourseSpeed to work across Udemy, Coursera, LinkedIn Learning, and Skillshare required per-platform DOM manipulation strategies.
Science backs this up. Murphy et al. (2022) found 2x speed causes no significant learning loss. Watching a lecture twice at 2x produces better retention than once at normal speed. I built CourseSpeed on this research — not assumptions.

The results so far

CourseSpeed just launched on Product Hunt and has active users on the Chrome Web Store. The most requested feature so far: per-platform speed presets (already built).

If you take online courses and want to learn faster without losing comprehension, try it out:

👉 https://joycraft.dev/coursespeed

Ask me anything about building Chrome extensions, the MV3 migration, or the science of video speed learning.

The 1.08x Anomaly: What 4 Million Playback Events Taught Me About How We Actually Watch TV

Hui — Thu, 09 Jul 2026 10:48:08 +0000

Tuesday morning, sitting in a cafe with an overpriced flat white, I was scrolling through the monthly aggregated telemetry dashboard for StreamEnhancer.

When I first built this extension to control playback speed across YouTube, Netflix, Disney+, Prime, and Max, I had a very specific mental model of the user. I pictured the hyper-optimized tech worker blasting through a 40-minute YouTube tutorial at 2.5x speed, or the student skimming a recorded lecture at 1.75x. I built the UI around those assumptions. Big, bold buttons for 1.5x and 2.0x.

Then I looked at the histogram for narrative streaming platforms.

Out of 4.2 million speed-change events logged last month, the massive, undeniable spike wasn't at 1.5x. It wasn't at 2.0x.

It was at exactly 1.08x.

Specifically, 61% of all speed adjustments on Netflix, Max, and Disney+ landed in the microscopic band between 1.05x and 1.12x. People aren't trying to hack their way through a movie in half the time. They are trying to shave exactly four minutes off a 50-minute TV episode without their brain registering that the audio has been altered.

It completely changed how I think about media consumption, and more importantly, how I architect the underlying media pipeline for StreamEnhancer.

The "Invisible Speedup" and the Audio Pipeline

At 1.25x, you notice the cadence is off. The pauses between sentences feel unnaturally short. At 1.5x, the pitch correction algorithms in browsers start to make actors sound slightly metallic.

But at 1.08x? Your brain just thinks the actors are speaking a bit more briskly. It’s the Goldilocks zone of time-stretching.

The problem is that browsers are actually pretty bad at handling micro-speedups natively. If you just set video.playbackRate = 1.08 on an HTML5 video element, modern browsers (like Chrome 132) will attempt to preserve the pitch using their built-in time-stretching algorithms. But for complex, multi-layered movie soundtracks—where you have dialogue, a sweeping orchestral score, and foley effects mixed together—the browser's native phase vocoder introduces a subtle "phasing" or "flutter" artifact.

It’s barely noticeable at 1.5x because your brain is already accepting the audio as "fast." But at 1.08x, where the user expects the audio to sound completely natural, that subtle flutter breaks the illusion.

Because the data showed me that this "invisible speedup" was the primary use case, I had to rethink how StreamEnhancer handles the audio context for narrative platforms. Instead of relying purely on the native playbackRate property, we route the audio through the Web Audio API for micro-adjustments.

// High-level architecture for micro-speed audio handling
const audioContext = new AudioContext();
const source = audioContext.createMediaElementSource(videoElement);

// We use a custom granular overlap-add (OLA) processor 
// for speeds between 1.01x and 1.15x to prevent phasing artifacts
const customPitchShifter = createGranularProcessor(audioContext, {
  grainSize: 2048,
  overlapRatio: 0.75,
  targetRate: 1.08
});

source.connect(customPitchShifter);
customPitchShifter.connect(audioContext.destination);

// Disable native pitch preservation so our custom node handles it
videoElement.preservesPitch = false;
videoElement.playbackRate = 1.08;

By handling the granular synthesis ourselves for that specific 1.01x–1.15x band, we eliminate the metallic flutter on movie soundtracks. It takes more CPU, but the data proved this is exactly what people actually care about. For speeds above 1.25x, we just fall back to the browser's native implementation to save battery life.

The Bimodal Reality of YouTube

If Netflix and Max are about the "invisible speedup," YouTube is a completely different beast.

When I isolated the telemetry for YouTube, the histogram didn't show a neat curve. It showed a harsh, bimodal distribution.

Peak 1: 1.0x (Music videos, podcasts, and high-production video essays).
Peak 2: 2.0x to 3.0x (Tutorials, tech reviews, and news).

There is almost no middle ground on YouTube. You are either consuming it as art/entertainment, or you are consuming it as pure information extraction.

This taught me a hard lesson about context-aware UI. Initially, StreamEnhancer used a single, unified speed-control overlay for all platforms. But the data screamed that a YouTube user wants quick, aggressive jumps (tapping a hotkey to instantly jump from 1.0x to 2.0x), while a Netflix user wants fine-grained control (scrolling a wheel to dial in exactly 1.08x).

We ended up splitting the default hotkey mappings based on the domain. On YouTube, the + and - keys jump in 0.5x increments. On Netflix/Max, they jump in 0.05x increments.

The 14-Second Rule and the "Subtitle Drop"

The last piece of data that completely caught me off guard was when people change the speed.

I assumed people would settle in, watch for a few minutes, realize the pacing was too slow, and then reach for the extension.

Wrong. 78% of all speed adjustments happen in the first 14 seconds of a video.

People know exactly what they want before the intro sequence even finishes. If the StreamEnhancer UI takes more than a second to inject into the DOM and become interactive, they rage-click. This forced us to heavily optimize the content script injection. We moved away from waiting for the DOMContentLoaded event and started injecting the speed-controller UI via a MutationObserver that triggers the millisecond the specific platform's video player container hits the DOM.

But there was a secondary, weirder spike in the "when" data.

On Netflix and Disney+, there was a massive cluster of speed adjustments happening around the 12-minute to 15-minute mark, and almost all of them were downward adjustments, dropping the speed to 0.85x or 0.9x.

I couldn't figure it out until I cross-referenced it with the language settings in the anonymized telemetry payloads.

Subtitles.

People watching foreign-language shows, or even just complex sci-fi/fantasy shows with heavy exposition (like House of the Dragon or Shōgun), let the first 10 minutes play at 1.0x. But around the 12-minute mark, when the plot thickens and the dialogue gets dense, they drop the speed to 0.9x so they have an extra fraction of a second to read the subtitles without pausing the video.

It’s such a specific, human behavior. They aren't pausing because pausing breaks the immersion and ruins the audio swell. They just slow the world down by 10% so their eyes can catch up to their ears.

Building for the Margins

When you build a tool like StreamEnhancer, it’s easy to get caught up in the extremes. You want to support 0.1x so people can analyze golf swings, and 16x so people can skim 4-hour podcasts.

But the telemetry doesn't lie. The vast majority of your users are living in the margins. They want 1.08x to get to bed 4 minutes earlier. They want 0.9x to read a subtitle. They want to make the adjustment in the first 14 seconds and never touch the UI again.

Looking at the numbers didn't just change my feature roadmap; it completely shifted my philosophy on what a "power user" actually is. A power user isn't the person watching a video at 4x speed. A power user is the person who knows exactly how to manipulate the media to perfectly match their cognitive load in that exact moment.

And honestly? That's a lot more interesting to build for.

The 412% Illusion: What 50,000 hours of playback data taught me about "speed learning"

Hui — Thu, 09 Jul 2026 10:45:44 +0000

412%.

That was the number sitting in my weekly aggregate query results on a random Tuesday morning while I was eating a bagel. I actually stopped chewing for a second.

For context, CourseSpeed is the browser extension I built to give users granular playback speed control and learning analytics across Udemy, Coursera, LinkedIn Learning, and Skillshare. I originally built it because I was tired of the clunky native speed controls on these platforms. I assumed my users were just like me: impatient developers trying to blast through a 40-hour React masterclass in a weekend.

But when you build an analytics layer on top of a video player, you stop guessing how people learn and start seeing how they actually learn.

And the data completely broke my mental model of "speed learning."

The Micro-Rewind Tax

Let's talk about that 412%.

I was looking at the delta in user behavior when they switched their default playback speed from 1.25x to 2.0x. I expected the total time spent on the platform to drop by roughly 37% (the mathematical difference between the two speeds).

Instead, the "effective watch time" only dropped by about 8%. Why? Because micro-rewinds spiked by 412%.

A micro-rewind is when a user jumps back 5 to 15 seconds in the video. At 1.25x, people mostly just let the video play. At 2.0x, the cognitive load gets too high, they miss a crucial sentence, and they aggressively mash the left arrow key.

They weren't saving time. They were just buffering their own brains.

To track this without being creepy, CourseSpeed doesn't record what you're watching. No video titles, no URLs, no user IDs tied to specific courses. We just listen to the HTML5 <video> element's DOM events and batch the telemetry.

Here is the stripped-down logic we use in the content script to calculate the "rewind tax":

// content-script.js (Manifest V3)
let lastTimestamp = 0;
let microRewindCount = 0;
let totalRewindSeconds = 0;

const videoElement = document.querySelector('video');

videoElement.addEventListener('timeupdate', () => {
  lastTimestamp = videoElement.currentTime;
});

videoElement.addEventListener('seeked', () => {
  const currentTime = videoElement.currentTime;
  const delta = lastTimestamp - currentTime;

  // Define a micro-rewind as jumping back between 3 and 20 seconds
  if (delta >= 3 && delta <= 20) {
    microRewindCount++;
    totalRewindSeconds += delta;
  }

  // Batch and send to our analytics endpoint
  flushTelemetry({
    event: 'seek_behavior',
    playback_rate: videoElement.playbackRate,
    micro_rewinds: microRewindCount,
    time_lost_to_rewinds: totalRewindSeconds
  });
});

When I saw the 412% spike, I realized my UI was actually encouraging bad learning habits. I was making it too easy to hit 2.0x.

I ended up redesigning the speed selector. Instead of a linear slider, I added a subtle visual "friction" indicator. If you push past 1.5x, the UI gently shows your historical "rewind ratio" for that speed. It’s just a tiny text hint: "You usually rewind 4x more at this speed."

Surprisingly, users loved it. It made them more intentional.

The Platform Personality Split

The second thing that caught me off guard was how wildly the data varied depending on the hostname. I initially thought "a video is a video," but the platform dictates the pedagogy, which dictates the playback behavior.

I ran a clustering analysis on the average playback rates across the four major platforms we support. The results were stark.

Udemy users are speed demons. The median playback rate is 1.65x. But their session lengths are short. They treat courses like a checklist. Speed up, get the concept, mark as complete, move on.

Coursera and edX users hover around 1.15x. They rarely touch the speed controls once they set them. The content is usually more academic and dense, so they treat it like a university lecture.

But LinkedIn Learning was the weirdest. The data showed a massive bimodal distribution. Users were either watching at exactly 1.0x or exactly 2.0x. Almost nobody sat in the 1.25x to 1.75x middle ground.

Digging into the session logs, I figured out why. LinkedIn Learning videos are heavily segmented into 2-to-3 minute micro-chapters. At 1.0x, it's a quick coffee-break watch. At 2.0x, it's a 60-second summary. The middle speeds just feel awkward for content that short.

This completely changed how I shipped the latest update. Instead of a global default speed, CourseSpeed now uses platform-aware presets. If you're on LinkedIn Learning, the speed toggle snaps to 1.0x and 2.0x. If you're on Coursera, it gives you fine-grained 0.05x increments between 1.0x and 1.5x.

Matching the tool to the platform's native content rhythm increased our daily active user retention by 18% in a single month.

The "Pause-to-Completion" Ratio

This is the metric I’m actually most proud of, even though it’s the least "hacky" one.

Everyone obsesses over completion rates in ed-tech. Course creators want to know why students drop off. I wanted to know if my extension was helping or hurting.

I created a metric called the Pause-to-Completion Ratio. I looked at users who successfully finished a course (reached the final video) versus those who abandoned it (no activity for 30+ days).

The speed they watched at didn't matter nearly as much as I thought. You can finish a course at 2.0x just as easily as 1.0x.

What mattered was the pauses.

Users who paused the video for >30 seconds at least once every 15 minutes had an 88% course completion rate.
Users who blasted through with zero long pauses had a 14% completion rate.

The people who were actually learning were stopping to take notes, write code, or just stare at the wall and process what they just heard. The people who were just "consuming" were treating it like Netflix. And just like a Netflix binge, they eventually got bored and stopped.

I didn't want to just observe this; I wanted to act on it.

I introduced a "Focus Mode" in CourseSpeed. If the telemetry shows you've been playing a video at >1.5x for 45 minutes without a single pause longer than 10 seconds, the extension gently fades in a non-intrusive overlay: "You've been going fast for a while. Good time to pause and review?"

It doesn't force a pause. It just breaks the trance.

Data over assumptions

Building CourseSpeed started as a scratch-my-own-itch project. I just wanted to watch tutorials faster. But building the analytics layer turned it into a mirror reflecting how human attention actually works.

We think we want to consume information as fast as possible. But the data shows that our brains still need time to compile the code, so to speak.

If you're building any kind of tool that interacts with user habits, don't just build the feature you think they want. Build the telemetry to see what they actually do. The numbers will humble you, but they'll also point you toward a much better product.

The unglamorous reality of maintaining a streaming extension as a solo dev

Hui — Thu, 09 Jul 2026 06:47:31 +0000

Tuesday, 8:15 AM. I was waiting for the kettle to boil when the email notification popped up on my phone.

Chrome Web Store Developer Support: Action Required for StreamEnhancer.

My stomach did that familiar little drop. It wasn’t a malware flag, and it wasn’t a copyright strike. It was a policy rejection under the "Interfering with third-party website functionality" clause.

Building StreamEnhancer—the extension that lets you fine-tune playback speed on YouTube, Netflix, Disney+, Prime, and Max—was the fun part. Figuring out how to inject UI overlays into wildly different video players and keeping the audio pitch intact at 2.5x speed? That was a great puzzle.

But nobody warns you about the administrative and emotional overhead of keeping a media-manipulation extension alive in the wild.

Here is what actually takes up my time these days.

The CWS Review Tug-of-War

When you build an extension that touches major streaming platforms, you are automatically flagged for deeper manual review by the Chrome Web Store team. And honestly? I get it. The web is full of malicious extensions trying to intercept video streams or inject ads into Netflix.

But StreamEnhancer doesn't touch DRM. It doesn't decrypt Widevine. It literally just finds the HTML5 <video> element and tweaks the playbackRate property.

Explaining this to a reviewer who is processing hundreds of extensions a day is a diplomatic exercise, not a technical one.

When I got that Tuesday morning rejection, the reviewer cited a policy about modifying the core experience of a third-party service. I couldn't just reply with "but it's just the standard HTML5 API." I had to build a case.

What actually works with CWS reviewers:

A short, unlisted YouTube video (or Loom) showing the extension in action.

A screen recording of the Chrome DevTools Network tab, proving no encrypted media streams are being intercepted or modified.

A written breakdown mapping your extension's features directly to standard, documented browser APIs.

I spent two hours recording a video, pausing to explicitly point out that the video source URLs were untouched, and writing a polite, overly detailed explanation of how HTMLMediaElement.playbackRate is a native browser feature, not a hack.

It took four days to get approved. Four days where my existing users were stuck on the old version, and new users couldn't install it. You just have to sit with that anxiety and keep checking your email.

The "Is Netflix Broken or Is It You?" Support Queue

The other massive time sink is user support. And with streaming extensions, support is deeply psychological.

Streaming platforms update their DOM structures and player wrappers constantly. Disney+ is particularly notorious for tweaking their web player on random Thursday nights. When they change the class names on their player controls, my injected speed buttons might misalign or disappear entirely.

When that happens, my inbox fills up.

But here’s the thing: users don't email me saying, "Hey, the DOM structure on the Disney+ web player changed, causing your overlay to fail."

They email me saying:

"Did Netflix ban my account?"
"Why is my TV freezing?"
"Your extension broke my streaming, I want a refund."

When you're a solo dev, you aren't just fixing code. You are de-escalating panic. People pay $15 to $25 a month for these streaming services. They feel entitled to a flawless experience. If my $3 extension accidentally covers up the "Skip Intro" button because of a z-index miscalculation, they are going to be annoyed.

I had to learn to separate my ego from their frustration.

Early on, I would get defensive. I’d write back long explanations about how Netflix changed their code, not me. It didn't help. It just made them angrier.

Now, my support process is entirely about speed and validation.

Acknowledge immediately. "You're right, the player updated and the controls are hidden. I'm working on the fix right now."
Provide a temporary workaround. "In the meantime, you can use the keyboard shortcuts (Shift + >) to change speed without the UI."
Ship the fix and follow up.

I also set up a very specific FAQ page. The very first question is: "Is my streaming service broken, or is it StreamEnhancer?" I included a quick guide on how to disable the extension to test if the native player works. It cut my "my TV is broken" support tickets by about 60%.

The reality of the solo dev maintenance loop

Look, building the thing is maybe 20% of the job.

The other 80% is monitoring the Chrome Web Store policy updates, keeping an eye on streaming platform changelogs (or just waiting for users to tell me they changed something), and managing the expectations of people who just want to watch The Bear at 1.25x speed without the audio sounding like chipmunks.

It’s unglamorous. It’s a lot of email writing and policy reading. But when I get a random five-star review from a med student who says StreamEnhancer saved them hundreds of hours of lecture watching?

Yeah. I'll happily deal with the CWS review queue for that.

Stop relying on `timeupdate`: Building battery-efficient video analytics in the browser

Hui — Thu, 09 Jul 2026 06:45:20 +0000

Sunday mornings are for pour-over coffee and catching up on tech courses. A few months ago, I was working through an advanced Rust module on one of the big e-learning platforms. I paused, scrubbed back to re-watch a tricky section on lifetimes, and then skipped ahead.

When I checked my dashboard later, the platform told me I was 85% done with the course.

I wasn't. I was maybe 40% done. The platform's progress tracking was essentially just looking at the highest timestamp I'd reached, completely ignoring the scrubbing and re-watching. It was garbage data.

That specific frustration is what pushed me to build CourseSpeed. I wanted actual, granular learning analytics and better playback speed controls across Udemy, Coursera, and the rest. But building a browser extension that tracks video engagement accurately without turning the user's laptop into a space heater taught me a hard lesson about how we traditionally handle video events in the DOM.

If you're building anything that interacts with HTML5 video—whether it's a custom player, an analytics script, or a browser extension—you need to stop using the timeupdate event.

Here is what you should be doing instead.

The `timeupdate` trap

If you open the dev tools on almost any video player and attach a listener to timeupdate, you'll see it firing constantly.

// The old, bad way
videoElement.addEventListener('timeupdate', (e) => {
    logAnalytics(e.target.currentTime);
});

The problem? The HTML5 spec doesn't dictate exactly how often timeupdate should fire. It just says it should fire when the playback position changes. In practice, browsers fire it anywhere from 4 to 60 times a second.

If you're just updating a UI progress bar, that's fine. But if you're doing what I do in CourseSpeed—calculating watch-time density, tracking playback speed changes, and syncing local analytics to a backend—that unpredictable firing rate is a nightmare. You end up doing heavy computations on the main thread at random intervals, causing micro-stutters in the video playback and draining battery life on mobile.

Enter `requestVideoFrameCallback`

Chrome 83 introduced requestVideoFrameCallback (often abbreviated as rVFC), and it's now supported in all major Chromium-based browsers and Safari. Firefox is still dragging its feet on it, but for extension development and modern web apps, it's a game changer.

Instead of relying on a time-based event, rVFC hooks directly into the browser's rendering pipeline. It fires exactly once per rendered video frame.

const video = document.querySelector('video');

function trackFrame(now, metadata) {
    // metadata.mediaTime gives you the exact presentation timestamp
    // metadata.presentedFrames tells you how many frames have been shown

    const currentTime = metadata.mediaTime;

    // Do your analytics math here
    calculateEngagement(currentTime);

    // Queue the next frame
    video.requestVideoFrameCallback(trackFrame);
}

// Kick it off
video.requestVideoFrameCallback(trackFrame);

Why is this better?

It's battery efficient. It aligns with the display's refresh rate and the video's actual frame rate. If the video is 30fps, it fires 30 times a second. If the user pauses, it stops firing completely. No wasted cycles.
You get metadata. The callback passes a metadata object that includes mediaTime, presentedFrames, and expectedDisplayTime. This lets you detect if the video is actually dropping frames or buffering, which is incredible for diagnosing playback quality issues.

When I migrated CourseSpeed's core tracking loop from timeupdate to requestVideoFrameCallback, CPU usage during a 2-hour course dropped by about 14% on my M1 MacBook. That's not a marginal gain. That's the difference between a user keeping your extension enabled and uninstalling it because it's "slowing down their browser."

Finding the video tag in the wild

Of course, getting the analytics loop right is only half the battle. The other half is actually finding the <video> element.

E-learning platforms don't just hand you a clean <video src="..."> tag. They bury it. Udemy uses nested iframes. Coursera wraps things in complex React trees. Skillshare sometimes throws shadow DOMs into the mix.

If you're writing a content script, document.querySelector('video') is going to fail you 90% of the time.

I ended up writing a recursive walker that pierces same-origin iframes and open shadow roots. It's a bit brute-force, but it works reliably across the platforms I support.

function findVideoElements(root = document, results = []) {
    // Check current root
    const videos = root.querySelectorAll('video');
    videos.forEach(v => results.push(v));

    // Pierce open shadow DOMs
    const shadowHosts = root.querySelectorAll('*');
    shadowHosts.forEach(el => {
        if (el.shadowRoot) {
            findVideoElements(el.shadowRoot, results);
        }
    });

    // Pierce same-origin iframes
    const iframes = root.querySelectorAll('iframe');
    iframes.forEach(iframe => {
        try {
            // This will throw if cross-origin, which is fine, we just catch it
            const iframeDoc = iframe.contentDocument || iframe.contentWindow.document;
            findVideoElements(iframeDoc, results);
        } catch (e) {
            // Cross-origin iframe. 
            // If the platform uses postMessage for player control, 
            // you have to hook into that instead.
        }
    });

    return results;
}

You don't want to run this on every DOM mutation. Run it once on page load, and then set up a highly specific MutationObserver that only watches for the insertion of new iframe or video nodes.

A quick note on Firefox

Since Firefox doesn't support requestVideoFrameCallback yet, you need a fallback. Don't just revert to timeupdate blindly.

Use requestAnimationFrame combined with checking video.currentTime. It's not as perfectly synced to the video decoder as rVFC, but it ties your logic to the browser's paint cycle rather than the video element's internal clock, which is still vastly superior to the random firing of timeupdate.

function fallbackLoop() {
    if (!video.paused) {
        calculateEngagement(video.currentTime);
        requestAnimationFrame(fallbackLoop);
    }
}

Building tools that sit on top of other people's web apps is always a bit of a cat-and-mouse game. The platforms change their DOM structures, they update their player APIs, and things break. But by relying on low-level browser APIs like requestVideoFrameCallback instead of high-level DOM events, you anchor your code to the rendering engine itself.

It makes your analytics smoother, your extension lighter, and your Sunday morning coffee breaks a lot less frustrating.

4.2 million hours of video later: What StreamEnhancer telemetry taught me about human impatience

Hui — Thu, 09 Jul 2026 06:32:15 +0000

1.14x.

That was the exact median playback speed across all StreamEnhancer users last month.

I was sitting in a coffee shop on a Tuesday morning, running the monthly aggregation script against our anonymized telemetry database. I honestly expected the number to be higher. If you spend any time on tech Twitter or Reddit, you’d think everyone is watching tutorials at 2.5x speed. The internet loves to brag about media speedrunning. "I watch lectures at 3x, I'm basically a cyborg."

But the aggregate data told a completely different story. The reality of how people actually consume media is a lot more nuanced, and honestly, a lot more interesting than the hustle-culture speedrun narrative suggests.

When you build a tool like StreamEnhancer, you start with assumptions. I assumed people just wanted to go fast. The data proved me wrong. People don't just want to go fast; they want to go exactly as fast as their brain can process without feeling stressed.

Here is what 4.2 million hours of streaming telemetry actually looks like.

The Platform Personality Split

The 1.14x median is basically a useless number on its own because it mashes together completely different behaviors. When I broke the data down by platform, the variance was wild. It turns out, the platform dictates the psychology.

Netflix and Max users are "Set and Forgetters."
The median speed on Netflix is 1.25x. But more importantly, the average number of speed changes per session is just 0.8. People find a comfortable cruising speed for a narrative show, set it, and leave it alone. They are optimizing for a steady state.

YouTube users are "Active Pilots."
The median speed on YouTube is actually lower (1.10x), but the average number of speed changes per video is 4.6.

YouTube is a chaotic mix of content. A single 20-minute video might have a slow-talking intro, a dense technical explanation, a 60-second sponsor read, and a rapid-fire conclusion. Users are constantly riding the speed slider like a clutch pedal. They drop to 1.0x when the creator is showing complex code on screen, bump it to 2.0x for the sponsor pitch, and settle at 1.25x for the talking-head segments.

I thought I was building a tool for speedrunners. I actually built a pacing tool for people trying to manage their cognitive load.

The 0.05x Obsession

This was the biggest surprise in the dataset, and it completely changed my product roadmap.

When I first shipped StreamEnhancer, the speed controls jumped in 0.25x increments. 1.0 → 1.25 → 1.5. Standard stuff. That's how the native HTML5 <video> element usually handles it if you just hook into playbackRate.

In version 2.4, I added fine-grained control, allowing 0.05x steps. I figured maybe 10% of power users would care.

Instead, 71% of all speed changes became micro-adjustments.

People weren't jumping from 1.0 to 1.5. They were nudging.
1.10 → 1.15 → 1.20 → 1.15.

They were hunting for the exact threshold where the video felt fast, but the audio didn't start sounding artificial. Even with the preservesPitch property updates in recent Chrome versions (which does a great job preventing the "chipmunk" effect), pushing past 1.3x on certain audio tracks introduces weird phasing artifacts.

Users are highly sensitive to this. They will spend 15 seconds nudging the speed up and down by 0.05x just to find the "sweet spot" for a specific video's audio mix.

Here’s what a typical telemetry payload looks like for a YouTube session:

{
  "event": "speed_change",
  "platform": "youtube",
  "session_id_hash": "a8f9c2e...",
  "previous_rate": 1.10,
  "new_rate": 1.15,
  "delta": 0.05,
  "session_total_changes": 4,
  "time_in_video_sec": 342
}

Because of this data, I completely ripped out the "preset speed" buttons in the UI overlay. Presets are useless to an Active Pilot. I replaced them with a drag-slider that has subtle haptic-style snapping at 1.0x and 1.25x, but allows free-floating micro-adjustments everywhere else. Usage satisfaction scores jumped 22% in the next update.

The Rewind Paradox

Here's a weird correlation I found while digging through the event logs.

I track (anonymously) when the playback speed is increased, and when the user triggers a "rewind 10 seconds" event via our custom hotkeys.

If a user is watching at 1.5x or higher, the likelihood of them hitting "rewind 10s" within the next 30 seconds is 340% higher than if they are watching at 1.0x.

Obvious, right? You go too fast, you miss a detail, you rewind.

But here's the kicker that made me stop and think: they rarely drop the speed back down after rewinding.

They miss a concept at 1.5x. They rewind 10 seconds. They watch it again at 1.5x. If they miss it again, they rewind again at 1.5x.

Human attention is a funny thing. We would rather rewind three times at 1.5x speed (taking 20 seconds total) than just watch it once at 1.0x speed (taking 10 seconds). The math doesn't make sense for actual time saved, but it makes perfect sense psychologically.

The perception of moving fast matters more than the actual time saved. Dropping the speed to 1.0x feels like a penalty. It feels like you're "losing" the speedrun. Rewinding at 1.5x feels like you're just buffering your brain while maintaining your momentum.

What the numbers actually mean

Looking at analytics for a browser extension is different from looking at SaaS dashboard metrics. You aren't tracking churn or MRR. You're tracking human impatience, attention spans, and the subtle ways people try to hack their own biology to consume more information.

The data from StreamEnhancer taught me that when you build consumer tools, you shouldn't build for the extreme edge cases (the 3.0x speedrunners). You should build for the messy, nuanced middle. The people who just want to watch a Netflix show at 1.25x so they can go to sleep 12 minutes earlier, or the developer who wants to nudge a tutorial to 1.15x so it matches their reading speed.

Next time you watch a video and feel the urge to speed it up, pay attention to the exact number you choose. You're probably not just trying to save time. You're just trying to sync the internet to your own internal clock.

Bypassing the 2x speed limit on stubborn video players (and why `playbackRate` lies to you)

Hui — Thu, 09 Jul 2026 06:29:40 +0000

I was riding the train back from a conference last month, trying to finish a Coursera module on my laptop. The instructor was speaking at roughly the speed of a melting glacier. I hit the 2x button in the custom UI. It wasn't enough.

I opened dev tools, typed document.querySelector('video').playbackRate = 3.5, and watched the playback instantly snap back to 2.0.

If you've ever written a browser extension, a userscript, or just tried to hack your way through a mandatory compliance training video, you've probably hit this exact wall. The HTML5 video API makes speed control look trivial. But modern learning platforms don't just use raw <video> tags. They wrap them in heavy state managers.

Here is what's actually happening under the hood, and the DOM trick you need to bypass it.

The Synthetic Event Trap

Platforms like Udemy, LinkedIn Learning, and Coursera usually build their players in React or Vue. When you manually set video.playbackRate = 3.5 in the console, the browser does its job and fires a ratechange event.

The framework's synthetic event system catches that event, checks its internal state, realizes 3.5 is outside the bounds of their custom UI slider (which usually maxes out at 2.0), and forcefully clamps it back down by re-assigning the property.

You aren't fighting the browser. You're fighting the framework's reconciliation loop.

The Fix: Prototype Descriptor Hijacking

You can't just stop the ratechange event propagation reliably without breaking the player's internal analytics or UI updates. Instead, you need to intercept the property setter itself.

By overriding the property descriptor on the HTMLMediaElement prototype, you can silently ignore the framework's attempts to clamp the speed.

const targetSpeed = 3.5;
const proto = HTMLMediaElement.prototype;

// Grab the browser's native descriptor
const originalDescriptor = Object.getOwnPropertyDescriptor(proto, 'playbackRate');

Object.defineProperty(proto, 'playbackRate', {
    get() {
        return originalDescriptor.get.call(this);
    },
    set(value) {
        // If the platform tries to clamp it to their UI max (usually <= 2.5), 
        // and we've flagged this video for override, just ignore the set.
        if (value <= 2.5 && this.__speedOverrideActive) {
            return; 
        }
        originalDescriptor.set.call(this, value);
    },
    configurable: true
});

// Apply the override to the specific video instance
const video = document.querySelector('video');
video.__speedOverrideActive = true;

// Now set the speed. The framework's subsequent attempts to reset it to 2.0 will fail silently.
video.playbackRate = targetSpeed;

A quick heads up if you're building an extension: a lot of these platforms render their video player inside an iframe. document.querySelector('video') will return null on the top-level window. You'll need to target the iframe's contentDocument first, assuming it's not blocked by cross-origin restrictions.

Don't forget the Chipmunk effect

There's a secondary issue when you push past 2.0x or 2.5x.

To save CPU cycles, some platforms explicitly disable audio pitch correction when the playback rate changes. In Chrome 130+, the standard property is preservesPitch, but older WebKit/Blink implementations still rely on vendor prefixes. If your instructor suddenly sounds like an angry chipmunk at 3x speed, force the pitch preservation:

video.preservesPitch = true;
video.webkitPreservesPitch = true; // Safari/older Chrome
video.mozPreservesPitch = true;    // Firefox

It’s a tiny detail, but it makes the difference between a usable 3x speed and an unlistenable one.

Tracking the "Rewind Density"

Getting the video to play at high speeds is only half the battle if you actually want to learn something.

When I was wiring up the core logic for CourseSpeed, I realized that just forcing a 3x playback rate was useless if the user had to constantly pause or rewind. I needed to know if the speed was actually sustainable for the content being watched.

I ended up implementing a metric I call "rewind density."

Instead of just logging the current playback speed, the analytics hook tracks the delta between high-speed playback and rewind events (specifically, dropping the speed back to 1.0x or hitting the left-arrow key to jump back 10 seconds).

If you're building your own learning tools or analytics dashboards, don't just track average watch speed. Track how often the user is forced to abandon that speed. A video watched at 2.5x with zero rewinds is a great fit. A video watched at 2.5x with a rewind every 40 seconds means the content is too dense, and the user is just creating an illusion of productivity.

The DOM hacks get the video to play fast. But paying attention to how the user interacts with the player is what actually makes the speed useful.

The 1x1 Pixel That Broke My Streaming Extension

Hui — Thu, 09 Jul 2026 04:17:02 +0000

Saturday morning, 9 AM. I was at the kitchen island, making a pour-over coffee and testing StreamEnhancer on my MacBook while chopping onions for a frittata.

I had the extension running, playing an episode of The Mandalorian on Disney+ at 1.5x speed. Everything was smooth. The audio pitch correction was holding up, the custom UI overlay was tracking the progress bar perfectly. Feeling confident, I hit my hotkey to bump the speed to 2.0x.

Fourteen minutes later, the video froze. The audio cut out with a harsh digital stutter, and a generic "Something went wrong" error replaced the player.

I figured it was a memory leak. StreamEnhancer injects a fairly heavy UI overlay and listens to a lot of media events to sync the speed indicators across YouTube, Netflix, Prime, Max, and Disney+. I restarted Chrome 128, loaded the page, and tried again.

Exact same thing. 14 minutes at 2.0x, then death.

I dropped the speed back to 1.5x. The episode finished without a hitch.

The naive assumption

My initial code for applying the playback speed was, frankly, lazy. When you're building a cross-platform tool, you want to write the least amount of platform-specific code possible.

// The "please just work" approach
const videos = document.querySelectorAll('video');
videos.forEach(v => {
    v.playbackRate = targetSpeed;
});

I assumed a streaming page would only have one active <video> element. Or at least, only one that actually mattered. YouTube behaves exactly like this. Netflix is a bit more complex with its canvas rendering for certain UI elements, but the core media tag is straightforward.

But Disney+ and Max? They are a different beast.

I opened DevTools, cleared the console, and just searched the DOM for <video>.

There were three of them.

The main player. videoWidth was 1920.
A hidden element used for ad-tracking and analytics beacons.
A 1x1 pixel video, positioned absolutely off-screen, with no audio.

The accidental discovery

I paused the main movie. The 1x1 pixel video kept playing. I muted the tab. It kept playing.

I dug into the network tab and watched the requests. That tiny, invisible video tag was streaming a continuous, low-bitrate media chunk. It turns out, this is a DRM heartbeat.

When you stream protected content, the browser uses Encrypted Media Extensions (EME) to talk to a Content Decryption Module (CDM) like Widevine or PlayReady. The platform needs to verify the session is still valid and the environment hasn't been tampered with. Instead of relying purely on standard XHR/Fetch network requests—which can be easily intercepted, mocked, or blocked by ad-blockers—some platforms tie the license renewal to the playback lifecycle of a secondary, heavily monitored media element.

The heartbeat video plays silently in the background. When it hits a certain timestamp, it triggers a license renewal.

Here is where my extension broke everything.

When I forced playbackRate = 2.0 on every video tag in the DOM, I sped up the DRM heartbeat.

The heartbeat video reached its renewal checkpoint twice as fast. The CDM fired a license renewal request to the server. But the server-side logic expects these renewals at specific real-world intervals. When it started receiving them at 2x speed, the platform's sanity check flagged the client as anomalous. It assumed the environment was tampered with, or the license simply burned through its validity window too fast.

Result: Session revoked. Black screen.

Isolating the primary media

I didn't want to mess with the DRM heartbeat. I just wanted to speed up the movie. I needed a reliable way to identify the actual primary video tag across five different streaming platforms, ignoring the ghosts in the DOM.

Checking videoWidth > 0 wasn't enough. Ad trackers can have dimensions. Checking if the element is visible in the viewport wasn't enough either, because picture-in-picture modes and minimized players change the bounding client rect.

I ended up writing a scoring function for StreamEnhancer that runs every time the URL changes or the player initializes.

function findPrimaryMediaElement() {
    const candidates = Array.from(document.querySelectorAll('video'));
    let primary = null;
    let maxScore = -Infinity;

    for (const video of candidates) {
        let score = 0;

        // 1. Dimension check (The most reliable filter)
        // Heartbeats and trackers are usually tiny
        if (video.videoWidth >= 800 && video.videoHeight >= 400) {
            score += 50; 
        } else if (video.videoWidth < 100) {
            score -= 100; // Heavily penalize the 1x1 pixels
        }

        // 2. Rendered area check
        const rect = video.getBoundingClientRect();
        const area = rect.width * rect.height;
        score += (area / 10000); 

        // 3. DOM hierarchy check
        // Primary players are usually nested deep in specific player containers
        // while trackers are often injected at the root body level
        let depth = 0;
        let node = video;
        while (node.parentElement) {
            depth++;
            node = node.parentElement;
        }
        score += depth;

        if (score > maxScore) {
            maxScore = score;
            primary = video;
        }
    }

    return primary;
}

It’s not perfect. Every time Netflix or Prime updates their player architecture, I have to tweak the weights. Prime Video, for instance, sometimes wraps their main video in a shadow DOM during initial load before hydrating it into the main document, which required adding a MutationObserver just to catch the element when it finally surfaces.

But the scoring system solved the DRM crash. By only applying playbackRate to the highest-scoring element, the 1x1 pixel heartbeat continues to play at 1.0x, the server stays happy, and the user gets to watch their show at 2.5x without getting kicked out.

The web is a battlefield

Before building StreamEnhancer, I thought of the DOM as a document. A tree of elements that represent what the user sees.

Working across Netflix, Max, Disney+, and the others taught me that on modern streaming sites, the DOM is a battlefield. There are decoys, trackers, heartbeats, and hidden state machines all fighting for resources and verifying each other.

When you build tools that interact with these platforms, you aren't just manipulating a video tag. You're stepping into a highly paranoid ecosystem. Sometimes, the most important part of your code isn't the feature you're building, but the invisible things you've learned to leave alone.

I thought building a video speed controller would take a weekend. The analytics nearly broke me.

Hui — Thu, 09 Jul 2026 03:10:27 +0000

It was 2 AM on a Tuesday, and I was staring at my CourseSpeed dashboard looking at a graph that claimed I had just finished a 14-hour AWS certification course in 47 minutes.

I hadn't. I was just testing the 16x speed toggle. But my analytics engine thought I was a god.

When I started building CourseSpeed—a browser extension to inject custom playback speeds and track learning analytics across Udemy, Coursera, LinkedIn Learning, and Skillshare—I thought the hard part would be the UI. It wasn't. Injecting a floating control panel and setting document.querySelector('video').playbackRate = 2.5 takes about ten lines of JavaScript.

The actual nightmare was the learning analytics. Specifically, accurately tracking effective watch time versus wall-clock time across wildly different Single Page Applications (SPAs).

The naive approach that burned me

My first pass at the analytics tracker was straight out of MDN. I listened to the standard HTML5 video events.

// The approach that worked perfectly in my head
const video = document.querySelector('video');

video.addEventListener('ratechange', (e) => {
  sendAnalytics({ type: 'speed_change', rate: e.target.playbackRate });
});

video.addEventListener('timeupdate', () => {
  logWatchTime(video.currentTime, video.playbackRate);
});

This worked flawlessly on Udemy. Then I opened LinkedIn Learning. The dashboard flatlined. Then I tried Coursera. The time spent was wildly inaccurate, drifting by minutes over an hour.

I spent three days debugging this, tearing my hair out over console logs.

Here is what I missed: modern learning platforms don't just drop a raw <video> tag on the page and leave it alone. They wrap it in custom players, throttle events to save CPU, and dynamically destroy and recreate the DOM node when you skip chapters or when the SPA router transitions.

My event listeners were getting orphaned. Or worse, they were firing with stale data because the platform's custom wrapper was dispatching synthetic timeupdate events that didn't reflect the underlying HTML5 video element's true state when the playback rate was manipulated.

Stop trusting the DOM events

I had to rip out the event listeners. If I wanted reliable analytics, I needed to observe the DOM for element swaps and poll the video state myself.

I built a VideoTracker class. Instead of waiting for the platform to tell me the video changed, I used a MutationObserver to watch the specific player wrapper containers.

const observer = new MutationObserver((mutations) => {
  for (const mutation of mutations) {
    if (mutation.type === 'childList') {
      const newVideo = mutation.target.querySelector('video');
      if (newVideo && newVideo !== this.currentVideo) {
        this.attachToVideo(newVideo);
      }
    }
  }
});

// We observe the highest stable container, not the whole document body
const playerRoot = document.querySelector('[data-player-root]') || document.body;
observer.observe(playerRoot, { childList: true, subtree: true });

This solved the orphaned listener problem. When Coursera swapped the video node during a module transition, my tracker caught it, detached the old state, and latched onto the new <video> element within milliseconds.

But then I hit the background tab wall.

The background tab throttling trap

Here’s the real kicker. When you switch tabs to read documentation while a course plays in the background, Chrome (specifically around version 120 and later) aggressively throttles setInterval and setTimeout in background tabs to save battery and CPU.

My analytics pings were getting delayed. The browser would batch them up and send massive, inaccurate chunks of "watch time" when the tab regained focus. If a user left a 2x speed video running in the background for an hour, my extension might only log 15 minutes of actual progress because the setInterval ticking my internal clock was being put to sleep.

I tried switching the internal clock to requestAnimationFrame. That paused entirely in background tabs.

The fix was moving the ticking clock to a Web Worker. Web Workers run on a separate thread and aren't subjected to the same aggressive throttling as the main thread's timers.

The architecture ended up looking like this:

The Web Worker ticks every 1000ms and posts a message to the main thread.
The main thread receives the tick, reads video.currentTime and video.playbackRate directly from the DOM.
The main thread calculates the delta and updates the local analytics state.

// worker.js
let intervalId;

self.onmessage = function(e) {
  if (e.data === 'start') {
    intervalId = setInterval(() => {
      self.postMessage('tick');
    }, 1000);
  } else if (e.data === 'stop') {
    clearInterval(intervalId);
  }
};

It feels like overkill for a browser extension, but it completely eliminated the background-tab drift. The analytics dashboard finally matched reality. A 14-hour course watched at 2x speed now correctly logged as 7 hours of effective learning time, regardless of whether the user was actively staring at the tab or reading MDN docs in another window.

Building tools that live on top of other people's SPAs means you are constantly at the mercy of their DOM updates and browser performance optimizations. You can't just assume the standard APIs will behave the way the spec says they should in a vacuum. You have to build defensively, assume the DOM will mutate out from under you, and never trust a setInterval in a background tab.

DEV Community: Hui

I built an AI-powered video speed controller for online courses

What it does

The tech stack

What I learned

The results so far

The 1.08x Anomaly: What 4 Million Playback Events Taught Me About How We Actually Watch TV

The "Invisible Speedup" and the Audio Pipeline

The Bimodal Reality of YouTube

The 14-Second Rule and the "Subtitle Drop"

Building for the Margins

The 412% Illusion: What 50,000 hours of playback data taught me about "speed learning"

The Micro-Rewind Tax

The Platform Personality Split

The "Pause-to-Completion" Ratio

Data over assumptions

The unglamorous reality of maintaining a streaming extension as a solo dev

The CWS Review Tug-of-War

The "Is Netflix Broken or Is It You?" Support Queue

The reality of the solo dev maintenance loop

Stop relying on `timeupdate`: Building battery-efficient video analytics in the browser

The timeupdate trap

Enter requestVideoFrameCallback

Finding the video tag in the wild

A quick note on Firefox

4.2 million hours of video later: What StreamEnhancer telemetry taught me about human impatience

The Platform Personality Split

The 0.05x Obsession

The Rewind Paradox

What the numbers actually mean

Bypassing the 2x speed limit on stubborn video players (and why `playbackRate` lies to you)

The Synthetic Event Trap

The Fix: Prototype Descriptor Hijacking

Don't forget the Chipmunk effect

Tracking the "Rewind Density"

The 1x1 Pixel That Broke My Streaming Extension

The naive assumption

The accidental discovery

Isolating the primary media

The web is a battlefield

I thought building a video speed controller would take a weekend. The analytics nearly broke me.

The naive approach that burned me

Stop trusting the DOM events

The background tab throttling trap

The `timeupdate` trap

Enter `requestVideoFrameCallback`