OWLOn 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 does
Caveats
- The "codec spread within a content β€0.1 W" half does not generalise to a third box (2026-09-22). On the TV Box W5 (Allwinner H618, n=3, same BBB iso-bitrate family, screen-attached) the hardware codec spread is 0.107 W and is statistically separated: H.264 +1.073 W vs HEVC +0.966 and VP9 +0.971 (Welch t=4.96, 95% CI +0.038..+0.176, rep ranges non-overlapping). So on that silicon the codec term is resolvable rather than lost in noise. The content half of this finding is UNTESTED on the W5 β only BBB has been run there β so whether content still outweighs codec on that box is an open question, not a claim. See docs/w5_onboarding_2026-09-21.md.
- DRAFT pending lab review. Two boxes, one resolution (1080p), one bitrate rung per codec (matched-VMAF ~92 NVENC encodes), one player (Just Player / media3), LAN HTTP delivery.
- Bench configuration: the boxes' inattentive-sleep timer (GTV default 20 min), screensaver (Fire TV default 5 min) and the GTV's HDMI-CEC active-source-lost standby were pinned OFF so a full window plays; a living-room box on defaults sleeps at 20 min. Every row records the pinned values (`keep_awake`). Earlier long-window rows taken WITHOUT this (2026-07-31, 2026-08-15) are invalid β box asleep, not decode β and are not cited.
- Fire TV Stick is Wi-Fi only (no Ethernet port): its ΞW includes the radio's share of streaming; the Google TV is on Ethernet. Link quality is not the confound (Wi-Fi 7 AP metres away).
- One Fire TV row (Meridian H.264, +0.19ββ0.19 W) is excluded: its baseline caught an Amazon home-screen autoplay burst (1.56 W vs the usual ~1.43). Repeat pending.
- n=1 per (box, content, codec) cell except GTV BBB H.264 (n=3 across 2026-08-16/17: +0.65, +0.60, +0.52 W). Cell CIs are tight (Β±0.05β0.15 W) because windows are 1100β3540 samples, but between-run baseline drift (~0.1 W) is not inside them.
- The operator box on the same bench (Bbox 4K) is NOT part of this claim: its 6.3β6.8 W idle drifts more than its H.264/HEVC decode delta, so its cells are inside its own noise even over an hour; only its AV1 rows (+1.2β1.4 W, no hardware AV1 decoder in logcat) are π’ β reported separately.
The result, in one sentence
Playing 1080p for an hour on a Google TV Streamer or a Fire TV Stick 4K adds about 0.6 W over the home screen for a bright, high-motion animation and 0.25β0.45 W for live-action drama or sport β and within either content, choosing H.264, HEVC or AV1 changes that by β€0.1 W.
Why this matters
Decode energy is paid per viewer, per hour. These are the boxes on the shelves now, all-hardware decode for all three codecs, and the number is small enough that a 34 s window cannot see it: OWL's own first attempts read 0.0β0.3 W with π΄ flags. On long windows the signal is unambiguous β ~0.6 Wh per hour of playback, over a ~1.4 W home-screen floor β and it says two things a codec debate tends to miss. First, on decode silicon the codec is nearly free: HEVC and AV1 cost the viewer nothing measurable over H.264, so the encode-side energy and bitrate savings of newer codecs are not paid back at the client. Second, the picture is not free: the same box on the same codec draws 0.35 W more for Big Buck Bunny than for Meridian β bright, saturated, high-motion frames cost more to decode and render than dark, quiet ones, and any per-title or per-hour client-energy figure that ignores content is quoting one clip.
How it was measured
decode-bench harness (decode_bench/bench.py, protocol v3): the box's own Tapo P110 (fw 1.3.1, local mW API, 1 s), pre-baseline stable-idle guard on the home screen, 20-sample baseline, launch via ADB VIEW intent into Just Player streaming from OWL's Range-correct origin over LAN, 8 s startup skip, then a 3540 s (H.264, 60-min clips) or 1100 s (HEVC/AV1, 20-min clips) sampled window, OWL confidence.py per row. Liveness is proven per row: media-session state PLAYING at mid-window, a mid-window screenshot showing content, and a flat trace to the last bin (six 10-min bins agree within ~0.03 W). All nine cited campaign jobs ran overnight 2026-08-16β17 (results/decode/2026-08-17_*.json); the reference hour is 2c793c73 (2026-08-16). Content: Big Buck Bunny (animation), Meridian (dark drama), Kranjska (MTB sport), all 1080p matched-VMAF encodes.
What this finding does not measure
- The display: the boxes render to HDMI but the panel is on its own plug and excluded β see the C2 native rows for why panel content-dependence (30β75 W) swamps decode.
- Any resolution above 1080p, HDR, or bitrate ladders; adaptive streaming behaviour; a real service's app (Just Player is a neutral local player).
- Software decode on these boxes (not reachable), or the operator Bbox (see caveats).
- Whether the ~0.35 W content spread is decode, render/compositor, or panel-facing output processing β the box is one meter.