Energy and carbon per channel: measuring and reporting the power cost of broadcast processing

How it works

Measuring the input: which watts to use

Three power figures are commonly available for any piece of media processing equipment, and only one of them belongs in a per-channel calculation.

Nameplate or maximum rated power is a supply-sizing figure. It describes what the power supply must be able to deliver, typically with substantial margin, and it is normally well above anything the device draws in service. Using it inflates the result and is the single most common error in published per-channel energy figures.

Idle power is what the device draws powered but not processing. It matters more than it appears, because in a modular chassis a significant fraction of total draw is fixed — control, switching fabric, fans and power conversion — and does not scale down with channel count. It is why a lightly loaded chassis has poor per-channel efficiency and a fully loaded one has good efficiency.

Operational power under representative load is the figure to use. Measure it at the PDU or via the platform’s own telemetry, with the actual codec, resolution, profile and channel count intended for service, sustained long enough for thermal steady state — thirty minutes is a reasonable minimum, because fan behaviour changes as the chassis warms.

The practical measurement procedure: record idle draw, then load the device in increments to full configuration, recording draw at each step. This gives both the fixed overhead and the marginal cost per channel, which are different numbers and answer different questions. Marginal cost per channel tells you what adding a service costs. Total draw divided by channel count tells you what a service costs today, at current utilisation — and that is the figure a reporting return wants.

The conversion chain

From measured watts to attributed emissions is four steps. Each introduces an assumption worth stating explicitly when the figure is published.

Step 1 — annualise. Multiply measured power in watts by hours in service. For an always-on service, 8,760 hours per year. For event-driven capacity, use actual operating hours, which is where event-based workflows differ sharply from linear ones.

Annual energy (kWh) = power (W) × hours in service ÷ 1,000

Step 2 — apply facility overhead. Power usage effectiveness expresses total facility power divided by IT power. It captures cooling, power conversion losses, lighting and everything else the building spends to keep the equipment running. Modern purpose-built datacentres operate around 1.2; older broadcast technical areas, retrofitted machine rooms and small regional sites are frequently 1.5 to 1.8 and sometimes worse.

Facility energy (kWh) = IT energy (kWh) × PUE

The effect is large and frequently ignored. The same equipment in a PUE 1.2 facility and a PUE 1.6 facility consumes 33% more total energy in the second, with no difference whatsoever in the media processing.

Step 3 — attribute per channel. Divide by the number of channels actually in service on that resource, not by its maximum capacity. Attributing against nameplate capacity produces a flattering number that does not describe the facility’s actual performance and will not survive scrutiny.

Annual energy per channel (kWh) = facility energy (kWh) ÷ channels in service

Step 4 — convert to emissions. Multiply by the grid carbon intensity for the location and period, expressed in grams or kilograms of CO₂ equivalent per kWh.

Annual emissions per channel (kg CO₂e) = annual energy per channel (kWh) × grid intensity (kg CO₂e/kWh)

Grid intensity varies enormously by geography — an order of magnitude between a predominantly hydroelectric or nuclear grid and a predominantly coal-fired one — and it varies by time of day and season within a single grid. For a facility in Norway and a facility in a coal-heavy region running identical equipment at identical utilisation, the emissions figures are not comparable and should never be presented as though they were. State the intensity figure used, its source and its period alongside the result.

The two multipliers that dominate

Everything in the chain above is arithmetic except two inputs, and those two inputs frequently matter more than the equipment choice.

PUE is a property of the facility, not of the media platform. Consolidating processing from four regional technical areas at PUE 1.7 into one purpose-built site at PUE 1.25 reduces facility energy by roughly a quarter before a single watt is saved in the equipment itself. This is often the largest single lever available and it is an estate decision rather than a procurement one.

Grid carbon intensity is a property of location and time. Where processing location is genuinely flexible — centralised distribution, cloud-hosted elastic capacity, regional hub placement — siting against grid intensity changes the emissions figure without changing the energy figure at all. Where it is not flexible, it should still be stated, because a low absolute figure achieved by siting is a different claim from one achieved by efficiency.

What actually moves the equipment number

Within the equipment itself, four levers change watts per channel, in roughly descending order of effect.

Utilisation against fixed overhead. Because chassis overhead does not scale down with channel count, a chassis at 40% utilisation carries roughly the same fixed draw as one at 90% and spreads it across fewer services. Consolidating services onto fewer, fuller chassis is usually the fastest improvement available, and it requires no new equipment.

Processing architecture. Dedicated encoder silicon and FPGA draw materially less per stream than general-purpose CPUs performing the same compression, which is why purpose-built appliances report lower watts per stream at sustained high channel counts. The existing COTS versus purpose-built article covers this comparison in full.

Codec choice and hardware acceleration. More efficient codecs reduce delivered bitrate — lowering transport, egress and CDN energy downstream — but increase compute per channel, which raises encoder energy unless the codec is hardware-accelerated. The net effect depends on where the energy is spent in your chain, and it is entirely possible for a codec change to reduce total delivered energy while increasing encoder energy. Model both sides.

Scheduling idle capacity. Event-driven capacity that runs 8,760 hours a year because nobody turns it off is pure waste. Powering down or reallocating capacity outside event windows is the cleanest saving available for event-based operations and the easiest to verify.

Avoidable arithmetic and framing errors

• Nameplate instead of measured power. Inflates results, sometimes by more than half.

• Capacity instead of utilisation in the denominator. Produces a number describing a facility that does not exist.

• Omitting PUE. Understates total energy by 20–80% depending on the facility.

• Omitting or averaging grid intensity. Makes results incomparable across sites and indefensible in a disclosure return.

• Ignoring transport and delivery energy. A codec change that reduces encoder efficiency but halves delivered bitrate may reduce total chain energy substantially. Drawing the boundary at the encoder hides that.

• Comparing a fully loaded reference chassis against a lightly loaded competitor. Normalise to comparable utilisation or the comparison means nothing.

Why it matters in broadcast

Procurement now asks. Energy and emissions questions appear in customer RFIs and supplier questionnaires as standard clauses. A supplier who can produce a measured, methodologically stated per-channel figure has a materially easier conversation than one who can produce only a datasheet maximum.

Disclosure requires attribution, not estimates. Frameworks aligned to ISO 50001 energy management and to corporate sustainability reporting expect operational energy attributed to activities with a stated methodology. “Total facility consumption” is not attribution.

Power is the binding facility constraint. In many technical areas and regional sites, available power and cooling now limit expansion before rack space does. Per-channel energy is therefore a capacity planning input, not only a reporting one.

Energy is the fastest-moving line in operating cost. Electricity pricing volatility has made a previously stable line item the one most likely to change a facility’s economics between budget cycles, and per-channel figures are what make that exposure visible.

Technical specifications and trade-offs

Reporting template

A per-channel energy figure is only defensible if it carries its assumptions. Publish it with all of the following:

Field	Example
Measurement method	PDU measurement at chassis input, 30-minute thermal steady state
Load condition	48 channels, HEVC 1080p50, 10 Mbps CBR
Measured power	Idle and full-configuration figures, both stated
Hours in service	8,760 (continuous) or actual operating hours
PUE	Value, source and measurement period
Denominator	Channels in service, not chassis capacity
Grid intensity	Value, source, region and period
Boundary	What is included — encode only, or encode plus transport plus delivery

Where to draw the boundary

Three boundaries are commonly used and they produce very different numbers:

• Device boundary — the processing equipment only. Simplest to measure, useful for equipment comparison, but it hides the downstream effect of codec and bitrate decisions.

• Facility boundary — processing plus facility overhead via PUE. The right boundary for facility reporting and capacity planning.

• Chain boundary — acquisition through delivery, including transport, egress and CDN. The only boundary at which codec efficiency trade-offs can be evaluated honestly, and the hardest to measure. Use it for decisions, not for routine reporting.

State which boundary a published figure uses. Comparisons across different boundaries are meaningless and are a common source of misleading vendor claims.

Related approaches and standards

• ISO 50001 specifies energy management system requirements and is the framework under which per-activity energy attribution is typically formalised.

• PUE (ISO/IEC 30134-2) defines the facility efficiency ratio and its measurement categories — worth citing precisely, since PUE measured at different points gives different values.

• Grid carbon intensity data is published by national system operators and by regional aggregators, at varying temporal resolution. Cite the source and period.

• The GHG Protocol distinguishes direct emissions, purchased-energy emissions and value-chain emissions; media processing energy sits in purchased energy for owned facilities and in value-chain emissions for hosted or cloud processing, which changes who reports it.

• HEVC, AVC, AV1 and JPEG XS each carry a different compute-per-channel and bitrate-per-channel profile. The trade-off between them is the clearest illustration of why chain-boundary measurement matters.

• NMOS (IS-04, IS-05) supports the orchestration required to reallocate or power down capacity outside event windows, which is where scheduling savings are realised.

How Appear addresses this

Two things determine whether an operator can produce these figures: whether the channels-in-service denominator is known accurately, and whether density is high enough that fixed chassis overhead is spread across enough services to matter.

XM addresses the denominator. It provides estate-wide visibility across deployed X Platform chassis — inventory, configured services, alarm state and software version — through a single interface and an API. That establishes how many channels are actually in service on each resource, which is the divisor the calculation above depends on and the number most often guessed at.

The numerator still has to be measured. Appear does not expose live per-chassis power telemetry, so the method described above stands: measure at the PDU, at thermal steady state, under the configuration you intend to run. Per-module and per-chassis power figures for planning purposes are available from Appear on request rather than from the platform itself, and the PSU rating on a datasheet is a nameplate figure — the one this article recommends against using.

On density, the X Platform concentrates channels per rack unit: the X20 in 2RU takes up to twelve module slots, the X10 is the 1RU chassis, and X5 is the compact edge encoder and decoder. Higher channels per chassis improves the utilisation term that dominates watts per channel, because fixed overhead is amortised across more services. Front-to-back airflow and redundant PSUs feed the facility side of the equation rather than the IT side.

Appear’s position on compression efficiency and sustainability is set out in Compression and sustainability and on the Climate commitment page. For the cost model that sits alongside the energy model, see Comparing cloud/software and hardware encoding.

FAQ

Which power figure should I use — nameplate, idle or measured? Measured operational power under representative load, at thermal steady state. Nameplate is a supply-sizing figure and using it inflates the result substantially.

How do I calculate annual energy per channel? Multiply measured power in watts by hours in service, divide by 1,000 for kWh, multiply by facility PUE, then divide by the number of channels actually in service on that resource.

How much difference does PUE make? Moving from PUE 1.2 to PUE 1.6 increases total facility energy for the same equipment by 33%. It is frequently a larger lever than the equipment choice itself, and it is an estate decision rather than a procurement one.

Should I divide by chassis capacity or by channels in service? Channels in service. Dividing by capacity describes a facility that does not exist and will not survive scrutiny in a customer questionnaire or a disclosure return.

Why does a lightly loaded chassis have poor per-channel efficiency? Because control, switching fabric, cooling and power conversion draw is largely fixed and does not scale down with channel count. Consolidating services onto fewer, fuller chassis is usually the fastest efficiency improvement available.

Does a more efficient codec always reduce total energy? No. More efficient codecs reduce delivered bitrate — saving transport, egress and CDN energy — but increase compute per channel unless hardware-accelerated. The net result depends on where energy is spent in your chain, so measure at the chain boundary before deciding.

How do I convert energy to emissions? Multiply annual energy in kWh by the grid carbon intensity for the location and period, in kg CO₂e per kWh. Always state the intensity value, source and period alongside the result.

Can I compare per-channel figures between two sites in different countries? Only for energy, not for emissions, unless you normalise for grid intensity. Two identical facilities on different grids produce very different emissions figures with identical energy consumption.

How long should a power measurement run? Long enough to reach thermal steady state — thirty minutes as a practical minimum, since fan behaviour and therefore total draw change as the chassis warms.

What is the biggest saving available without buying new equipment? Raising utilisation on existing chassis, and powering down or reallocating event-driven capacity outside event windows. Both are operational changes with measurable, verifiable effect.

Which boundary should a published figure use? State it explicitly. Device boundary for equipment comparison, facility boundary for reporting and capacity planning, chain boundary for codec and architecture decisions. Comparisons across boundaries are meaningless.

How do I validate a vendor’s watts-per-stream claim? Request the figure at your target codec, resolution, profile and channel count, then measure it yourself at the PDU during a pilot under sustained representative load. Ask which of nameplate, idle or measured operational power the claim uses.

Learn more

For chassis form factors, module density and cooling design across the platform, see the X Platform overview; for estate-wide inventory and service visibility, see XM. For the density model behind watts per channel, see COTS hardware versus purpose-built broadcast hardware; for the cost model, see Comparing cloud/software and hardware encoding.