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 ranking
SCOPE: Client device layer only (Google TV Streamer hw; Raspberry Pi 5 / Pi 400 sw, headless pure decode). Network, CDN excluded; Pi rows exclude display and audio.
OWL Finding: 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 ranking
measured 2026-07-29
https://wattlab.greeningofstreaming.org/findings/codec-decode-energy-depends-on-silicon-and-regime
Greening of Streaming — wattlab.greeningofstreaming.org
Source measurement
Loading measurement decode/dec0de06…
Loading measurement decode/dec0de05…
Loading measurement decode/dec0de04…
Caveats
DRAFT pending lab review. Yellow because the software realtime panels are BBB 1080p60 only (n=1–3 per cell) and the Google TV rows are full playback (display + audio) vs the Pis' headless pure decode — the cross-device comparison is indicative, not strict.
Matched-VMAF encodes, so bitrate co-varies with codec (BBB: 8.0/6.6/4.0 Mb/s for h264/hevc/av1) — the honest iso-quality framing, not equal-bitrate.
Why AV1 draws less than its CPU share suggests (85.5% busy yet lowest saturated power) is conjecture — instruction-mix/power-density hypothesis, needs PMU counters.
Which regime a real player occupies depends on its buffering strategy (July's Google TV burst-vs-sustained finding shows +0.42 W between modes); no Pi player's buffering has been characterised.
The result, in one sentence
On fixed-function hardware (Google TV) the three codecs decode within 0.08 W of each other; in software at playback pace the spread is up to ~60% with the same ordering on two different Pi generations (h264 < av1 < hevc); and when decode runs flat-out instead of paced, the ranking inverts (AV1 lowest, H.264 highest).
Why this matters
Codec-energy claims are routinely made without stating the decode path or the measurement regime — this data shows either omission can flip the conclusion. Concretely, for the industry's live HEVC-rollback question: rolling back to H.264 is energy-neutral on hardware-decode devices (≤0.08 W) and energy-reducing on software-decoding clients (−1.0 W of +2.56 on these boards). And a codec's "energy cost" is not one number: paced at 1×, H.264 software decode is cheapest; racing to idle, the same board makes AV1's instantaneous draw the lowest. If it can't be stated with silicon path and regime attached, it shouldn't be asserted.
How it was measured
Same 1080p matched-VMAF (~92–93) NVENC encodes across all three devices. Google TV: Just Player full playback, hw MediaTek decoders, July 2026 round (n=9, all 🟢). Pis: decode-bench headless pure decode from tmpfs, realtime (-re) and saturated (-stream_loop -1) regimes, Tapo P110 mW path, OWL confidence per row; key realtime rows n=2–3. Full narrative + conjecture list: docs/pi_decode_energy_2026-07.md.
Playback with display attached on the Pis, or any Pi player's buffering behaviour — so it does not name a single "greenest codec for playback" per device.
Equal-bitrate codec comparison (bitrate co-varies under matched quality).