// Lossy Neural Compression Engine ⬡ Beta · from PoC

L.I.V.

Lossy Implicit Vector

MIKE stores the formula. LIV stores the memory of the detail a codec threw away.

Every lossy codec — JPEG, MP3, H.264 — discards what it thinks you won’t miss. LIV compresses harder than that, then puts a small neural model in the decoder that restores the discarded detail on the way out. The model ships once and costs zero bytes in your files. Turn it on and the same picture, sound or video fits in less space.

// The lossy sibling to MIKE. MIKE is the mathematician — it finds the exact rule and is provably lossless. LIV is the artist — it remembers what detail belongs there and paints it back. Both are real, both have receipts, and both are honest about where they don’t win. LIV is early — a research beta with measured results, not a shipping product yet.

// video · aggressive H.264 + AI Restore · held-out frames

542 KB→276 KB

An aggressive encode plus the free in-decoder restorer matched a plain encode of nearly double the size — same quality (31.0 dB), 1.96× smaller. The AI lives in the decoder, so those bytes never touch your file.

And it’s fast where it matters. On a fixed camera, restoring only the blocks that move hits real-time on a plain CPU — 26× less work at −0.02 dB. Built for surveillance archives.

// free multiple · video, fixed content

1.96×

Storage cut roughly in half at equal quality, on top of H.264 — for zero per-file overhead. Stills ~1.22×, audio ~1.33×. Honest numbers below.

// Where LIV stands — at a glance

A free compression multiple on top of the codec you already use.

Every number below is measured on real media, held out from training, at an aggressive base-quality operating point. “Free multiple” = how much bigger a plain codec file has to be to match LIV’s AI-restored quality. The model is amortised in the decoder, so it adds zero bytes to each file.

Media	With AI Restore	Detail
Video (H.264)	1.96× · ~49% smaller	per-camera / per-title — the standout; a fixed camera makes this permanent
Audio (MP3)	1.33× · ~25% smaller	cross-content held-out; spectral metric — wants a formal listening test
Still images (JPEG)	1.22× · ~18% smaller	universal restorer, cross-content held-out — the cleanest, most honest number
Already-lossless / random	— no gain	nothing to restore — and we say so

// numbers grow at aggressive base quality (most artifacts to undo) and shrink toward the codec at high quality · these are engineering-grade gains in the neural post-filter band, not magic

// New — the lossless byte-exact tier

And now LIV is lossless too — byte-for-byte, no AI in sight.

The AI tier above trades a guess for size. Its sibling MIKE (LIV’s lossless brother) just had a breakthrough in the Motion-JPEG arena, and we ported its engine straight into LIV. This tier touches no pixels and invents nothing: it Huffman-decodes each JPEG frame into its exact token stream, stores that far more efficiently, and re-encodes to the original bytes on the way back. What comes out is cmp-identical to what went in — safe for a court, a clinician, an auditor.

The trick for video: LIV pools every frame’s tokens into one stream before compressing, so the backend dedups the structure similar frames share — the intra-frame win of still JPEG plus the inter-frame redundancy of video. Container-agnostic: raw MJPEG, or JPEG-in-AVI/MOV/MKV.

Input	Lossless, byte-exact	Detail
Motion-JPEG · full motion	1.86× · ~46% smaller	every frame still round-trips exactly; less shared structure to dedup
Single JPEG still	~1.1–1.25×	entropy transcode of one frame (MIKE’s proven photographic range); always exact
Progressive / arithmetic / odd JPEG	— falls back	if it can’t round-trip perfectly, LIV discards the transcode — never wrong, only smaller

// measured on real MJPEG clips, restored output cmp-identical to source · beats a plain x264-lossless re-encode on the same MJPEG clip (exact-original vs re-encoded) so LIV picks it automatically · liv pack clip.avi out.liv

// New — one engine, two modes you choose per file

Lossless when it must be exact. Lossy when you say so.

Because LIV decodes each codec to its exact quantised DCT coefficients, the same liv pack can either re-pack them byte-for-byte, or — on your word — drop the smallest coefficients in the codec’s own transform domain and re-emit a still-valid, smaller stream. One flag, --quality N, slides continuously from certified-lossless down. A neural drop-restorer buys detail back on decode.

	Lossless mode certified	Lossy mode --quality N
Command	liv pack in out	liv pack in out --quality 4
Guarantee	byte-for-byte — SHA-256 preserved	valid, playable, smaller — never corrupt
Mechanism	entropy transcode (re-pack the VLC layer)	codec-domain coefficient drop, decode-verified
On decode	cmp-identical to the source	microAI drop-restorer recovers detail
Codecs	MJPEG · JPEG	JPEG · MP3 · H.264 (AI-restore tier)
Typical gain	MJPEG ~1.86×	1.22×–1.96× (AI-restore)
Made for	archival · evidentiary · chain-of-custody	storage & bandwidth — your quality/size call

The moat isn’t the ratio — it’s the hash

Because restoration is bit-for-bit, SHA-256(restored) = SHA-256(original). The recompression is invisible to any evidentiary chain-of-custody seal computed over the file bytes — including ONVIF Export File Format and IEC 62676-2-32 (RSASSA-PSS over SHA-256). A recording recompressed by LIV and later restored still passes its original authentication. Lossy or re-encoding competitors change the bytes, break the hash, and are inadmissible. That edge is patented.

What LIV declines — on purpose

Codecs whose entropy layer is already arithmetic sit at the floor and are stored verbatim — measured, not assumed: H.264-CABAC, H.265/HEVC, H.266, AV1, VP8/9, JPEG-2000/XL, FFV1 all yield ~0%. LIV detects this and never inflates. Knowing the boundary is the honesty.

// New — the streaming tier

Store it compressed. Stream it back decompressed, from any point, with proof.

Everything above is whole-object: one file in, one file out. That is right for an archive and wrong for a stream — you cannot serve minute 12 of an hour-long segment without first decompressing the eleven before it, and a single LZMA stream has no seek points at all.

The streaming profile cuts an object into independently-decodable chunks with an index, so a byte range costs only the chunks it covers. It is an engine, not an app: it exposes a plain HTTP origin that anything can sit in front of — a ComputeEngine streaming proxy, an nginx edge, a player, curl.

ComputeEngine proxy ─┐ nginx / CDN edge ────┼──▶ liv-tier origin ──▶ vault of chunked .liv objects player / curl ───────┘ Range: bytes=a-b → 206 + only the chunks it touched

Three things ride on every response, and they are what make this a LIV origin rather than a file server. Accept-Ranges is advertised only when the object is genuinely byte-seekable. X-Liv-Certified says whether the bytes are byte-exact to the original. X-Liv-Merkle plus a per-chunk proof lets the caller verify what it was handed without ever holding the whole object — because an archive that cannot prove a partial read is not an archive.

Methods supported for streaming

Method	Fidelity	Seekable	What it is for
zstd	byte-exact	✓ byte ranges	the streaming default — near-LZMA ratio, far faster decode
xz (LZMA 9)	byte-exact	✓ byte ranges	best ratio, slowest decode — the cold-archive choice
deflate	byte-exact	✓ byte ranges	fast; wins on some small or already-packed chunks
stored	byte-exact	✓ byte ranges	the never-inflate floor — kept verbatim, never grown
jpeg-lossy	lossy · PSNR-floored	✗ read whole	still frames — searches for the smallest file clearing your quality floor
time-indexed video	— roadmap	—	wants GOP segments and a time index, not byte offsets. Not built yet

// every chunk picks its own codec: each candidate is tried, the smallest that round-trips exactly wins, verbatim is the floor · a file with a compressible header and an incompressible body stops paying for the wrong codec across the whole thing

✓ Certified is a one-way door

A lossy object can never be re-shaped back into a certified one — the original bytes are gone, so the result could not honour the claim. The code refuses it; it is not left to you to remember.

✓ Re-shape without the original

Archive cold at maximum ratio, then re-cut to hot for scrubbing — from the stored copy alone, with the source file long deleted. The object id is the hash of the original, so it survives every move.

✓ Two promises, still enforced

A chunked object is proved byte-identical before it is trusted, and if it would be no smaller than the original the ingest falls back rather than storing something worse. By proof, not assumption.

✗ Lossy video streaming is not built

Byte ranges address original octets, which a lossy object no longer has. Lossy video needs GOP segments and a time index — a different coordinate system. Objects advertise seekable so nothing has to guess.

# tier a segment as a seekable object, and promote it later without the original
liv-tier chunk   vault cam3.seg --profile max-ratio      # cold archive tier
liv-tier reshape vault <id> --profile fast-seek          # hot: seek points
liv-tier stream  vault <id> --range 1500000+64          # 1 chunk decoded, byte-exact

# stand it up as an origin for a proxy / gateway / player
liv-tier origin  vault 0.0.0.0:8098
curl -H "Range: bytes=1500000-1500063" \
     http://host:8098/liv/v1/objects/<id>/data   # 206 + X-Liv-Merkle + proof

// lossy: --profile lossy --min-psnr 34 · the floor is the dial · liv-tier info shows the chunk index, per-chunk codec mix and Merkle root

// The idea

Throw away more — then paint it back on the way out.

A lossy codec is a compromise: quality for size. LIV moves the compromise. It lets the codec throw away more (a smaller file), and rebuilds the missing detail with a model that lives in the player, not the file.

01 · BASE

Compress aggressively

Encode with an ordinary codec — JPEG, MP3, H.264 — turned up hard. Tiny file, visible artifacts. Standard, compatible, nothing exotic on the wire.

02 · RESTORE

The microAI in the decoder

A small neural model — shipped once with the player, or once per camera — reconstructs the detail the quantiser discarded. It isn’t in your file, so it costs zero per-file bytes.

03 · DELTAS ONLY

Restore just what changed

Video frames barely differ. LIV restores only the blocks that moved and reuses the rest — near-free on a fixed camera (26×), the trick that makes it fast.

// The working mode — AI on compressed data

Two modes. One switch. You decide when the AI touches your data.

LIV never edits your file silently. The restorer is a mode you turn on, with a status badge that says so — because on some data (evidence, medical, forensics) a model that invents plausible detail is worse than useless. So we make the line explicit.

◻ AI Restore : OFF — certified

Standard mode

You get exactly the bytes the base codec produced — the aggressive stream, untouched. This is the certified original: what a court, a clinician or an auditor should see. Small, honest, exact-as-stored.

◼ AI Restore : ON — enhanced

AI Restore mode

The decoder’s microAI reconstructs the discarded detail on playback — sharper picture, cleaner sound, same file. Labelled “enhanced, non-certified”: it’s a reconstruction, a very good guess, never presented as the ground truth.

// the model is amortised: shipped once in the decoder (stills/audio) or once per camera (video) — it is not stored in, and adds nothing to, each compressed file · for verifiable content, a true-residual option sends the real error instead of trusting the prior

// The receipts · measured benchmarks

Every modality, held out from training, honest metric.

Each row: the aggressive base codec, then the same file with AI Restore on, then the plain-codec file you’d need for the same quality. The gap between them is the free multiple — storage you save for no per-file cost. Held-out means the model never saw these during training.

Video · H.264held-out frames · quality = PSNR · 20k-param decoder model

Encode	Size	Quality	Note
plain H.264 (CRF 32)	275,927 B	28.81 dB	the aggressive base
LIV = base + AI Restore	275,927 B	31.04 dB	+2.23 dB · free
plain H.264 (CRF 26)	542,108 B	31.0 dB	what you’d need for the same quality

// LIV matched a 542 KB encode at 276 KB → 1.96× smaller · net of honestly-charged model weights: still 1.5–1.8×, vanishing on real (large) footage

Audio · MP3cross-content held-out file · quality = spectral SNR

Encode	Size	Quality	Note
plain MP3 (24 kbps)	188,701 B	13.98 dB	the aggressive base
LIV = base + AI Restore	188,701 B	15.76 dB	+1.78 dB · free
plain MP3 (32 kbps)	251,525 B	16.24 dB	what you’d need for the same quality

// 1.33× smaller · spectral SNR is a proxy — a formal listening test (PEAQ/ViSQOL) is the honest next step, and we say so

Still images · JPEGuniversal restorer · 24 unseen images · quality = PSNR

Encode	Size vs base	Quality	Note
plain JPEG (q12)	1.00×	baseline	the aggressive base
LIV = base + AI Restore	1.00×	+0.97 dB	held-out · free
plain JPEG (larger q)	1.22×	matched	what you’d need for the same quality

// trained on 300 images, tested on 24 it never saw — held-out matched train (1.22× vs 1.23×), so it generalises, it doesn’t memorise

// one small engine (~5k–20k parameters) · the decoder is a plain forward pass, headed for a sovereign Rust/candle port · gains measured at aggressive base quality where artifacts are worst

// Fast enough?

Small model, and restore only the deltas.

The decoder is just a forward pass, so speed is a dial — two levers, both measured.

LEVER 01 · SHRINK

4× smaller, same win

The restoration task never needed a big model. A 5.5k-parameter version keeps the full 1.96× and runs real-time on a plain CPU at SD resolution.

LEVER 02 · DELTAS

Only what moved

Restore the changed blocks, reuse the static background. On a fixed camera that’s 3.8% of the frame — a 26× speed-up at −0.02 dB, essentially free.

LEVER 03 · GPU, EVERYWHERE

One shader, every device

The restore is now a GPU compute shader in the same engine — Vulkan on Android, Metal on iOS, desktop too. Built and bit-identical to the CPU path; on a phone GPU the tiny per-frame conv is trivial → HD real-time.

// Now real, in the engine: the delta-only decoder restores just 3.7% of tiles on a static camera — 26.9× less compute, a full clip in 15s vs 104s, quality held at +0.68 dB (vs +0.73 full). On a phone GPU the tiny remaining conv is trivial → HD real-time.

// Where LIV earns its keep

An archival codec for security footage.

Every constraint lines up on one use case — and it’s the one where the storage bill actually hurts.

✓ Halve the storage bill

CCTV records forever; storage is the cost. ~1.96× is money straight off the drive or cloud invoice.

✓ A fixed camera is a gift

It films the same scene forever, so a per-camera model is a permanent, legitimate match — and re-tunes itself nightly as light shifts.

✓ Real-time on a plain box

Static background + delta-only restore = 26× less work. No GPU, no special hardware, restore on review or overnight.

✗ Never as evidence, unlabelled

The restorer guesses. Restored footage is “enhanced, non-certified”; the original aggressive stream stays the certified copy for court.

// The part nobody else prints

What LIV is — and honestly isn’t.

Neural restoration is real and useful. It is also easy to oversell. Here’s the truth, same as MIKE.

✓ A real, free multiple

1.2–2× smaller at equal quality, on top of the codec you already use, for zero per-file bytes. Measured, held out, reproducible.

✓ Fast where it counts

Shrink the model and restore only the deltas and it runs real-time on a plain CPU for a fixed camera. No GPU required.

✗ Not magic, and not novel-physics

These are engineering-grade gains in the known neural post-filter band — not a 10× revolution. Anyone claiming that is selling something.

✗ It hallucinates — mind the use

The video win is strongest per-camera; audio’s number is a proxy pending a listening test; and on evidence or medical data you must keep the certified original.

// Origin story

How LIV was born

Olivia — the original L.I.V.

I was grinding on MIKE, trying to push it past the one wall compression can’t argue with: entropy. Squeezing an already-compressed file is a fool’s errand — the math simply says no. MIKE had already beaten 7-Zip and RAR where the data has structure, so I’d made my peace and left it there.

Then my friend Victor called. “In security footage we store enormous amounts of data — it costs us a fortune. Can’t MIKE help?” And I said no — flatly. Security footage is lossy, and MIKE is lossless; different worlds. End of call.

But the thought wouldn’t leave. Wait a minute… what if I don’t replace JPEG, MPEG and MP3 — what if I push them further than they’re supposed to go, and teach something to bring the lost detail back? It lingered for days.

And while it lingered, my youngest daughter Olivia — Liv — planted her hands on her hips and asked the only question that mattered:

“Dad — you built a whole program for Mike. Where’s my program?” — Olivia (Liv), who was not going to be out-done by her brother

I know female jealousy when I see it coming. And just like that — Victor’s problem, the lingering idea, and a daughter who wanted her name in lights — Lossy Implicit Vector was born. A human name first, an acronym made to earn its letters second, exactly like MIKE:

Lossy — unlike MIKE, LIV lets go. Pictures, sound and video, where the eye and ear forgive far more than a checksum ever would.
Implicit — the intelligence isn’t in the file. It’s an implicit model living in the decoder, reconstructing detail instead of storing it.
Vector — a compact learned representation does the remembering, so a few thousand parameters stand in for a great deal of discarded data.

LIV puts a micro-AI engine right inside the codec, trained to understand how the picture changes. It lets JPEG, MPEG and MP3 throw away more than they safely should — and then re-establishes parity, bringing the detail back as if you’d encoded at high quality all along. Where MIKE is the mathematician who stores the exact rule, LIV is the artist who remembers what the picture is supposed to look like — and paints it back.

It’s built for Victor’s problem: security footage. Decompress a whole archive back to a big file for viewing, or scrub it frame by frame on a computer — the frame-decode speed just tracks how much computing power you throw at it. And because it’s still evolving — we think there’s more to push — the µAI mode is still just a mode. That’s the beta. Let’s see how it grows.

LIV is born.

With thanks and dedication to:

— my daughter Olivia (Liv), who wanted her own program — and was absolutely right to;

— my friend Victor, whose one honest question turned a “no” into a whole engine;

— and her brother Miguel (Mike), for going first.

// Spoiler: I have another daughter — Madalena. So don’t be surprised if a MAD — or a Maddie — shows up on this site before long. IDK. We’ll see.

// Status

Beta — and the engine is real now.

LIV started as a set of honest benchmarks. It is now a working engine. The sovereign Rust decoder exists — a hand-rolled forward pass, no ML framework — and it matches the reference to one least-significant bit. A self-describing .liv container carries the method (certified lossless, or AI-enhanced) and the media type, and packs a pristine clip 6.8× before the restore even runs. Full round-trip on a real clip: base 31.47 dB → AI-restored 32.21 dB (+0.73), end to end. And there’s a first beta APK below — sideload it and test on your phone. Player plugins and in-app playback come next; the hard part is built and proven.

⬡ BETA · engine working ✓ sovereign decoder · 1-LSB parity ✓ .liv container · lossless round-trip ✓ MJPEG lossless byte-exact · AI-restore: JPEG · MP3 · H.264 ✓ GPU backend · wgpu · bit-identical ✓ delta-only · 26.9× less compute ✓ Android APK builds · GPU on the phone ◷ on-device test + player plugins · next Shipping sibling → MIKE

// L.I.V. · managed service Enterprise

LIV is now enterprise-only.

LIV has moved out of open beta. Following a signed term sheet, the whole engine — the byte-exact lossless storage tier, the in-decoder AI Restore, and the new layered analytics format — is now delivered as a managed enterprise service under an exclusive licence, not a public download. The measured results stand and the benchmark pack stays public so they’re independently checkable — but the binaries go only to enrolled beta-program members and enterprise partners.

L.I.V. is not a public download. Adamantware OÜ has signed a distribution and exclusivity agreement with HealthTech Portugal — please contact them for any further information.

Contact HealthTech Portugal

PUBLIC · reproducible

Benchmark pack

The sample clip, its .liv, and the exact numbers — so you can reproduce our result and compare LIV against any other codec on the same input. Includes verify (cmp) and cross-tool compare instructions. This stays public so the benchmark is coherent and honest.

Benchmark pack · .tgz · 2.1 MB

// lossless MJPEG — unpack is cmp-identical to the source

BETA PROGRAM · binaries

Get the LIV binaries

One engine, the full suite — provisioned to enrolled beta-program members and enterprise partners only, not a public download:

• Windows — GUI & command-line
• Linux — GUI & command-line
• Android app
• Drop-folder compress service — Windows & Linux

Request beta access