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.
🟢Apple TV 4K (2017, A10X): H.264/HEVC play at the same power; AV1 and VP9 both cost +29% more — the third silicon-coverage instancev2 · 2026-09-22 (first 2026-08-26)
Device-total W, VLC for tvOS, n=3 per codec across three content families: H.264 4.10 W, HEVC 4.07 W, AV1 5.25 W, VP9 5.28 W — hardware pair (VideoToolbox) flat, software-fallback pair +1.19 W (+29%), gap stable per content (+1.0 to +1.3 W).
🟡Which codec is cheapest to decode has no silicon-independent answer: near-flat on one hardware decoder but resolvable on another, up to ~60% spread in software — and the measurement regime can flip the rankingv2 · 2026-09-22 (first 2026-07-29)
Hw (Google TV): codec spread ≤0.08 W, unresolvable. Hw (Allwinner H618, n=3): H.264 +1.073 > HEVC +0.966 ≈ VP9 +0.971 W — H.264 dearer by 0.107 W, separated (t=4.96). Sw at 1× (both Pis): h264 +1.57 < av1 +1.83 < hevc +2.56 W. Sw saturated: ranking inverts.
🟢A hardware decoder cuts client decode power ~3.7× — and having the silicon isn't enough: stock software must be able to reach it, while having none at all can put the codec out of reach entirelyv2 · 2026-09-22 (first 2026-07-29)
Pi 400, same board, same 1080p60 file — H.264 hw +0.41 W vs sw +1.50 W playing (3.7×, n=6/3); +0.59 vs +2.72 W saturated (4.6×, n=3). Pi 5 (block dropped): +1.57 W.
🟢On modern hardware-decode set-top boxes, an hour of 1080p playback costs ~0.25–0.65 W over the home screen — and the content moves that number more than the codec doesv2 · 2026-09-22 (first 2026-08-16)
Google TV Streamer + Fire TV Stick 4K, 1080p over LAN, 1100–3540 s windows, all 🟢: BBB (animation) +0.60/+0.64/+0.60 W (GTV h264/hevc/av1), +0.59/+0.44/+0.52 W (Fire TV); live-action Meridian/Kranjska +0.25–0.46 W. Codec spread within a content ≤0.1 W; content spread ~0.35 W.
🟢Playing the same video, display attached: THIS fixed-function streaming box draws 4–7× less than a general-purpose board — even against the board's own hardware decoder; a cheaper box is not in the same classv2 · 2026-09-22 (first 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 🟢.
🟢Looping a 2-minute excerpt measures the same as playing the continuous original; a 30-second loop does not on every boxv1 · 2026-09-03
Four STBs, one 600 s H.264 1080p60 encode of Big Buck Bunny, n=3 paired passes: its 120 s excerpt ×5 sits within 0.02 W of the continuous 600 s (CIs straddle zero, ±0.03–0.04 W bound on three boxes); its 30 s excerpt ×20 costs the Google TV Streamer +0.012 ±0.009 W and Xiaomi Gen 3 +0.101 ±0.027 W (+3.8 %).
🟢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.v2 · 2026-08-13 (first 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