OWL ← HomeOWL FindingsBeta · under development
Curated, citable measurements from the Greening of Streaming bench. Each finding links to its source measurement at live-run fidelity, with scope, methodology, and a copy-paste citation.
🟢Playing the same video, display attached: a fixed-function streaming box draws 4–7× less than a general-purpose board — even against the board's own hardware decoderv1 · 2026-07-30
BBB 1080p60 H.264, local file, screen on, marker-verified: Google TV +0.30 W · Pi 400 hw +1.32 W (4.4×) · Pi 400 sw +1.96 W (6.5×) · Pi 5 sw +2.03 W (6.8×). All 🟢.
🟡Which codec is cheapest to decode has no silicon-independent answer: a wash on hardware, up to ~60% spread in software — and the measurement regime can flip the rankingv1 · 2026-07-29
Hw (Google TV): codec spread ≤0.08 W. Sw at 1× (both Pis): h264 +1.57 < av1 +1.83 < hevc +2.56 W. Sw saturated: ranking inverts (av1 +4.15 < h264 +5.13 W).
🟢A hardware decoder cuts client decode power ~3.6× — and having the silicon isn't enough: stock software must be able to reach itv1 · 2026-07-29
Pi 400, same board, same 1080p60 file — H.264 hw +0.35 W vs sw +1.25 W playing (3.6×); +0.64 vs +2.62 W saturated (4.1×). Pi 5 (block dropped): +1.57 W.
🟢NVIDIA GPU Boost over-clocks the NVENC transcode pipeline into a wasteful zone: ~9-12% more energy for identical encode time and VMAF. Pinning the SM clock removes it — and makes GPU energy reproducible across reboots and ambient temperature.v1 · 2026-06-20
h264_nvenc 1080p, Meridian 120s: full boost (SM 2872 MHz) = 0.280 Wh in 12.1 s. Pinned at the knee (SM 2572 MHz) = 0.255 Wh in 12.5 s — 9% less energy, same VMAF, +0.4 s.
🟢AI upscaling to 4K pays off where content is worst: restoring degraded SD buys ~20× more quality per Wh than polishing clean HD — and re-processing pristine 4K buys nothing at the highest energy costv1 · 2026-06-19 (first 2026-06-12)
SD-dirty → 4K: +2.1 NR-VQA for 14.8 Wh · HD-clean → 4K: +0.23 for 11.9 Wh · pristine 4K → 4K: ±0.0 for 44 Wh (45 s / 60 fps clips, all 🟢)
🟢Input-master bitrate has no measurable effect on H.265 re-encode energy (CPU 1.7 %, GPU 4.9 % spread); input-codec has a small effect carried by the AV1-as-source case (CPU 3.4 %, GPU 10.3 % spread)v1 · 2026-05-26
Re-encode `h265_both` on 2-min 1080p siblings · bitrate axis (1.3 → 14.6 Mbps): flat · codec-of-origin axis (H.264 5.1 / H.265 3.4 / AV1 2.3 Mbps): AV1 source raises GPU energy by ~10 %
🟢On Meridian-120s at the ABR ladder, GPU encodes are 2.0× to 4.4× more energy-efficient than CPU encodes; H.265 GPU produces the lowest-energy file, AV1 GPU the fastestv1 · 2026-05-22
Per-codec ABR · H.264 4 Mbps · H.265 2 Mbps · AV1 1.5 Mbps — most efficient: H.265 GPU (0.30 Wh, 28.4 MB, VMAF 92.0) · fastest: AV1 GPU (15.1 s, 0.32 Wh, VMAF 90.8)
🟢AV1 hardware uses ~55% less energy than software at 1500 kbps, but loses ~2 VMAF points and produces ~40% larger filesv1 · 2026-05-22
1500 kbps ABR — SVT-AV1: 0.71 Wh · VMAF 92.74 · 14.5 MB · 34 s av1_vaapi: 0.32 Wh · VMAF 90.79 · 20.3 MB · 15 s
🟡Cold LLM inference on the GoS1 bench: TinyLlama (1.1B) at ~0.07 mWh/token, Mistral 7B at ~0.96 mWh/token — both on the pre-S30 ladderv1 · 2026-05-08 (first 2026-04-24)
T3 cold inference · TinyLlama 0.0718 mWh/token 🟡 · Mistral 7B 0.9639 mWh/token 🟢 · ratio ≈ 13× per token
🟡RAG retrieval surfaced the correct GoS REM papers across three models; the smallest model (TinyLlama 1.1B) then generated a hallucinated answer combining the correct retrieval with an adjacent JRC chunkv1 · 2026-04-29
Same top-k=3 retrieval, three models — TinyLlama 1.1B hallucinated 'European Commission framework'; Gemma 3 12B and Phi-4 14B stayed faithful to the GoS source
🟢SD-Turbo CPU image generation on the GoS1 bench: 0.21 Wh per image at 8 inference steps, 512×512v1 · 2026-04-29
SD-Turbo on Ryzen 9 7900 CPU · 8 steps · 512×512 · 0.21 Wh / image · ΔW ≈ 30 W during the run