Deploying H.265 Video on the Web: Compatibility, Hardware/Software Requirements, and Playback Strategies

With Chrome 107 supporting hardware decoding of H.265 and mature software decoding on the web, large‑scale deployment of H.265 is now feasible. The main benefit is lower deployment cost.

The core challenge for web developers is to deploy higher‑efficiency codecs at scale: use the efficient codec when hardware and software conditions allow, and fall back to a less efficient codec otherwise.

This article shares experience from deploying H.265 in a content‑review platform, covering browser compatibility, hardware and software prerequisites, and playback solutions.

Browser compatibility – H.265 support varies across browsers: Safari supports both soft and hard decoding, Chrome ≥ 107 supports hard decoding only, while Firefox and Edge do not support it. Compatibility tables and caniuse references are provided.

Decoding methods – Soft decoding runs on the CPU, has high CPU cost but high compatibility; hard decoding uses GPU modules, offering high efficiency and low power consumption but depends on GPU support and driver versions.

Hardware requirements for hard decoding include specific GPU models (e.g., NVIDIA GTX950+, AMD RX460+, Intel HD4400+, Apple M1 series). Software requirements include appropriate decoding frameworks (Media Foundation, D3D11VA, DXVA2, VideoToolbox, VAAPI, OpenCL) and OS versions.

Playback options – Several approaches are compared:

Direct <video src="//cdn.com/hevc.mp4"> 你的当前环境不支持播放该视频 </video> – highest compatibility, lowest implementation cost.

<video controls width="375" height="375"> <source src="//cdn.com/hevc.mp4" /> <source src="//cdn.com/avc.mp4" /> </video> – better fallback handling with the type attribute.

MSE – medium compatibility and implementation cost.

WebCodecs – low compatibility, high implementation cost.

WASM‑based soft decoder – high compatibility but very high implementation cost.

Decision tables show compatibility, implementation cost, and user experience for single‑source and multi‑source scenarios.

Detection APIs – canPlayType(), MediaSource.isTypeSupported(), navigator.mediaCapabilities.decodingInfo(), and actual video loading via HTMLVideoElement are evaluated for accuracy, performance, and implementation cost. Example code snippets:

document.createElement('video').canPlayType('video/mp4;codecs=hvc1.1.6.L93.90');

MediaSource.isTypeSupported('video/mp4;codecs=hvc1.1.6.L93.90');

navigator.mediaCapabilities.decodingInfo({
    type : 'file',
    video : {
        contentType : "video/mp4;codecs=hvc1.1.6.L93.90",
        width : 1280,
        height : 780,
        bitrate : 874496,
        framerate : 25
    }
}).then(({ supported }) => console.log(supported));

const isSourceSupported = (url: string): Promise
=> {
    const video = document.createElement('video');
    // set minimal attributes
    return new Promise((resolve) => {
        video.onloadeddata = () => resolve(video.videoWidth > 0 && video.videoHeight > 0);
        video.onerror = () => resolve(false);
        video.src = url;
    });
};
isSourceSupported('//cdn.com/hevc.mp4').then(console.log);

const decoder = new VideoDecoder(init);
decoder.configure({
  codec: 'vp8',
  hardwareAcceleration: 'prefer-hardware',
});
interface VideoDecoder {
  configure(config: VideoDecoderConfig): void;
}
interface VideoDecoderConfig {
  codec: string;
  hardwareAcceleration?: HardwarePreference | undefined;
}
type HardwarePreference = "no-preference" | "prefer-hardware" | "prefer-software";

Risk: API detection may be inaccurate (e.g., Chrome 108 bug disabling hardware decoder while still reporting support). A fallback strategy using error and loadeddata events is recommended:

video.addEventListener('error', () => {
  if (video.error?.code === MediaError.MEDIA_ERR_DECODE) {
    nextSrc();
  }
});
let once = false;
video.addEventListener('loadeddata', () => {
  if (!(video.videoWidth > 0 && video.videoHeight > 0) && !once) {
    nextSrc();
  }
  once = true;
});

Conclusion: Choose the detection API that matches the playback method (use isTypeSupported() for MSE, decodingInfo() for WebCodecs). Prefer <source> fallback, then MSE, then WebCodecs, and finally WASM when necessary.

The article also discusses performance considerations for WASM soft decoding, optimization techniques (multithreading, SIMD, frame filtering), and rendering strategies (OffscreenCanvas, AudioWorkletProcessor).

Team introduction and recruitment information are included at the end.