HDR Archive, HEVC Transcode and Frame-Accurate Clipping for a Certification School

Verdict: not defensible. Three independent reasons, each sufficient on its own.

1. Bit depth. HDR delivery uses PQ or HLG transfer functions. PQ allocates a large share of its code values to highlights, so an 8-bit signal leaves very few code values in the shadows and midtones; smooth gradients (a lit backdrop, a plasma glow) break into visible steps. HDR10 is defined for 10-bit and above for exactly this reason.
2. Chroma sampling. 4:2:0 stores one chroma pair per four luma samples. Saturated HDR highlights - coloured flames, LED indicators, laser demonstrations - are precisely where chroma resolution matters, and 4:2:0 produces colour bleeding that cannot be undone later.
3. Format signalling and generational loss. H.264 was not designed as an HDR interchange format; static HDR metadata (mastering display colour volume, content light level) has to be bolted on as SEI and many tools ignore it. Worse, the proposal archives an inter-frame compressed stream, so any future regrade decodes artefacts and re-encodes them.

Archive instead: a 10-bit 4:2:2 intra-frame mezzanine - ProRes 422 HQ or DNxHR HQX - which is frame-accurate, cheap to decode for editing, and preserves the grade. Derive delivery renditions from it: HEVC Main10 4:2:0, with H.264 High as a fallback for old devices. Storage maths: ProRes 422 at 1080p25 runs about 147 Mbps, so a 12-minute master is roughly 13 GB; 500 masters per year is ~6.6 TB, which is far cheaper than reshooting a demonstration that graded badly.

The proposal saves bandwidth on paper and loses quality permanently in practice.

• Cascaded lossy coding. Each H.264 file already carries quantization noise, blocking and ringing. The HEVC encoder has no model of the original content; it treats those artefacts as signal, spends bits reproducing them, and adds its own. Motion-compensated prediction makes this worse: an artefact inside a reference block propagates through the GOP.
• The 50% saving is not guaranteed. HEVC's efficiency gain over H.264 is often quoted around 40–50% at equal quality for UHD material with a clean source. For 1080p content that is already compressed at 3.2 Mbps and already near its quality floor, re-encoding usually forces either a visible quality drop or a bitrate that is not much lower. Measure before committing: encode ten representative clips at three bitrates and compare VMAF/SSIM against the H.264 source, not against a fresh encode.
• Irreversibility. Once the ProRes masters are discarded, every future codec (AV1, VVC) inherits the same damage.

Preferred plan:

1. Recover or retain ProRes masters wherever they exist, and encode HEVC from those. Keep the masters as the mezzanine of record - this is a storage purchase measured in single-digit terabytes, not a capital project.
2. For the subset with no surviving master, treat the H.264 file as the source of record: encode HEVC at a quality target (constant QP or CRF) rather than a fixed bitrate, keep a copy of the original for rollback, and gate the release on a measured quality check.
3. Retire the 3.2 Mbps H.264 renditions only after the new ladder has been validated on real devices.

Why it fails. A long-GOP stream only decodes cleanly from an IDR (instantaneous decoder refresh) frame. To display the frame an editor clicks, the player must locate the preceding IDR and decode every frame forward to the target. With a 10-second GOP at 25 fps that is up to 250 frames of decoding, plus container parsing and network buffering - matching the observed three-to-five-second stall. HEVC adds a nuance: CRA pictures with leading pictures are legal random-access points but the leading pictures cannot be decoded from that point, so naive seeking produces artefacts. Open GOPs make it worse.

What the editors actually need is an intra-frame or short-GOP proxy, not a smaller delivery stream.

Proposed architecture:

• Delivery tier: keep long GOPs (IDR every 5–10 s, closed GOP, B-frames enabled) for the CDN. Long GOPs are what make the bitrate low; shortening them for the sake of editors would raise delivery cost, which is the opposite of the finance goal.
• Editing tier: generate a 540p or 720p intra-frame proxy (ProRes Proxy or H.264 All-Intra at ~2–4 Mbps) at ingest, stored on cheap object storage and served only to authenticated editors. Every click becomes a single-frame decode.
• Conform: the editor exports an EDL or decision list of timecodes; the render farm applies it to the mezzanine master, so the published clip carries full master quality rather than proxy quality.
• Housekeeping: store a keyframe index (byte offset and timestamp per IDR) in the database so the player can jump to the nearest IDR before decoding forward - this also improves scrub performance for end viewers at negligible cost.

The splitting of editing proxies from delivery renditions is standard practice and typically adds less than 5% to total storage while removing the seek complaint entirely.