The lineage of YouTube-as-infinite-storage projects and memvid
Contents
While browsing MCP servers, I found memvid-mcp-server, which was interesting: it encodes text into video (MP4) and makes it searchable semantically.
That made me remember the old “turn YouTube into infinite storage” projects, so I looked at the lineage behind this idea.
The history of YouTube storage projects
YouTube does not impose a cap on the total number or total size of videos. People exploited that “hole” and asked: what if arbitrary files could be encoded into videos and uploaded, turning YouTube into infinite storage?
YouTubeDrive (2017) - the original
The original, written in Wolfram Language (Mathematica). It converts file bytes into RGB values, generates a video, and automates upload and download through the YouTube API.
The author even called it a “silly proof-of-concept,” yet it still gathered more than 1,900 stars.
Infinite-Storage-Glitch (2023) - the breakout hit
DvorakDwarf/Infinite-Storage-Glitch
A Rust project with more than 7,300 stars. It has two encoding modes:
- RGB mode: 1 pixel = 3 bytes. Efficient, but weak against compression
- Binary mode: 2x2 pixel blocks represent 1 bit. More resilient to YouTube compression
The author honestly notes that it may violate YouTube’s terms of service and does not recommend using it.
qStore (2023) - the QR code answer
The author tried many techniques first, including LSB steganography, RGB embedding, and DCT transforms. But YouTube’s compression was too strong, and the data kept breaking on restore.
The final answer was QR codes. Since QR codes already include error correction, they can survive some compression damage.
memvid - QR codes plus semantic search
memvid inherits qStore’s QR code approach and adds new pieces:
- Embed text chunks as QR codes in video frames
- Generate embeddings with
sentence-transformers - Enable semantic search with FAISS
In other words, it treats video as a vector database.
memvid-mcp-server
This wraps memvid as an MCP server. It exposes two tools:
add_chunks: add text chunks and regenerate the videosearch: run a semantic search and return matching chunks
It uses Streamable HTTP transport and runs on port 3000 by default.
Comparing the approaches
| Project | Encoding | Purpose |
|---|---|---|
| YouTubeDrive | RGB values | File storage |
| Infinite-Storage-Glitch | RGB or binary | File storage |
| qStore | QR codes | File storage, with encryption support |
| memvid | QR codes + vectors | Text storage + search |
YouTubeDrive-style projects are mostly about the hack: “free infinite storage.” memvid is aiming more at a RAG-style use case, where video is just the storage medium for text plus semantic search.
Practical usefulness
Honestly, both sides are a bit questionable in practice:
Problems with YouTube storage projects
- Risk of data corruption due to compression
- Slow upload and download
- Possible violation of YouTube’s terms
Problems with memvid
- A normal vector database such as Pinecone, Qdrant, or ChromaDB is faster and more stable
- Regenerating the whole video on each chunk addition adds overhead
- The dependency stack is heavy (
PyTorch,sentence-transformers, FAISS)
They share the same appeal: technically interesting, but there are easier practical alternatives. Even so, projects like this are valuable for the sheer idea. Using video as a database is unique enough that I might keep it in mind for future experiments, even if it is not the best tool for real work.