Whether transcoding to the same quality target uses more energy on CPU or GPU — and whether the faster path is also the more efficient one.

Encoding a 2-minute 4K clip (Meridian, Netflix Open Content, CC BY 4.0) to 1080p — once in software on the CPU and once as a full GPU pipeline (hardware decode + scale + encode via hevc_nvenc, or av1_nvenc on the AV1 chip). Same source. Same per-codec bitrate target. Tapo P110 sampled at 1-second intervals on each of two staggered meters throughout.

The same measurements, flipped into the operator’s question: given an energy budget and a quality target, how much video can you actually ship? Pick a VMAF target (92 by default — the figure transcoding farms cite) and OWL shows how many hours each codec and hardware path buys you, from real measured curves.

It turns Wh-per-minute into planning — the H.264 / HEVC / AV1 and CPU-vs-GPU decision, sized to a budget, measured rather than estimated.

Step 1 spent energy to shrink video. This flips the question: what does it cost to make video better? A machine-learning enhancer on the lab GPU takes a rough, low-resolution clip and denoises and upscales it — and OWL meters the watt-hours at the wall and scores the quality before and after, like every other workload on the bench.

The showcase below: real 2005 phone footage — 544×408, heavily compressed — machine-upscaled to 4K for a couple of watt-hours. Watch the two previews, then read what that difference cost in the card underneath.

Operators handed an imperfect feed can weigh enhancing it against its real energy cost — and see where enhancement earns its watts and where it just burns them.

How much energy each generated token costs — and how model size translates into energy use per unit of output.

Running a fixed prompt (T3, long generation — a technical briefing on network energy attribution) through Qwen3 4B cold: model unloaded before baseline so we capture the true first-request cost. GPU inference via Ollama (CUDA).

How much energy one AI-generated image costs — measured end to end on real hardware, not estimated from TDP or cloud benchmarks.

Running SD-Turbo (stabilityai/sd-turbo, CPU, 8 steps, 512×512) with a randomly modified prompt — the colour modifier changes each run to prove the image is generated live, not replayed from cache.

Whether retrieval-augmented generation (RAG) — searching a local corpus before answering — costs meaningfully more energy than plain inference, and see the difference in context size the model must process.

Running three modes back-to-back on Qwen3 4B: baseline (no retrieval), RAG (small corpus), and RAG Large (with re-ranking). Same question, same model, same hardware — only the retrieval pipeline changes.

Not every measurement we take is equally trustworthy. System noise — Tapo P110 quantisation, OS jitter, Wi-Fi polling variance — is real. A task that adds a small delta above baseline might be signal or artefact. We need a principled way to say which.

Every result carries a traffic light. As of CR-028 Phase 2 it's a per-run confidence interval — "can this run be told apart from idle?" — not a fixed watt rule. confidence = Φ(ΔW / SE), SE from this run's noise + the calibrated idle floor

Fixed thresholds (e.g. "5W = green") don't adapt to the machine's actual noise level. Instead we take this run's own baseline + task power samples, form a standard error on ΔW (worst case of the run's observed noise and the calibrated idle floor, plus a drift term), and turn ΔW into a one-sided confidence that the task draws above idle. A short run can't go green on a couple of lucky readings — it also needs enough task polls.

On any result page, click a 🟢 🟡 🔴 badge for a quick reminder of the formula.

Everything so far measured the server. But encode energy is paid once per title — decode energy is paid per viewer, per hour. OWL's decode rig applies the same method (idle baseline, ΔW, confidence flags) to real playback devices: two Raspberry Pis and a Google TV streamer, each on its own milliwatt meter, sharing one measured screen.

Same 1080p60 file, local delivery, display attached, all rows 🟢 with in-band black/white markers verifying the screen showed real content:

A purpose-built streaming box plays the same video for 4–7× less energy than a general-purpose board — and a device generation that drops a decoder block (Pi 5) loses its efficiency to software. Invisible on any spec sheet; visible at the wall.

The rig is a public page: live device tiles, recent runs, and every result's raw per-second samples as CSV/JSON. Open the decode rig ›