Video as text

Every codec is a lie told carefully. Spend fewer bits, fool the eye, call the result a picture. I wanted to tell a different one: what if the frame was never pixels to begin with?

The format is one sentence

A glyphcast frame is a grid of cells. Each cell holds one Unicode glyph and two colors. That is the whole thing. Encoding means asking, for every cell, which glyph-and-color pair happens to look most like that patch of the source. Decoding means drawing them back.

By every metric a codec is judged on, this is worse. It throws away detail no serious format would tolerate. I know. That is not what it is for.

What falls out of it

The frame is text. Not text-like. Text.

A terminal can render it, with no decoder and no GPU, because it already knows how to put glyphs on a screen. A language model can read a frame as tokens and tell you what is in the picture without ever decoding an image. Overlay, crop, diff: grid operations, not pixel math, because cells are discrete and text has always been easy to slice.

None of that was the goal. It is what happens when you pick a representation that is honest about being symbolic instead of pretending to be continuous.

The part that nearly killed it

The obvious way to draw a glyph grid is one draw call per cell. Do that and you get thousands of draw calls a frame and a slideshow. It sat there, dead, for a while.

The fix is the entire engine: pack the whole grid into GPU buffers and render it in a single instanced draw call. One glyph atlas, per-instance attributes for position, glyph index, colors. The GPU eats the frame whole. That is the difference between a party trick and a thing that runs.

Honestly

It is not going to replace h264 and it never applied for the job. It is a format that is simultaneously an image, a document, and a data structure. Once video is text, everything that already operates on text operates on video for free.

That is the trick. The rest is just glyphs.

Core is Apache-2.0. It runs at glyphcast.tv.