How ViewerVitals works

ViewerVitals loads a live Twitch channel in your browser using Twitch's own embedded player, watches it for thirty seconds, and reports what arrived.

The test, step by step

1. You give it a channel name or a twitch.tv link.
2. It checks with Twitch that the channel is actually broadcasting. An offline channel cannot be measured.
3. The Twitch player loads, muted. Muted playback is never blocked by a browser, which is why the test starts that way — you can turn sound on once it is running.
4. Five seconds are allowed for playback to settle. Readings taken during start-up describe start-up, not the stream.
5. For the next thirty seconds it takes one reading per second directly from the player.
6. All thirty readings are averaged into a report, along with the worst value seen for each one.

The report uses the whole thirty seconds, not the last reading. A stream that wobbled badly for ten seconds and then recovered should not be able to present itself as healthy.

Where each number comes from

This distinction matters enough that the interface marks it. Some figures are read straight off the Twitch player. Others are ViewerVitals deciding what those figures mean together — and those are labelled calc wherever they appear.

Read from the player

• Delay behind live — how far behind the broadcaster this playback is running.
• Frame rate — frames per second being rendered.
• Dropped frames — frames your browser received but could not paint.
• Quality received — the video resolution actually arriving.
• Playback buffer — seconds of video held in reserve.
• Playback bitrate — the data rate of the stream being received.

Worked out by ViewerVitals

• Connection health — delay, buffer and dropped frames combined into one figure.
• Smoothness — how close the frame rate held to its target, penalised for how much it moved around.
• Overall rating and its word — Excellent through Very poor.
• Primary limitation — the one thing most worth investigating.

None of the calculated figures are Twitch classifications. They are our display rules, and we will keep adjusting them as we see more real streams.

The quality ladder, and why it matters more than the resolution

This is the part most stream testers get wrong, and it is worth understanding before you act on any result.

Twitch's player chooses a quality automatically based on the viewer's connection. So if a test says “you received 480p”, that usually means the browser running the test decided 480p was safest — not that the broadcaster sent 480p. A streamer who reads that as a broadcast problem will go and change OBS settings that were never wrong.

ViewerVitals asks the player for the full list of qualities Twitch is offering for that channel, and shows it with the received one highlighted. That single readout separates three genuinely different situations:

• Higher qualities are available but you got a lower one. A receiving-side result. Your connection or player setting, not the broadcast.
• The highest quality on offer is itself low. A broadcast-side result. No viewer can receive more than is being sent.
• Only one quality is on offer. Twitch is not transcoding that broadcast. Viewers whose connection cannot carry the full quality have nothing to drop down to, so they buffer instead of degrading gracefully.

That last one is invisible to almost everybody, is common on Affiliate channels, and is frequently the real explanation behind “some of my viewers say it keeps buffering.”

What it cannot tell you

The path between a broadcaster and a viewer has four parts: the broadcaster's encoder and upload, Twitch's own infrastructure, the viewer's network, and the viewer's browser and device. ViewerVitals measures the far end of that chain. It cannot see where in the chain a problem started.

That is why every result is written as an investigation path rather than a diagnosis, and why each one ends with a way to test the theory. Almost always that means running the test again from somewhere else. A problem that follows the stream across two networks and two devices is upstream. A problem that only appears on one is local to it.

One clean test is one data point. Three tests from three places are evidence.

What about Twitch's own ads?

If a Twitch ad plays during the thirty seconds, the player starts describing the ad rather than the broadcast — different resolution, and no broadcaster delay to report, because an ad has no broadcaster. ViewerVitals tries to spot that and leaves those seconds out of the results, telling you when it has. If a report looks strange and mentions an ad break, run it again.