# Real time transcoding

**URL:** <https://forum.babylonjs.com/t/real-time-transcoding/64115>\
**Category:** Feature requests\
**Created:** [September 17, 2026, 8:28am UTC](https://forum.babylonjs.com/t/real-time-transcoding/64115 "2026-09-17T08:28:34Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![phaselock](https://avatars.discourse-cdn.com/v4/letter/p/da6949/32.png) [@phaselock](https://forum.babylonjs.com/u/phaselock)\
**Post date:** [September 17, 2026, 8:28am UTC](https://forum.babylonjs.com/t/real-time-transcoding/64115/1 "2026-09-17T08:28:34Z")

</div>

Any interest for real time transcoding as an upgrade to ktx2 textures? Would help reduce an extra step prepping texture assets for users already on web image formats (avif, webp etc).

Ref: [GitHub - Ludicon/spark-gltf-demo: Real-Time GPU Texture Compression Demo · GitHub](https://github.com/Ludicon/spark-gltf-demo)

---

<div class="post-metadata">

**Author:** ![Deltakosh](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/deltakosh/32/26635_2.png) [@Deltakosh](https://forum.babylonjs.com/u/Deltakosh)\
**Post date:** [September 17, 2026, 6:34pm UTC](https://forum.babylonjs.com/t/real-time-transcoding/64115/2 "2026-09-17T18:34:44Z")

</div>

question for @alexchuber for sure

---

<div class="post-metadata">

**Author:** ![increasinglyHuman](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/increasinglyhuman/32/51340_2.png) [@increasinglyHuman](https://forum.babylonjs.com/u/increasinglyHuman)\
**Post date:** [September 19, 2026, 3:42am UTC](https://forum.babylonjs.com/t/real-time-transcoding/64115/3 "2026-09-19T03:42:21Z")

</div>

+1 to the feature — real-time encoding from AVIF/WebP is the only practical route to GPU-compressed textures for _user-uploaded_ content, where there’s no chance to pre-bake KTX2. That’s a real gap for UGC-heavy apps like ours.

One request on the how: spark.js is free only for non-commercial use or under $100k lifetime revenue, and its shaders are under a separate EULA, so it couldn’t be a core dependency of an Apache-2.0 engine, and commercial projects couldn’t build on it. Could this be designed as a pluggable encoder interface (image in → compressed `InternalTexture` out, format picked from device caps), with an open-source encoder as the reference implementation? Then anyone who has licensed Spark can plug it in, and everyone else still gets the feature.

---

<div class="post-metadata">

**Author:** ![alexchuber](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/alexchuber/32/52000_2.png) [@alexchuber](https://forum.babylonjs.com/u/alexchuber)\
**Post date:** [September 22, 2026, 9:24pm UTC](https://forum.babylonjs.com/t/real-time-transcoding/64115/4 "2026-09-22T21:24:38Z")

</div>

I like the idea! Yeah!

Bouncing off @increasinglyHuman , I think we’d want to create our own implementation. A few things top of mind:

- If there’s interest in this being a separate package, then we could follow the existing KTX2 decoding conventions. Its implementation is split between `@babylonjs/ktx2decoder` (more agnostic logic) and `@babylonjs/core` (more Babylon-focused logic).
- There’s a transcoding decision tree in the ktx2 decoder package that may be useful here…? Either to reference or reuse.
- This could be a nice loader option
- We’d need to clarify the tradeoff (like how there’ll be a longer load time than using .ktx2 images outright, I’d imagine?)

---

<div class="post-metadata">

**Author:** ![phaselock](https://avatars.discourse-cdn.com/v4/letter/p/da6949/32.png) [@phaselock](https://forum.babylonjs.com/u/phaselock)\
**Post date:** [September 30, 2026, 5:11am UTC](https://forum.babylonjs.com/t/real-time-transcoding/64115/5 "2026-09-30T05:11:49Z")

</div>

> [@alexchuber](#):
>
> I think we’d want to create our own implementation

That’s what I thought.

> [@alexchuber](#):
>
> - If there’s interest in this being a separate package

Ideally, I’d prefer the implementation as part of core so ktx2 becomes completely transparent. But if the code bloat is huge, a separate package would be best. Also have to consider back-compat.

> [@alexchuber](#):
>
> - We’d need to clarify the tradeoff

erm, depends on the perf from implementation. Targeting client gpu for the transcoding shouldn’t take more than a few frames, so the load time would be far shorter vs fetching the larger ktx2 files. A simple prototype for testing/benchmarking might be best?