// the find
numberwolf/h265web.js
https://h265web.com 🔥 作者：常炎隆(Author: ChangYanlong):HEVC/H.265 网页直播/点播播放器 支持硬解！ 支持H.265的HttpFLV/HLS/MP4/TS/FLV/M3U8/Websocket/WebRTC播放。 🔥 A HEVC/H.265 Web Player, Support hard-decoding! for LIVE/VOD stream. Support H.265 Codec with HttpFLV/HLS/MP4/TS/FLV/M3U8/Websocket/WebRTC.
A browser SDK for playing HEVC/H.265 (plus H.264 and AV1) video, covering VOD and live protocols — HLS, FLV, HTTP-FLV, MPEG-TS, MP4, M3U8, and now WebRTC/WHEP — with a WASM software decoder and hardware-decode/WebCodec fallback. Aimed at teams that need H.265 playback in the browser without native codec support, especially for IP-camera or CDN live-streaming setups paired with a server like ZLMediaKit.
Genuinely broad protocol/codec coverage in one SDK (HEVC/AVC/AV1 across HLS, FLV, TS, MP4, and WebRTC) with a sensible fallback chain: hardware decode, then WebCodec, then WASM+SIMD — that ordering matters a lot for performance on H.265, which most browsers still don't decode natively. It's been maintained since 2017 with a long, specific changelog (not just 'bug fixes'), and has real production users listed (Temu, Kwai, iQiYi, Baidu), which is a decent signal it holds up outside a demo page. The recent WHIP/WHEP and ZLMediaKit RTMP-to-WebRTC work, including documented timestamp-smoothing gotchas (`modify_stamp`), shows someone actually running this against real streaming infra rather than just toy files.
There's no source directory for the core player — `static/h265web.js` and the WASM decoder ship as built artifacts, and the actual H.265 decoder lives in a separate repo (`h265web.js-wasm-decoder`) that isn't part of this one either; you're integrating a black box, not something you can patch or audit. Licensing is a custom 'CYL_Free-1.0' license rather than a standard OSI license (MIT/Apache/GPL), so check the terms before using it commercially — the README also advertises a 'PRO' tier without the feature matrix saying which rows are free vs. paid. Support is QQ groups, WeChat, and a single named maintainer, with no visible multi-maintainer or triage process, so bus-factor risk is real for something this widely embedded. Native WebRTC playback is locked to 1x with no seek, and the encoded-media fallback for non-negotiated codecs requires the server to implement a bespoke `h265web-rtc-encoded/v1` transport — that's a non-trivial server-side lift most teams won't have for free.