HLG — Hybrid Log-Gamma — is the HDR transfer function the BBC and NHK developed jointly to enable HDR broadcasting alongside SDR using the same delivery infrastructure. Unlike HDR10's PQ transfer function (which is display-referred and produces output that looks wrong on SDR displays), HLG is scene-referred and backward-compatible with SDR — the same HLG signal looks correct on both an HDR display (rendered as HDR) and an SDR display (rendered as SDR). For broadcast, where the same signal must serve both HDR and SDR audiences without separate variants, HLG is the answer. For streaming, HDR10/Dolby Vision/HDR10+ dominate. This page is the engineering reference.
What HLG is
HLG is a transfer function — the OETF (opto-electrical transfer function) that maps brightness to digital code values. It was jointly developed by the BBC and NHK, standardized as part of ITU-R BT.2100 (2017).
The defining characteristic: HLG is scene-referred, not display-referred. The code value relates to scene brightness rather than absolute display luminance. The display interprets the code value based on its own peak luminance:
- A 75% code value on an SDR display (100 nits) renders at ~75 nits.
- A 75% code value on a 1000-nit HDR display renders at ~750 nits.
- A 75% code value on a 4000-nit HDR display renders at ~3000 nits.
The scene relationship preserves the perceptual mapping across displays; the absolute brightness scales with the display capability.
This contrasts with PQ (HDR10's transfer function), which is display-referred — code value 1023 always means 10,000 nits regardless of display. PQ produces output that looks wrong on displays it wasn't intended for; HLG produces output that looks reasonable on any display.
The "hybrid" in Hybrid Log-Gamma refers to the curve shape: gamma-like in the lower brightness range (matching SDR's gamma curve) and logarithmic in the upper range (extending dynamic range for HDR). The hybrid lets a single signal serve both SDR and HDR displays gracefully.
SDR backward compatibility
HLG's defining feature is SDR compatibility. The same HLG signal:
- On an SDR-only display: rendered as SDR using the gamma-like portion of the curve. Looks like normal SDR.
- On an HDR display: rendered as HDR with extended dynamic range using the full curve. Looks like HDR.
No separate variants needed. No metadata to interpret. No tone-mapping concerns. The signal works on both display types because the curve is designed for graceful degradation.
This is operationally invaluable for broadcast — broadcasters can ship one HLG signal that works on both SDR and HDR receivers in the audience, without producing separate HDR and SDR variants.
For streaming, this matters less because streaming infrastructure can deliver per-device variants efficiently. SDR + HDR10 + Dolby Vision as separate variants is operationally tractable for streaming. For broadcast contribution and over-the-air delivery, HLG's single-signal approach is much simpler.
HLG in BT.2100
ITU-R BT.2100 standardized HLG (and PQ) as the two HDR transfer functions for production. The standard specifies:
- HLG OETF formula.
- HLG OOTF (opto-optical transfer function) for converting between scene-referred and display-referred values.
- BT.2020 color space (same wide gamut as HDR10).
- 10-bit and 12-bit color depths.
HLG and PQ are both BT.2100 transfer functions. They're alternatives, not complementary — content is mastered in one or the other. HLG-mastered content can be tone-mapped to PQ for streaming delivery (and vice versa), with quality cost.
HLG in production workflows
HLG is the primary HDR format for live broadcast workflows. The pattern:
- Capture — HDR-capable cameras output HLG-encoded video natively.
- Production switching — broadcast production switchers handle HLG signals alongside SDR signals (HLG signals look correct on SDR monitoring).
- Distribution — over-the-air broadcast (DVB-T2, ATSC 3.0) carries HLG signals to consumer receivers.
- Receiver display — TVs render HLG appropriately based on their HDR/SDR capability.
For sports broadcasting, HLG dominates — the production workflow doesn't need separate HDR and SDR feeds, and live HLG production has been operationally validated for over a decade.
For VOD streaming (Netflix, Prime, etc.), HLG is rarely used. The infrastructure is built around per-device variant delivery, and HDR10/Dolby Vision/HDR10+ are the formats with consumer streaming ecosystem maturity.
HLG in HEVC / AV1
HLG signaling in HEVC uses VUI:
- Color primaries = BT.2020 (matrix coefficients = 9).
- Transfer characteristics = ARIB STD-B67 (matrix coefficients = 18, the HLG identifier).
- Matrix coefficients = BT.2020 non-constant luminance.
HLG doesn't use mastering display SEI metadata (HDR10's static metadata) — HLG is self-contained in the curve, so no separate metadata is required.
Encoding HLG with x265:
ffmpeg -i input -c:v libx265 -profile:v main10 -pix_fmt yuv420p10le \
-x265-params "colorprim=bt2020:transfer=arib-std-b67:colormatrix=bt2020nc" \
-c:a copy output.hevc
The transfer function identifier (arib-std-b67) signals HLG to playback systems. Similar signaling applies for AV1.
Display ecosystem support
HLG support across consumer displays in 2026:
- TVs — every HDR-capable TV from 2017+ supports HLG. Universal across LG, Samsung, Sony, Vizio, etc.
- Mobile — most HDR-capable phones support HLG.
- Set-top boxes / streaming devices — HLG is supported broadly.
- Browsers — HLG support varies; less universal than HDR10 in browser HDR support.
- Game consoles — HLG is supported on PS5 and Xbox Series X|S as alongside HDR10.
The display install base for HLG is essentially the same as HDR10. Both are supported universally on HDR-capable consumer displays.
When HLG is the right answer
The cases where HLG is the right HDR format:
- Broadcast workflows — over-the-air, satellite, cable. SDR backward compatibility eliminates the need for parallel SDR signal production.
- Live production — single-signal workflows for camera-to-air pipelines.
- Contribution feeds — HLG carries cleanly through broadcast contribution infrastructure (SRT, RIST, etc.).
- Mixed SDR/HDR audiences with single-stream delivery — when you can't or don't want to ship multiple variants.
The cases where HLG isn't the right answer:
- VOD streaming with multi-variant delivery — HDR10 is the streaming default. Variant infrastructure handles SDR fallback explicitly.
- Premium streaming with Dolby Vision tier — HLG can't carry per-scene dynamic metadata. Premium streaming wants Dolby Vision (or HDR10+).
- Apple ecosystem premium — Apple TV+ premium content is Dolby Vision; HLG is supplementary at best.
HLG and HDR10 are essentially complementary — HLG for broadcast, HDR10 for streaming. The same content can be delivered as both formats from a single master with appropriate conversion.
Live HLG vs streaming HDR10
For live content delivered to both broadcast and streaming, the pattern is:
- Master grading and capture in HLG (broadcast-friendly).
- Broadcast distribution as HLG over DVB/ATSC/IP.
- Streaming distribution convert HLG → HDR10 (or HLG → Dolby Vision if premium).
The HLG → HDR10 conversion is straightforward — both use BT.2020 color and 10-bit depth; the transfer function conversion is well-defined. Quality is preserved.
This dual-delivery pattern is common for sports networks (ESPN, Sky Sports, etc.) that ship to both broadcast and streaming audiences. HLG simplifies the broadcast side; HDR10 conversion serves the streaming side.
A note on HLG and the BBC/NHK collaboration
HLG's standardization story is interesting in the context of HDR format wars. Most HDR formats came from a single corporate sponsor — Dolby Vision from Dolby, HDR10+ from Samsung. HLG came from two public broadcasters (BBC and NHK) collaborating because they faced a shared engineering problem: how to deploy HDR over existing broadcast infrastructure that couldn't handle separate HDR/SDR variants.
The constraint shaped the technical design. Public broadcasters can't afford to ship HDR-only signals that look broken on legacy SDR receivers — that would alienate the audience that hadn't upgraded yet. Public broadcasters also can't afford to ship dual-signal infrastructure (twice the bandwidth, twice the production complexity). HLG solved both constraints at once.
The result is a transfer function with broader perceptual coverage than its competitors at the cost of less precision in the highlight range. PQ can encode 10,000 nits with mathematical precision; HLG handles up to ~1000 nits effectively and graceful degradation above that. For broadcast use cases where 1000 nits is the practical display peak, HLG is sufficient. For premium VOD aiming at 4000-nit displays, PQ-based HDR10 is more aligned with the precision needed.
HLG and ATSC 3.0
ATSC 3.0 (next-generation broadcast TV in the US, formally NextGen TV) adopted HLG as one of its supported HDR formats. Broadcasters launching ATSC 3.0 services in 2026 are using HLG as the production HDR format. NextGen TV deployments in major US markets ship HLG content where source material is available.
The broadcaster-friendliness of HLG matters operationally for ATSC 3.0 — broadcast infrastructure is built around single-signal delivery to mixed receiver populations. HDR10's per-display variants don't fit broadcast workflows the way HLG does.
What MpegFlow does with HLG
MpegFlow's FfmpegExecutor worker image runs HEVC Main 10 (x265) and AV1 10-bit (SVT-AV1) for HLG output. The DAG runtime expresses HLG encoding as rendition stages on job_stages with explicit dependency tracking; per-stage retry handles transient failures; sibling cancellation propagates fatal failures across rendition stages.
For customers ingesting HLG content (broadcast contribution, live production output) and delivering to streaming audiences as HDR10, the workflow runs a transfer-function conversion (HLG → PQ) at the FfmpegExecutor stage via filter parameters; the partitioner persists the conversion stage and the rendition stages with dependency tracking. An FfprobeExecutor stage upstream characterizes the source's transfer function so the conversion gets the right inputs via cross-stage data flow.
For pipelines that produce both broadcast HLG outputs and streaming HDR10 outputs from the same master, the workflow models each output target as parallel sibling rendition stages — same upstream source, different downstream encoder parameters.
The CMAF muxer at the packaging stage preserves HLG signaling (colr with HLG transfer-characteristics indicator) the encoder emitted; broadcast-typed contribution wrapping (AS-11/DPP and similar profiles) is not a pipeline-native output type today — broadcast-side wrapping is operator-side work alongside MpegFlow.
The strict-broker security model handles HLG content like any pipeline payload — workers carry no ambient credentials; content access flows through short-lived presigned URLs scoped per stage; access is disposed on completion.
For customers building broadcast-to-streaming pipelines, HLG ingest → HDR10 streaming output is the common pattern. We help configure the transfer function conversion correctly during onboarding; the rest of the pipeline (encoding, packaging, delivery) follows the standard HDR pipeline. HLG isn't more complex than HDR10 to operate; it just serves a different ecosystem (broadcast vs streaming) with different operational characteristics.