Jessibuca: an H5 live-stream player that decodes H.264 and H.265 in the browser via WebAssembly

What Jessibuca solves, and who actually needs it

Browsers do not natively play HTTP-FLV or WebSocket-FLV, and H.265 support is uneven across them. Jessibuca exists to close that gap: the README describes it as an open source, pure H5 live-stream player that compiles audio and video decoding libraries to JavaScript (wasm) through Emscripten, so it runs in the browser without an extra plugin. It targets PC, phone and WeChat browsers.

The codec list is the reason to pick it. H.264 is supported across Baseline, Main and High profiles, including B-frame video. H.265 is decoded when the stream carries flv id equal to 12, and enhanced-rtmp H.265 is also listed. On the audio side it handles AAC in LC, HE and HEv2 profiles, plus PCMA, PCMU and 8 kHz PCM_ALAW and PCM_MULAW G.711. That combination matters for surveillance and broadcast feeds, where the camera or gateway decides the codec and you cannot re-encode server-side.

It is not aimed at video-on-demand catalogues or adaptive-bitrate dashboards. The README's live-stream section enumerates 21 formats, starting with ws(s)-raw, ws(s)-flv, http(s)-flv and HLS, and the demo directory contains separate pages for VOD versus stream comparisons. If your problem is a library of MP4 files, a native video element is cheaper than shipping a WebAssembly decoder.

How the WASM pipeline and the three transport modes fit together

The repository layout tells the story. There is a wasm directory, an ffmpeg directory and an ffmpeg.py plus wasm/make.py pair, so the decoder is built from source rather than pulled as a binary blob. The build script named build:wasm runs python wasm/make.py --wasm before the rollup build, which is how the compiled module is produced. The shipped player is small: the README states the CDN-accelerated, GZIP-compressed download is about 500k.

On the transport side, three modes are documented. WebSocket-FLV is the default recommendation, and the README notes it does not have the cross-origin problem that HTTP-FLV does. HTTP-FLV works but requires the server to send access-control-allow-origin. The ws-raw private protocol sends bare data with less overhead, and the README is explicit that it only interoperates with a Monibuca server; other servers need custom work.

Rendering and decoding are layered. WebGL is used for drawing, with OffscreenCanvas support for better WebGL performance. WebWorker multi-core decoding is listed for multi-window playback. Hardware paths exist too: WebCodecs and MediaSourceExtensions are supported, and the README says the player falls back to WASM software decoding automatically when hardware decoding fails. That fallback is the practical safety net, because WebCodecs availability still varies by browser and platform.

Installing Jessibuca and playing an HTTP-FLV stream

The package is published to npm as jessibuca, and package.json at version 3.3.28 lists screenfull, recordrtc and element-plus as runtime dependencies. The README does not give a step-by-step install walkthrough, so the realistic paths are the npm package or the prebuilt files in dist. Start by adding the dependency.

npm install jessibuca

The repository's package.json provides the build scripts, including npm run build and npm run dev, and the demo directory is a VitePress site, so npm run dev opens the documentation and demo pages locally. For a first picture, the README's format list gives the exact URL shape: http(s)-flv is http(s)://host-name:port/hdl/live/test.flv, where live/test is the streamPath. The WebSocket form is ws(s)://host-name:port/jessica/live/test.flv and does not need the cross-origin header.

npm run dev

That command starts the VitePress dev server for the demo directory, which is where the player examples live. The one option worth experimenting with first is the playback buffer: the README states a buffer of 0 gives the lowest latency but network jitter will cause stutter. The built-in bottom UI appears with play/pause, volume, screenshot, recording, fullscreen and a traffic readout, each of which the README says can be toggled through configuration.

Where the open source build stops: the PRO split

This is the most important thing to understand before adopting Jessibuca, and it is easy to miss because the README documents both editions in one file. The features listed under the PRO heading are not in the open source build. That list is long and includes things people commonly assume are basic: MP3 audio, MPEG-4 video, WebRTC, MSE hardware decoding for H.265, multi-threaded and SIMD WASM decoding for 1080P and above, mirroring, watermarks of every kind, PTZ controls, SEI extraction, network latency detection with re-pull, and M7S, SM4 and XOR encrypted stream playback.

So the open source edition is single-threaded WASM software decoding plus WebCodecs and MSE where the browser provides them, over HTTP-FLV, WebSocket-FLV, ws-raw or HLS. If your workload is many 1080P H.265 tiles on one page, the PRO list is effectively telling you the open source build is not the tool, because the multi-threaded and SIMD variants are gated. The README does say the PRO edition supports nearly all open source methods and events and offers a seamless upgrade path, so the API surface is not a trap, but the capability ceiling is real.

A second limitation is protocol coupling. The ws-raw and WebTransport entries in the format list both carry the note that they only interoperate with a Monibuca server. Choosing those transports is choosing that server.

Jessibuca compared with MSE-based players like EasyPlayer.js and xgplayer

The obvious alternative approach is to let the browser do the decoding. EasyPlayer.js and xgplayer lean on Media Source Extensions, feeding fMP4 or TS segments into a SourceBuffer and letting the platform's hardware decoder handle the pixels. That path costs nothing in download size and uses hardware decoding by default, which matters on battery-powered devices.

The trade-off is codec coverage. MSE only decodes what the browser's own decoder supports, which is why H.265 on MSE is not a given across browsers and why the Jessibuca README lists H.265 MSE hardware decoding as a PRO feature with a WASM fallback. Jessibuca's answer is to ship its own decoder, so H.265 with flv id 12 plays even where the browser has no H.265 support at all. You pay roughly 500k of compressed JavaScript for that guarantee.

A second difference is the transport. MSE players generally want segmented formats, which is why HLS dominates that ecosystem. Jessibuca is built around the low-latency FLV family: HTTP-FLV, WebSocket-FLV and the ws-raw private protocol that strips container overhead. If your pipeline already produces FLV, Jessibuca removes a transmuxing step. If your pipeline produces HLS with fMP4, an MSE player is the more natural fit and Jessibuca's HLS support is simply one more entry in its format list.

Licence, release cadence and the cost of staying current

Jessibuca is licensed GPL-3.0. That is a copyleft licence, and it applies to the player you embed in your page, not just to a server component. If your product ships the player to users, the licence terms are a distribution question your legal team has to answer, and this article cannot give legal advice on it. The commercial PRO edition exists alongside the GPL build, which is a common arrangement for projects in this position, but the README does not spell out the PRO licence terms.

On cadence, the repository is not archived and the most recent push was on 2026-09-20. Releases have been roughly monthly: v3.3.26 on 2026-06-04, v3.3.27 on 2026-07-07 and v3.3.28 on 2026-08-03. The package.json version matches the newest release at 3.3.28.

Upgrade cost is dominated by the WASM artifact, not the JavaScript API. The build:wasm script rebuilds the decoder through wasm/make.py before the rollup bundle, so anyone building from source needs a Python toolchain and the ffmpeg submodule present. Consumers who take the published dist or the npm package skip that entirely. The README does not document a rollback procedure or a compatibility matrix between player versions and stream server versions, so pinning a known-good version in package.json is the only documented safety net.

Editorial conclusion

Adopt the open source build if you need H.264 or H.265 playback inside a normal page and your streams arrive as HTTP-FLV, WebSocket-FLV or HLS. Skip it if you depend on MPEG-4, MP3, WebRTC, PTZ controls, watermarking, SEI extraction or encrypted streams: the README lists all of those under the PRO build, not this one. Before committing, verify three things against your own stream: that your H.265 stream arrives with flv id 12 or as enhanced-rtmp, that your server sends access-control-allow-origin when you pull over HTTP-FLV, and that the GPL-3.0 terms fit how you distribute the player.

Frequently asked questions

Official sources

1. langhuihui/jessibuca on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases