#What is ASCILINE

ASCILINE turns moving images into programmable characters and color cells. A server decodes a video (or a webcam), maps every frame onto a grid, and streams it over a WebSocket, or you compile it ahead of time into a single .ascf file. The browser draws the result on a Canvas.

The result is not a video file in disguise. It is a grid you can reach into.

#The question behind it

Standard video already exists, is well compressed, and plays everywhere. So the honest question for this project is: what do we gain by refusing the normal pipeline?

Three things, and everything else follows from them:

  • Every cell is yours to touch. A frame is fonts, palettes, cells and selection layers, not an opaque bitmap. You can restyle it with CSS and Canvas filters, select and copy its text, and drive it with time-based effects.
  • No <video> element. The live player draws straight onto a Canvas. There is no browser-side video decoding for the picture, and the picture is not subject to video autoplay rules. (Audio is separate: it uses a normal audio element and follows the browser's audio policy.)
  • It travels to any screen. A text frame is small and needs nothing but Canvas and a WebSocket, so it can reach places where a full video stack is awkward.

#Three ways to represent a frame

Representation What a frame is Typical use
ASCII, monochrome (mode 1) Lines of text Smallest frames, terminals, pure typography
ASCII, color cells (modes 2–6) A character plus an RGB color per cell, 64 up to 16.7M colors The classic colored ASCII look
Pixel (--pixel) One BGR color per cell, drawn through Canvas ImageData, no glyphs Higher fidelity; can be compressed with the lossy DCT codec

Modes 2–6 differ in how finely color is quantized, but every cell still takes four bytes before compression. Pixel mode uses a much larger grid and so sends far more data than ASCII, which is why it has an optional lossy codec and an optional Rust engine, both described in How it works.

#What ASCILINE is not

ASCILINE is not trying to beat H.264, VP9 or AV1 at compression. In the project's own small pilot, realtime VP9 and AV1 reached the same image quality at half the bitrate or less. The point is the representation (characters and cells you can program), not bitrate.

Numbers on this site always say what they were measured on. If a claim has no stated source, grid, quality and machine, treat it as unproven. See Performance for what has and has not been measured.

#Directions, not features

Two ideas that are recorded as directions only. Neither is implemented:

  • Low-bandwidth monitoring: a small, constant text stream that is raised to higher detail only when something happens.
  • Text for downstream models: ASCII frames are already a compact text form, so they might be a lightweight input for text or LLM processing. Nothing in the code does this today.

#Where to go next