// Lossy Neural Compression Engine v0.6.2 · lossless + lossy

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 v0.6.2 is a suite now: byte-exact lossless for eleven legacy video formats, a lossy tier that beats plain H.264 at the same bytes, and a streaming storage tier.

// lossy · real shop-camera footage · H.264 CABAC in · 10 s

322 KB→99 KB

The camera’s own H.264, re-encoded by LIV’s lossy tier: 3.3× smaller. Squeeze plain H.264 into the same 98.7 KB and it reads 31.6 dB; LIV reads 34.9 dB — measured frame by frame against the camera original. The full 140 s recording: 4.21 MB → 670 KB.

And when it must be exact, lossless mode gives eleven legacy video formats back byte-for-byte — the SHA-256 still matches, so the chain of custody does too.

// same bytes as plain H.264 · CCTV

+3.3 dB

A better picture for the same storage — or the same picture for less. On cut-heavy TV drama the lead is +0.7 dB. Every number below is measured; where LIV doesn’t win, we say so.

// Where LIV stands — at a glance

Two modes. Measured on real media.

Lossless when the bytes must survive — DV, MPEG, Flash, Windows Media, Motion-JPEG — with the SHA-256 intact. Lossy when the picture is what matters — streaming, and storage of footage that is not evidence. Every PSNR on this page is frame-exact: both videos decoded, frame i compared with frame i.

Media	LIV	Detail
Video · lossy · CCTV	+3.3 dB at the same bytes	real shop camera, H.264 CABAC in — 3.3× smaller than the camera’s file; 6.3× over the full recording
Video · lossy · TV drama	+0.7 dB at the same bytes	hard cuts every few seconds — 2.1× smaller than the original over the full clip
Video · lossless · 11 formats	byte-exact · 7–47% smaller	MPEG-1/2/4, H.263, Flash, DV, MS-MPEG4, WMV7/8, Motion-JPEG, JPEG — SHA-256 preserved
DV camera file	17% smaller · byte-exact	ties xz -9e — LIV keeps whichever is smaller, so it never loses to it
Pixel-exact masters (720p)	1.24× smaller than FFV1	10.9 MB vs FFV1 13.5 MB vs xz 16.5 MB — every frame identical
AI Restore · video, per camera	1.96× · ~49% smaller	a model trained on that camera — measured per file and switched off where it doesn’t help
AI Restore · audio / stills	1.33× / 1.22×	cross-content held-out; audio is a spectral proxy pending a listening test
CABAC · HEVC · AV1 (lossless)	— stored verbatim	already at the arithmetic floor — never inflated, and we say so

// measured 2026-10-18 on v0.6.2 · lossy rival = plain x264 at its defaults, 2-pass, squeezed to LIV’s exact byte count · lossless rows verified with cmp and SHA-256

// Mode 1 — the lossless byte-exact tier

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

The AI tier 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.

Format	Saved, byte-exact	Verify
MPEG-1	15.1–15.6%	restored bit-for-bit — cmp identical
MPEG-2 (DVD, broadcast)	13.7–15.8%	restored bit-for-bit — cmp identical
MPEG-4 Part 2 (DivX, Xvid)	13.4–14.6%	restored bit-for-bit — cmp identical
H.263	16.9–23.6%	restored bit-for-bit — cmp identical
FLV1 (Flash video)	16.1–18.4%	restored bit-for-bit — cmp identical
MS-MPEG4 (MP42, MP43)	7.2–36.1%	restored bit-for-bit — cmp identical
WMV7 · WMV8	7.0–7.6%	restored bit-for-bit — cmp identical
Motion-JPEG	47.3%	restored bit-for-bit — cmp identical
DV25 (miniDV, DVCPRO)	see real camera files below	restored bit-for-bit — cmp identical

// format coverage from the repo’s self-verifying benchmark (19 encoder outputs, every one restored byte-exact, 50.2% saved overall) · those inputs are generated test patterns, so read the % as coverage, not as a promise — the real-footage numbers follow

Real DV camera files

File	Original	LIV lossless	Result
Handheld miniDV · 720×576	10,240,000 B	8,518,190 B	17% smaller · SHA-256 identical
Broadcast news · DV25	216,000,000 B	188,844,343 B	12.6% smaller · byte-exact

// on long DV, xz’s 64 MiB window finds frame-to-frame repeats the per-block transcode can’t, so liv pack builds both and keeps the smaller — LIV ties xz -9e here and never loses to it

Pixel-exact masters — before the edit

A 720p master, 72 frames of decoded YUV 4:2:0 (99.5 MB) — the files an editor re-grades and re-cuts. Every compressor at maximum, FFV1 (the archive standard), and LIV’s pixel-exact lossless. Bar = stored size.

LZ426.71 MB · 26.8%

ZIP24.78 MB · 24.9%

gzip24.78 MB · 24.9%

RAR19.41 MB · 19.5%

zstd19.12 MB · 19.2%

bzip218.70 MB · 18.8%

Brotli17.83 MB · 17.9%

7-Zip16.83 MB · 16.9%

xz16.53 MB · 16.6%

FFV113.53 MB · 13.6%

L.I.V. lossless10.88 MB · 10.9%

// every frame’s hash identical for LIV and FFV1 · on a fixed security camera the gap is wider: LIV lossless 278 KB vs xz 321 KB vs FFV1 6.73 MB

// Mode 2 — the lossy tier, on real footage

Same bytes as plain H.264. A better picture.

Two real clips that arrived as H.264 CABAC — a shop’s security camera and a TV drama cut every few seconds. LIV’s lossy tier re-encodes each; then plain H.264 (x264 at its defaults, two-pass) is squeezed to exactly the same number of bytes, and both are scored against the original, frame by frame.

10 s segment	Original H.264	LIV size	Plain H.264 at that size	LIV quality	Gain
Shop CCTV · 640×360	322,087 B	98,731 B	31.6 dB	34.9 dB	+3.3 dB
TV drama · 640×360	337,577 B	194,276 B	38.7 dB	39.4 dB	+0.7 dB

// full clips: CCTV 4.21 MB → 670 KB (6.3×) · drama 7.15 MB → 3.42 MB (2.1×) · PSNR over all three planes, frame-exact

✓ The restorer has to earn its place

Since v0.6.1, liv pack tries the AI restorer on sampled frames of this file and records it only if it measurably helps. On these two clips — far from what the model was trained on — it would have cost 2.0 and 9.2 dB, so it stayed off and you get the clean base. On the camera it was trained for, it gains and switches on.

✓ Frame-exact, or it doesn’t count

The common shortcut — ffmpeg’s psnr filter — pairs frames by timestamp, and between two containers it can compare neighbouring frames. On cut-heavy video that under-reads by up to 8 dB. We caught it in our own first numbers; everything here is decoded and compared frame i to frame i.

✗ It doesn’t beat HEVC

LIV’s base layer is H.264 so it plays on everything. At the same size x265 reaches 40.4 dB on the drama clip — about 1 dB above LIV. If your players all speak HEVC, use HEVC.

✗ Never the evidence copy

Lossy is for streaming and for footage past its legal hold. Evidence stays in lossless mode, where the restored file’s SHA-256 matches the camera’s.

// 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	MPEG-1/2/4 · H.263 · FLV1 · DV25 · MS-MPEG4 · WMV7/8 · MJPEG · JPEG	any video → H.264 base (--method ai) · JPEG · MP3
Typical gain	7–47% · DV ~17% · MJPEG ~1.86×	+0.7 to +3.3 dB at plain H.264’s bytes
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.

// 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. A real 140 s shop-camera recording: 4.21 MB as the camera wrote it, 670 KB in LIV — and a sharper picture than plain H.264 at that size.

✓ 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

v0.6.2 — one suite, two modes.

LIV started as a set of honest benchmarks. It is now a suite: the sovereign Rust engine (no ML framework, decoder matched to the reference to one least-significant bit), a self-describing .liv container that records the mode, the lossless transcode for eleven legacy formats, the lossy tier, and a storage tier that streams byte ranges with a Merkle proof per chunk. Linux, Windows and Android.

✓ lossless · 11 formats · byte-exact ✓ lossy · +3.3 dB vs plain H.264 ✓ restorer gated per file ✓ streaming tier · Merkle-proved ranges ✓ GPU backend · bit-identical ✓ Linux · Windows · Android ◷ time-indexed lossy streaming · next Lossless 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.

Product	Runs on	Version	What it does
liv · CLI	Linux · Windows	0.6.2	pack / unpack / info / play — lossless or lossy per file
liv-gui	Linux · Windows	0.6.2	drag a file in, pick the mode, see the size and the hash
LIV for Android	arm64	0.6.2	the same engine on the phone, GPU restore
liv-vault	Linux · Windows	service	drop-folder: media that lands is packed, verified byte-exact, then the original goes; opening a .liv serves a temp copy
liv-tier	Linux (systemd) · Windows service	0.2.0	storage tier behind a VMS / NVR: watched folder, SHA-256 ledger and dashboard, chunked streaming origin with range reads and Merkle proofs

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