Jetplay: Audio and Video Playback for JetBrains IDEs

So apparently JetBrains IDEs have never supported audio or video playback.

So when you open a video in IntelliJ, PyCharm, WebStorm, or any other JetBrains IDE, all you get is to set up a file association so some other program can open it. Which, in my opinion, is kind of cooked (VSCode supports this, btw.)

So why not build a plugin to handle this all within the IDE itself? So I built Jetplay.

This solves the dumb problem of audio and video playback support within your JetBrains IDE. Feel free to install it by clicking below:

The rest of this writeup will mostly be about the hoops to build this and my engineering decisions.

Just Use a Browser

So apparently JetBrains already ships a browser. I think it’s already used in JetBrains official Markdown plugin for rendering, but there are other plugins harnessing this, like a PDF Viewer Plugin.

What actually lies under the hood is JCEF¹ , which is basically Chromium (and most importantly, allows playback of audio and video). The first version did the obvious thing: load a small player page into JCEF and point an <audio> or <video> tag at the file.

And locally, that’s the whole trick: double-click and it plays. JCEF is happy to play a file:// URL, audio or video. The early versions of Jetplay were exactly that, a player with a progress bar and nothing else, and they worked fine.

The loopback server came later, when I added a waveform you could scrub. A null-origin page can play a file:// URL but can’t fetch() and decode its bytes, and drawing a waveform needs exactly that. file:// also has no real Range support² , so seeking was shaky on big files too. So local media moved onto a tiny HTTP server on 127.0.0.1 that hands the page a real http:// URL, with the CORS header it wants, Accept-Ranges: bytes, and a 206 Partial Content for whatever range it asks for.³ Same playback, just a server handling a fetchable URL now.

Remote Development

All of that worked well, but only on local setups, which, for me, recently has been pretty rare. The first time I opened something over RD⁴ , it came apart. Video wouldn’t play at all. Audio would start, run for a couple of seconds, and then randomly cut out.

Architecturally, RD splits it across two machines: the file on the host, the browser on the client (since JCEF only runs there). And a loopback server only answers on its own machine. Put it on the host and the browser can’t reach it; put it on the client and there’s no file to read. Either way the player runs out of bytes, which is the cut-out, and why video never even started.

So I split the plugin in two and let the halves talk over the wire. There are four Plugin Model V2⁵ modules: shared holds the contract, frontend is the player and the loopback server, client renders it in split mode, and backend runs FFmpeg on the host. The client runs its own loopback server, and every byte it needs it pulls from the host over an @Rpc⁶ call. When the browser seeks, the server turns that into readRange(offset, length), the host reads the slice off disk and sends the bytes back. Transcoding runs on the host too, where FFmpeg and the file already are.

You don’t see any of this. You double-click and it plays, whether the file is on your own disk or on a host three time zones away.

What it plays

Pretty much anything. If the embedded Chromium can decode it, it plays the moment you open it.

It’s not over just yet though, Chromium doesn’t support proprietary codecs.⁷ So we need to re-encode all them into codecs Chromium can play with FFmpeg. We bundle FFmpeg⁸ to transcode it to WebM the first time, with a progress bar. Either way you just double-click any registered media, and Jetplay either plays it natively or via a transcoded format

The current list of formats lives on GitHub, and it keeps growing. To install, search for “jetplay” under Settings → Plugins → Marketplace.