Add instant-replay plugin

[georgeparamore]

Instant Replay

A rolling-buffer clip recorder for OSRS — like ShadowPlay's instant replay. Keeps the last N seconds of gameplay in memory and automatically saves a video clip on new personal bests, valuable drops, collection log slots, pets, quests, combat achievements, and deaths, or on a manual hotkey.

How it captures: via DrawManager — the same API the core screenshot plugin uses. It only sees the game's rendered frames (never the desktop or other windows), only runs while logged in, keeps frames in memory only, and writes to disk only on a trigger. Nothing is uploaded anywhere.

Compliance: Java only, no native code, no external processes, no reflection, no runtime downloads. One third-party dependency — JCodec, a pure-Java MP4 encoder — used for the optional MP4 output; verification metadata is included in this PR. Clips are written as MJPEG-AVI by a small hand-rolled muxer, or as MP4 via JCodec (encoded in parallel chunks off the game thread).

Video only — capturing game audio from inside the JVM isn't practical under Hub rules; this is noted in the README.

Repo: https://github.com/georgeparamore/instant-replay

[runelite-github-app]

New plugin instant-replay: https://github.com/georgeparamore/instant-replay/tree/b27fccba827bbc6beecb8fe586e7bf496ef2666f

[runelite-github-app]

This plugin requires a review from a Plugin Hub maintainer. The reviewer will request any additional changes if needed.

---

Internal use only: Reviewer details Maintainer details

[georgeparamore]

Thanks for the automated feedback. To clarify where those flags come from:

The System.out / System.err / printStackTrace usages are entirely inside the third-party JCodec dependency (org.jcodec), not in the plugin's own code. JCodec is a pure-Java H.264/MP4 encoder, used only for the optional "MP4" clip format. The plugin's own classes use slf4j (log.*) exclusively — there are no System.out/err/in or printStackTrace calls anywhere in com.cliprecorder.

I can confirm the split: a scan of the plugin source has zero matches, while ~11 of JCodec's bundled classes reference those APIs internally.

A couple of options, whichever you prefer:

1. Keep JCodec for in-plugin MP4 export (smaller files than the default MJPEG-AVI). The flagged I/O is confined to the dependency and isn't reachable in a way that spams the client — but I understand if a dependency tripping the scanner isn't acceptable.
2. Drop the MP4 feature / JCodec entirely, shipping AVI-only. That makes the plugin 100% pure-JDK with no third-party dependency and no verification metadata needed, and the scanner passes clean. I'm happy to do this if you'd rather not take on the dependency.

Let me know which you'd prefer and I'll adjust the PR accordingly. Thanks for your time reviewing!

[riktenx]

use of jcodec dependency is not allowed

[georgeparamore]

Understood, thanks - I've removed JCodec entirely. The plugin now ships AVI-only (MJPEG-in-AVI via its own muxer) and is 100% pure-JDK with no third-party dependencies. I've also reverted the verification-template and verification-metadata changes, so this PR is now just the single plugins/instant-replay manifest file. Build is green and the scanner no longer flags anything.

[georgeparamore]

use of jcodec dependency is not allowed

Got it removed and updated, check it out!

[Alexsuperfly]

set build=standard in runelite-plugin.properties since you arnt using any additional dependencies anymore

[georgeparamore]

set build=standard in runelite-plugin.properties since you arnt using any additional dependencies anymore

Done - switched to build=standard and updated the manifest commit. Thanks!

[Alexsuperfly]

• use of Runtime::availableProcessors is not allowed

[georgeparamore]

use of Runtime::availableProcessors is not allowed

Done - removed it, the encode pool now uses a fixed thread count. Updated the manifest commit, build is green.

[Alexsuperfly]

i should have been more descriptive before, it wasnt just the processors, but also maxMemory getting flagged, really any runtime inspection

[georgeparamore]

i should have been more descriptive before, it wasnt just the processors, but also maxMemory getting flagged, really any runtime inspection

No worries - removed maxMemory too. There's no runtime inspection left anywhere now; the buffer just uses a fixed 256 MB ceiling that's safe on the stock client. Manifest updated.

[georgeparamore]

i should have been more descriptive before, it wasnt just the processors, but also maxMemory getting flagged, really any runtime inspection

Let me know if there's anything else

[georgeparamore]

use of jcodec dependency is not allowed

anyway I can get an update on my progress here? :)

[riktenx]

going forward we only allow one pr open at a time (github itself will also enforce this), pick the one you want to submit first and create a fresh pr for it

[georgeparamore]

going forward we only allow one pr open at a time (github itself will also enforce this), pick the one you want to submit first and create a fresh pr for it

Sounds good - opened a fresh PR for Instant Replay here: #15098. Thanks!