Why doesn't the data get corrupted if YouTube re-encodes the video?

Because every data block carries BCH(t=16, m=15) error correction: it can rebuild up to 16 errors per 2048-byte block. VP9 re-encoding introduces errors below that threshold, so BCH corrects all of them and recovery is bit-exact, verified by SHA256.

How much can it store?

It is tested with SHA256-verified recovery at ~140 MB per bundle, at both 30 and 60 fps. There is no hard limit: larger files are split into more 10 MB chunks.

Is this unlimited free storage?

In practice it is a research experiment, not a backup service. It shows that a lossy transcoding pipeline can be used as a reliable data channel if you add the right layer of error correction.

Agatha: how I turned YouTube into a hard drive with error correction

Q: What is Agatha?

A data transport system that encodes binary files as 4K grayscale video frames (1 bit per pixel), uploads them to YouTube and recovers them with 100% fidelity using BCH error correction, despite the platform's VP9 re-encoding.

A YouTube video is, underneath, a string of numbers: the brightness values of every pixel of every frame. If I can write those numbers and then read them back, YouTube stops being a video platform and becomes a storage medium. The problem is that YouTube does not give you back the numbers you uploaded: it re-encodes them with VP9 and hands you similar ones. Agatha solves exactly that problem.

Timeline. The project was created on 21 March 2026 and validated a few days later, with a ~140 MB recovery verified by SHA256 (release v1.1.0, 23 March 2026). The academic paper was written on 26 March 2026.

Try it yourself. Upload a file and leave your email: Agatha stores it as video on YouTube and sends you a real URL that rebuilds it bit for bit. → Try Agatha

Agatha in 29 seconds: from the dog to the bitmap, and from YouTube back to the file. Muted by default: turn the audio on in the controls.Watch it in the reel viewer →

What does Agatha do?

Agatha turns any binary file into 4K grayscale video frames (1 bit per pixel), uploads them to YouTube and recovers the original file with 100% fidelity. The key is a BCH(t=16, m=15) error-correction layer that rebuilds the bits VP9 re-encoding degrades. Recovery is bit-exact and verified by SHA256.

Why is it called Agatha?

Because of a dachshund. The project did not come out of a theory but out of a happy accident: the first attempts used QR-like patterns and died the moment YouTube re-encoded them. The turn came from converting a photo of Agatha, a dachshund, into a 1-bit bitmap (black and white) and embedding it in a frame. That image survived the compression where random binary noise did not. From there came the decoder that still defines the system: a pixel below 128 decodes to bit 1, above it to bit 0. The system is named after that dog.

Agatha's photo reduced to 1 bit per pixel

How does it work, step by step?

The pipeline has seven stages. Each one exists to survive something YouTube does to your video.

Packing. The input files are gathered into a canonical TAR and split into 10 MB chunks.
Error correction. Every chunk is encoded with BCH(t=16), in 2048-byte blocks with 30 bytes of overhead each. This is what later makes it possible to repair VP9’s damage.
Bitmap. The protected bits are packed into a 3840×2160 grayscale map: one bit per pixel, black or white.
Video. The bitmaps are first encoded to lossless FFV1 and then re-encoded to H.264 CRF 18 for the upload.
Bundle. The videos for each chunk are concatenated with 1-second white separator frames. Audio is stripped to avoid timestamp corruption from AAC edit lists.
Transcoding. YouTube receives the video and transcodes it to VP9 2160p. This is where the noise comes in.
Recovery. The frames are extracted, thresholded at 128 (above is 1, below is 0) and BCH-decoded. BCH corrects every error VP9 introduced and the file comes back identical, verified by SHA256.

One nice detail: the white frames between chunks cost almost no bits under VP9, so they leave the codec’s whole budget for the data frames, which gives a 30- to 60-fold amplification in the white-to-data ratio.

The numbers

Every 4K frame holds 3840 × 2160 = 8,294,400 bits ≈ 0.99 MB per frame. At 30 fps that is about 29 MB of data per second of video, before BCH overhead (~1.5%). That is why a ~140 MB bundle fits into a few minutes of video, and uploading more only means more 10 MB chunks.

The data frames

This is a real frame uploaded to YouTube: every pixel is a bit, white is 1, black is 0. In the video it lasts a fraction of a second, so to the naked eye it is just “noise”. Here it is frozen, plus a 1:1 close-up to see the bits one by one.

Requirements

Python 3.11+
ffmpeg and ffprobe (encoding and frame extraction)
yt-dlp (upload and download from YouTube)
A YouTube account with OAuth for automated uploading

Installing the monorepo (hexagonal core + CLI):

python3 -m venv .venv && source .venv/bin/activate
pip install -e packages/core -e apps/cli
agatha db init --db-url sqlite:///data/agatha.db

A worked example

The full flow, from file to YouTube and back:

# 1. Encode and bundle
agatha pipeline encode --name demo --input-file file.tar.gz --workspace /tmp/ws
agatha pipeline bundle --run-id <id>

# 2. Upload, wait for 2160p and download
agatha youtube upload    --run-id <id> --client-secrets client.json --privacy unlisted
agatha youtube wait-2160 --run-id <id>
agatha youtube download  --run-id <id> --format-id 313   # 313 = 30 fps, 315 = 60 fps

# 3. Recover and verify
agatha pipeline recover --run-id <id> --bundle-video video.webm

Real output from a verification run, with the file already through YouTube’s re-encoding:

{
  "full_recovery": true,
  "byte_match_percent": 100.0,
  "raw_bit_errors": 0
}

And the verdict that matters: the hash of the original and of the recovered file are identical.

original : babff974461e81fcd01fa98a42f293a57ce3fe396f5358b5cc4fd4c8fe366ee6
recovered: babff974461e81fcd01fa98a42f293a57ce3fe396f5358b5cc4fd4c8fe366ee6

Tested at ~140 MB with SHA256-verified recovery, at both 30 and 60 fps.

And this is Agatha storing itself: the project’s own source code (264 KB as a .tar.gz), uploaded as 4K video to YouTube and recovered bit-exact.

Agatha’s code stored as frames on YouTube, recovered with an identical SHA256. What you see as noise is the project’s own bits.

Verification videos (uploaded and recovered live, identical SHA256):

Data demo → youtu.be/JooSWN_wR14
Agatha storing itself → youtu.be/eZ3fz1U-1xo

Two families of operation

Morton Full: fast 4K VP9 channel. Maximum throughput (140 MB tested), but the data frames are visibly binary.
Color Carrier: modulates the luminance of natural images. Lower throughput (~13.6 MB tested) but visually indistinguishable from a legitimate video; in stealth mode, 1 data frame for every 30 of real video, with a zero error rate after BCH.

The two modes, and what it costs to look like a normal videomegabytes verified by SHA256 · higher is better

Morton Full, 4K VP9~140 MBMaximum throughput, but the data frames look like exactly what they are: binary noise.
Color Carrier, stealth~13.6 MBModulates the luminance of natural images. Ten times less capacity in exchange for being indistinguishable from a legitimate video.

Both with bit-exact recovery after the platform's VP9 re-encoding, thanks to BCH(t=16, m=15).

What is it actually good for?

Agatha is a research experiment, not a backup service. The interesting part is not “free storage” but the demonstration that a lossy channel can be made reliable if you put the right error-correction layer on it. The same idea holds for any noisy medium: radio, degraded optical storage, or any pipeline that transforms your data without asking permission.