Stutter fix (root cause):
- 0.4.7 made the GPU upload a memcpy, but toRgba() in JavaCvBackend was
still doing BufferedImage.getRGB() + a per-pixel ARGB->RGBA loop. That
loop ran 20-50ms per 1080p frame on the decode thread. When it slipped
behind real-time, the audio buffer drained, backpressure vanished,
the decoder burst-fired catch-up frames into the single-slot
AtomicReference (dropping 11 of 12 for ~0.5s of buffer), then blocked
again on the next audio refill -- exactly the periodic stutter the
user reported.
- Force the grabber to output AV_PIX_FMT_RGBA (=26) via setPixelFormat.
Now frame.image[0] is already a ByteBuffer of RGBA bytes; we just
copy it into a fresh direct buffer and hand it to the upload path.
The colorspace conversion happens inside swscale (native SIMD) at
<1ms per frame, so the decoder consistently keeps real-time pace and
the audio backpressure stays smooth.
- Removed Java2DFrameConverter / BufferedImage usage entirely.
Defensive delete fix (potential crash on anchor delete):
- Entry.close() now calls TextureManager.release(id) before closing the
texture itself. Without this, a RenderType cached by Identifier could
still try to bind the dead GL handle on the next frame and crash the
render thread. The crash report the user reported couldn't be located
(no crash-reports/ folder) so this is the most plausible suspect from
reading the code; full diagnosis still pending the tail of latest.log.
- build.gradle: optional -Pplatform=<id> property switches the build into
a fat-jar mode where javacv 1.5.13 + javacpp + ffmpeg 8.0.1 (java + the
picked platform's native jar) are all nested into the mod jar via
Fabric loom's `include` directive. Fabric loader unpacks them at
runtime, so users no longer need -Xbootclasspath/a:... or 5 separate
jars in .minecraft/libraries.
- Without -Pplatform, the build produces the same small ~85KB vanilla
jar as before, so devs/server-side and bring-your-own-JavaCV setups
still work.
- Per-platform artifacts: video_player-<platform>-0.4.8.jar where
<platform> ∈ windows-x86_64 / linux-x86_64 / macosx-x86_64 /
macosx-arm64. Sizes 21-32MB.
- README: STEP 5 (the long JavaCV manual-install + -Xbootclasspath
section) is gone. New STEP 4 just says 'pick the jar for your OS'.
Also added a warning about removing the old -Xbootclasspath JVM arg
when upgrading, since duplicate JavaCV on the boot classpath can
silently break decoding.
- Replace per-pixel RGBA->ABGR loop in Entry.upload() with a single
MemoryUtil.memCopy() into NativeImage's native buffer. The two layouts
are identical when viewed as little-endian bytes, so no swap is needed.
Cuts 1080p upload time from a ~2M-iter Java loop to one native memcpy.
- Move the frame-pump tick from 20Hz client tick (END_CLIENT_TICK) to
per-render-frame (LevelRenderEvents.START_MAIN). At 60+fps display vs
24fps source, this removes the worst stutter window where a decoded
frame waited up to 50ms for the next tick. Distance-gain math stays on
20Hz where it's plenty.
- Bump version 0.4.6 -> 0.4.7 in gradle.properties and README.
- new: config/video_player.json on first server start. Field preload_urls
is a list of HTTP(S) URLs (≤256 chars each) that the server broadcasts
via PreloadPayload to every player when they finish joining, so common
videos are warmed into each client's video_player_cache/ before they
ever play. Reuses the same PreloadPayload + VideoCache path as
/videopreload, so chat feedback ("[videopreload] 완료") still applies.
- config is loaded once at mod init; invalid entries are dropped with a
WARN line. Edit + restart server to apply changes.
- audio: distance attenuation now uses the panel center (width/2, height/2
offset from the anchor along the renderer's right/up axes) instead of the
anchor block corner, so a 4x4 panel sounds like it's coming from the
middle of the screen and not the bottom-left.
- preload: each client now posts a chat line on start / completion / failure
/ cache-hit, so a command-block sequence like /videopreload -> /videoplace
can be timed against the visible "[videopreload] 완료" message.
- safety: VideoPlayback.tick() verifies the anchor BE still exists at each
active position and forcibly stops playback if it doesn't — covers any
edge case where BLOCK_ENTITY_UNLOAD doesn't fire.
- /videopreload feedback now explicitly states "완료 알림 후 재생하세요".
- fix: stop playback when anchor block entity unloads (BLOCK_ENTITY_UNLOAD)
so deleting a video while audio is playing actually silences it.
- fix: force-stop SourceDataLine and grabber from outside the worker thread
so a blocked line.write() / grab() unblocks immediately on close.
- perf: tune FFmpeg streaming options (buffer_size, probesize, analyzeduration,
max_delay, fflags=+genpts, reconnect_delay_max) and pre-size audio line buffer
to ~0.5s to smooth out mid-stream stutter.
- feat: /videopreload <url> broadcasts a S2C PreloadPayload to all clients;
each client downloads the URL to <gameDir>/video_player_cache/<sha256> and
subsequent playback reads from the local file instead of streaming.
Gated by COMMANDS_GAMEMASTER (op level 2), so command blocks can invoke it.
JavaCPP Loader (javacpp.jar) ships pure-Java code that needs its own
JNI bridge DLL (jnijavacpp) to extract & link other native libraries.
That bridge lives in the platform-specific javacpp-<os>-<arch>.jar
which the old install guide silently omitted — users following it
ended up with a black panel and an UnsatisfiedLinkError for jnijavacpp
because FFmpeg natives could never be loaded.
This bumps the required JavaCV jar list from 4 to 5, updates the
-Xbootclasspath/a: examples on all three OSes, and adds a diagnostic
note for the matching log line.
Docs-only change; mod code is unchanged from v0.4.2.
Reviewer caught that the README still pointed users at video_player-0.4.1.jar
even though 0.4.2 fixes the stick missing-model issue. Updated:
- "current version" header → 0.4.2
- STEP 4 download filename → video_player-0.4.2.jar
- build output path → build/libs/video_player-0.4.2.jar
- STEP 6 verification: explicitly call out that 0.4.1 and below have a known
stick-icon defect (unprefixed item/generated parent rejected by the 26.1.2
model loader) so users on those versions need to upgrade, not just dedupe.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
User followed README using %APPDATA% in -Xbootclasspath/a: and the official
Mojang launcher passed the literal string through to Java without expanding
it, so boot classpath ended up empty and video stayed black despite all 4
JavaCV jars being present.
Replaced the %APPDATA% example with an absolute C:\Users\<name>\AppData\
Roaming\... template, added a callout warning that the launcher does not
expand env vars in JVM args, and pointed at `echo %APPDATA%` from cmd as the
way to discover the right path.
Also corrected the ffmpeg jar filenames: the bundle zip uses the short form
(e.g. ffmpeg-windows-x86_64.jar), not the Maven-style
ffmpeg-8.0.1-1.5.13-windows-x86_64.jar.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
User reported Incompatible-mods crash because they downloaded
fabric-api-0.140.2+1.21.11.jar from Modrinth (Modrinth's version-filter URL
param does not always restrict the listing to the requested game version).
Replaced the generic search-page link with the direct CDN URL of
fabric-api-0.149.0+26.1.2.jar and added a callout telling readers to verify
the filename suffix ends in +26.1.2.jar.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Previous README used "방법 A/B/C" terminology that confused readers and
recommended Prism over the official launcher. Per user feedback, restructured
into a step-by-step guide assuming the official Mojang launcher:
1. boot 26.1.2 vanilla once to create .minecraft
2. run fabric-installer-1.x for client / 26.1.2 / loader 0.19.2
3. open .minecraft/mods (per-OS instructions)
4. drop fabric-api + video_player-0.4.1.jar, remove old versions
5. install JavaCV — two routes:
5-A. Prism Launcher (easiest)
5-B. official launcher via -Xbootclasspath/a: with Windows/macOS/Linux examples
6. verify with /videostick
Moved Maven coords to a developer footnote. Added install verification step
to disambiguate "missing texture" symptom from leftover old-version jars.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
