Media
4 items
Description
A watchtower over your video playback: real resolution and FPS, dropped frames, buffer, live latency, codec, DRM and CDN. Mirqab is a "stats for nerds" panel for any HTML5 video in Chrome. It answers one question quickly: is this really 1080p50 — and is it playing correctly? Click the toolbar icon and a side panel opens. It stays open and keeps measuring while you work, on any site, with no changes to the page. WHAT IT SHOWS • Quality — the decoded resolution and measured frame rate as one label, such as 1080p50, plus the size the video is actually drawn at and whether it is being upscaled. • Optimal resolution — the highest rung the player's current size warrants, so you can see when you are being served less than the viewport deserves. • Frames — decoded, dropped, the drop rate, and a rolling 10-second rate, which is what matters during a live event. • Buffer — seconds ahead and behind, and the buffered ranges. • Live — true end-to-end latency, distance behind the live edge, and the target hold-back the stream itself declares, so you can see whether the player is where the stream asked it to be. • Stream — HLS, MPEG-DASH or progressive; MSE; the detected player library; segment duration; measured and declared bitrate. • Codec — name, profile and level, bit depth, chroma, colour primaries, transfer function, and HDR10 or HLG where the stream signals it. • Network — estimated throughput, requests in flight, segment size and download time, and the CDN provider and host. • ABR ladder — every rung parsed from the manifest with its bitrate, and a marker on the one actually playing. • Stream URLs — the manifest, the active rendition's playlist and the newest segment, each copyable, so the stream can be opened in an external player for a second opinion. Encrypted streams are labelled, since a key system means the URL alone will not play. • Quality of experience — startup time, rebuffer count and total duration. • DRM — key system, robustness and session types. • Tracks — which caption and audio tracks exist, which is active, and whether caption cues are still arriving. A feed that stops mid-match is labelled rather than left looking fine. • Player report — where a player publishes Common Media Client Data, Mirqab shows the player's own reported buffer, throughput and bitrate beside its own measurement of the same thing. Where the two disagree, the player's estimate is the one to doubt. The session identifier is copyable, which is what a delivery team needs to find the session in their logs. • Manifest health — the live playlist watched across refreshes: how long since the window last advanced, the refresh interval against the declared target duration, missed segments, and timeline breaks appearing upstream. A playlist that has stopped advancing is visible before the buffer drains. • Startup breakdown — startup split into page load, manifest fetch, licence acquisition and first frame, because a single total does not say which stage to fix. • Decode capability — whether this machine can decode each rung at all, smoothly, and power-efficiently. It separates "your computer cannot manage that resolution" from "the player chose not to serve it". • History — 60-second sparklines for throughput, bitrate, buffer and network activity, because a single number hides a dip. • Session timeline — one row per second for the whole session, exported as CSV: frame rate, resolution, buffer, latency, throughput, drops and rebuffers. This is what turns "it looked bad in the second half" into a timestamp. HOW IT MEASURES Frame rate is counted from created frames over media time, so it still reports 50 fps while the display is dropping frames — which is exactly the case worth catching. A separate presented-per-second figure shows what actually reached the screen. Live latency is derived from the stream's own wall-clock anchor (EXT-X-PROGRAM-DATE-TIME in HLS, availabilityStartTime in DASH), not merely the distance to the newest segment the player knows about. Implausible values are rejected rather than displayed. Codec and colour facts are read from the SourceBuffer mime type and RFC 6381 codec string, and DRM from the Encrypted Media Extensions key system. Nothing is inferred from filenames. Where a player publishes its own client data, it is read from the request the player was already making. Nothing is requested on its behalf, and nothing is added to it. Licence acquisition is timed by observing when the request started and finished. No request body and no response body is ever read, so no licence, key or challenge is accessible to this extension. Where Chrome does not expose a value reliably, Mirqab prints "Unavailable" instead of guessing. ALERTS Mirqab raises the alarm rather than waiting to be read. Eight conditions are watched: rebuffering, a buffer under one second, more than two percent of frames dropped in the last ten seconds, latency outside its band, playing below the resolution the player's size warrants, a caption feed that has stopped delivering cues, a live playlist that has stopped advancing, and segments that rolled out of the live window before the player fetched them. The last two are worth singling out. Every other alert reports something the viewer has already experienced. A playlist that has stopped advancing means the problem is upstream of the player, and it is visible before the buffer drains. Each one has to persist before it counts, because a single noisy sample is not an incident. A resolution drop waits ten seconds, since an adaptive player switching rung after a window resize is expected. Rebuffering fires almost immediately, since it is unambiguous. When something fires, it appears at the top of the panel, in the event log with a timestamp, as a tinted edge on the in-page overlay, and as a mark on the toolbar icon. One setting turns all of it off. THREE WAYS TO SEE IT • Side panel — the default. Docked, stays open, shows everything, and follows the active tab. • In-page overlay — a draggable panel on the page itself, and the only option during fullscreen playback, where Chrome hides its own UI. • Popup — a compact summary, if you prefer it to the panel. A keyboard shortcut toggles the in-page overlay, which is the only way to reach it once video is fullscreen and the toolbar is hidden. Copy Stats puts the current readings on the clipboard as text, Export JSON saves the full snapshot, and Export Timeline saves the second-by-second recording as CSV — all three are better than describing a problem in prose. BUILT FOR LIVE STREAMING Mirqab was written while debugging live sports: 1080p50 that silently plays at 720p, frame drops that look like a stuttering encoder, a CDN edge that went cold, latency that crept past a minute. Those are the cases it is tuned for. It works on standard HTML5 video with no site-specific integration: adaptive streaming over HTTP, progressive files, and encrypted playback. The page itself is never modified. PRIVACY Everything stays in your browser. No analytics, no telemetry, no external requests, and no stream URLs, video data or browsing history stored or transmitted. Playback and request statistics live in memory and are dropped when you navigate away or close the tab. Local storage holds only your interface preferences. Mirqab never touches DRM keys, licences or media content. It reads metadata the browser already exposes, and it does not modify, block or redirect any request. KNOWN LIMITS • The side panel is hidden while video is fullscreen, because Chrome hides all browser UI there. Use the in-page overlay for fullscreen. • Opening the side panel narrows the page, which changes the video's rendered size and can make an adaptive player switch rung. That is real behaviour, not a measurement error. • Cross-origin segments served without a Timing-Allow-Origin header hide their byte counts from Resource Timing; sizes then come from the Content-Length header, and read Unavailable if that is absent too. • Colour primaries and transfer function are only carried by VP9 and AV1 codec strings. For H.264 and HEVC, dynamic range falls back to the manifest and only bit depth is inferred. • Startup time cannot be measured if you enable the overlay after playback has already begun. • The session timeline begins when a Mirqab surface first reads the page, not when the page loaded. Open it before the event starts if you want the whole thing. • Chrome does not expose the audio track list to extensions, so the count reads Unavailable rather than zero. Track layout still comes from the manifest. • Client data is only visible for players that publish it and that fetch media through standard browser request APIs. Many do not, and the section reads Unavailable in that case. • Manifest health needs several playlist refreshes before it can judge anything, and reads Unavailable until it has them rather than calling a stream healthy it has not watched. • Decode capability is what the platform reports, not a measurement. A resolution reported as smooth can still drop frames under load, which is what the frame counters are for. Requires Chrome 114 or later.