Scaling H.265 Video on the Web: Compatibility, Decoding Strategies & Best Practices

With Chrome 107 adding hardware decoding support for H.265 and mature software decoding on the web, the time is ripe to deploy H.265 at scale. The key challenge for web developers is to deliver the most efficient codec when hardware and software conditions allow, and gracefully fall back otherwise.

Browser Compatibility

H.265 support varies across browsers: Safari fully supports both software and hardware decoding, Chrome 107+ only hardware decoding, while Firefox and Edge do not support it. The canPlayType, isTypeSupported and decodingInfo APIs provide different levels of confidence and performance for detection.

Reference: https://caniuse.com/hevc

Decoding Methods

Two decoding approaches exist:

Software decoding runs on the CPU, demanding high processing power for high‑bitrate streams but offering broad compatibility.

Hardware decoding leverages GPU modules, delivering high efficiency and low power consumption, yet depends on GPU support and driver versions.

Hardware Requirements

Hardware decoding requires a compatible GPU. Typical minimums are NVIDIA GTX 950 or newer, AMD RX 460 or newer for discrete GPUs, and Intel HD 4400 or newer, AMD Radeon R7 or newer, Apple M1 series for integrated GPUs.

Software Frameworks

Operating‑system‑level decoding frameworks include Media Foundation, D3D11VA, DXVA2 and OpenCL on Windows; VideoToolbox on macOS; and VAAPI and OpenCL on Linux. Browsers usually adopt these generic frameworks for hardware decoding.

Playback Solutions

Various ways to play video on the web:

src attribute – simplest but offers poor fallback when the codec is unsupported.

source elements – allow multiple sources with type attributes for graceful fallback.

Media Source Extensions (MSE) – enable custom demuxing and buffering, suitable when codec detection is needed.

WebCodecs API – provides direct access to hardware decoders via VideoDecoder.

WebAssembly (WASM) – implements a software decoder (e.g., FFmpeg) for maximum compatibility.

Detection APIs

Four main methods are used to check codec support: HTMLMediaElement.canPlayType() – fastest but low confidence. MediaSource.isTypeSupported() – medium confidence, moderate speed. navigator.mediaCapabilities.decodingInfo() – high confidence, slower.

Creating a <video> element and listening for loadeddata or error – highest confidence but highest cost.

Analysis

Accuracy ranking: HTMLVideoElement > decodingInfo > isTypeSupported > canPlayType. Performance ranking: canPlayType > isTypeSupported > decodingInfo > HTMLVideoElement. Implementation cost ranking mirrors performance.

Risks

APIs may report support even when a driver bug disables hardware decoding (e.g., Chrome 108 on Windows with certain NVIDIA drivers). Fallback logic using error and loadeddata events is essential.

Conclusion

Select the detection API that matches the playback method: use isTypeSupported() for MSE, isTypeSupported() for WebCodecs, and avoid canPlayType() due to low confidence. Always implement fallback handling.

Playback Flow

A recommended flow prioritizes sources when multiple are available (source → MSE → WebCodecs → WASM → src) and falls back to src when only one source exists.