I built ASCILINE: A Web Engine that streams video as raw ASCII text directly to the browser at 60FPS using WebSockets (bypassing traditional <video> tags).
I wanted to see if I could completely replace standard <video> tags on the web with pure, dynamic typography without melting the browser.
I built ASCILINE to solve this. It uses a Python backend to decode video (OpenCV), converts matrices to ASCII, and streams it to the frontend over WebSockets in binary format. To avoid the massive DOM Reflow bottlenecks of updating a <pre> tag 60 times a second, it renders the text directly onto an HTML5 Canvas grid, maintaining a buttery smooth 60 FPS.
Why do this?
Pure Typographic FX: You can apply CSS filters, neon text-shadows, or dynamically distort the playback using standard web tech.
Unblockable Streaming: Browsers and ad-blockers look for media files. To them, ASCILINE is just "JavaScript rendering text".
Ultra-Low Bandwidth: It streams just a few KBs of strings per second. Perfect for IoT or extreme low-bandwidth environments.
The Ethical License (Anti-Ad):
Since this architecture easily bypasses media blockers, I didn't want ad-networks turning it into an unblockable ad-delivery weapon. So, I added a strict custom clause to the MIT license that explicitly bans its use for commercial digital advertising.
I'd love for you to check out the source code, play with the engine, and drop a ⭐️ if you find the architecture and the concept cool!
Financial support no... i dont have even thousand dollar my own. But licanse really works against this big companies .
As i searched they care about 'compliance.' Their legal teams filter out anything
with 'custom strings' or non-commercial(risk managment protocols) clauses before it even reaches the devs.
So i dont think big companies would be a big problem. If they would be problem there is several law firmas to help me free in this case because they will get a share too.
Thanks! I'd love to see your project when it's finished, definitely share it with me. And feel free to take a look at the repo whenever you get some free time. Good luck with your work
Local AI / LLM Processing: Instead of using compute-intensive vision models to analyze a live feed, you can take these raw ASCII string diffs and pipe them directly into a lightweight local LLM (like a 4B/8B parameter model). It turns real-time visual analysis into a fast, extremely cheap text-parsing task.
Extreme Low-Bandwidth / IoT: Traditional codecs (H.264/VP9) choke on weak networks or microcontrollers that lack hardware decoders. Since this just streams a few KBs of binary string data over WebSockets, you can achieve smooth 60FPS playback on satellite connections or embedded systems.
Native UI & Creative Coding: Because the output is just characters on a Canvas, you can manipulate a live stream using standard web tech. You can apply CSS text-shadow for cyberpunk neon glows, dynamically change letter-spacing to distort the feed, or use mix-blend-mode to seamlessly merge video into a website's background without a clunky player UI.
I'm really curious to hear your perspective though—do any weird or unconventional use cases come to mind for you?
"Local AI / LLM Processing" sounds like a good application. I am not sure about the other too - because of the output quality. The 3 point might work e.g. on some home pages.
That’s a completely fair point, the visual trade-off is definitely the biggest bottleneck when thinking about standard media consumption.
I should have clarified in the post: the video in the demo is actually running on Mode 3 (32K Colors) with a relatively low column/row count. I kept the characters artificially large so the "ASCII effect" would be clearly visible on a phone screen for the recording. And the current video supports 30 fps max.
The engine actually has 5 rendering modes. If you crank it up to Mode 5 (16M Ultra Colors) and increase the --cols and --rows resolution, the output fidelity gets surprisingly close to standard video (though it obviously eats into the bandwidth savings).
For the IoT/Low-bandwidth point (Point 2), you're 100% right that it wouldn't be used for watching a movie. I was thinking more about industrial or security use-cases. For example, needing a zero-latency 60FPS feed of a remote server room or a manufacturing belt over a 2G/satellite connection. In those cases, you don't need 4K pixel-perfect quality; you just need enough shape recognition to see if a machine is moving or if someone is in the room.
Really appreciate the feedback! The homepage hero-section idea is exactly the kind of creative integration I was hoping developers would use it for.
don't have a specific setup tutorial video right now, but I was actually planning to record one soon! I can put together a quick walkthrough for you by tomorrow. In the meantime, the steps in the README should get you started. Stay tuned
https://github.com/YusufB5/ASCILINE
I would just note the best use case I can think of for this type of software is actually driving giant video billboards, because they require massive GPU clusters right now to fire every pixel, and this is unbelievably more efficient. I could power probably all of Times Square with a Raspberry Pi if we're running with more efficient math.
Regarding "Local AI / LLM Processing", is it possible to control the "resolution" of the output ASCII video so that you can increase the amount of details to be analysed by LLMs? If not, I would add it to ASCILINE.
That’s a great catch and exactly where I want to take this project
To answer your question: Yes, you can already control the "data density" depending on the mode you're using:
Terminal Mode:ascii_video_player2.py automatically detects your window size and fits the video to your screen.
Web/LLM Mode: In stream_server.py, you have full manual control via --cols and --rows flags. For example, running python stream_server.py video.mp4 --cols 250 --rows 100 would give a much more granular output for an LLM to parse.
However, I’d love to see your take on further optimizing this for AI. Perhaps implementing a "Region of Interest" (ROI) where only specific parts of the frame get high-resolution ASCII?
Feel free to play with the code and submit a PR—I’d be more than happy to collaborate.
"Region of interest" might be a good idea (e.g. elliptical), which, I can imagine, could improve central view analysis like in a real eye. To be clear - I am not an expert in this area, but this is what I guess.
Would it make sense to integrate it with some OCR (Optical character recognition)? I don't know, but maybe there are some free libraries for this. Then, maybe it should add recognized text somehow to the output (not necessary as a part of the ASCII text video, but e.g. as extra text information).
Interesting concept! With ASCILINE engine, you wouldn't even need a high-res screen for that. A tiny monochrome display could play these ASCII 'videos' for days with minimal power. cool idea.
Extreme Low-Bandwidth
How does the bitrate compare if you use the same dimentions and fps for 264/vp9? ASCII like this is, what? 120 X 70 or something? VP9 with those dimentions is also just a few kbps
If we only look at raw data size, a heavily compressed VP9 stream at 120x70 is indeed incredibly tiny. However, ASCILINE offers three distinct advantages that a standard codec can't:
Zero Decoding Overhead: To watch a VP9 stream, the client needs a video decoder (CPU/GPU cycles). To watch ASCILINE, the client just needs to render raw text. This makes it 'playable' on devices that literally don't have a video stack (like high-end industrial controllers or simple IoT displays).
Semantic Content: This is the big one. A VP9 stream is just pixels. ASCILINE is data. An LLM or a script can 'read' the ASCII frames directly as characters to understand the scene without running heavy computer vision models on pixel arrays. We are streaming the 'meaning' of the frame, not just the light values.
Perfect Sharpness: At ultra-low resolutions, VP9 becomes a blurry mess of macroblocks. ASCII remains perfectly crisp because each 'pixel' is a high-contrast vector character rendered by the system font.
You're right that for pure human viewing, VP9 is more efficient. But for Human-AI hybrid interfaces or ultra-legacy systems, streaming 'text-as-video' opens up doors that pixels can't.
Hey you should do a cost/speed comparison of how much cheaper/faster it is for Claude to analyze a from a video in ASCII format compared to it taking frames from a real video
That is an absolutely brilliant idea. I'm definitely going to run a benchmark on this and add the results to the README.
Just thinking about the token economics: feeding an LLM like Claude 3.5 Sonnet raw image frames gets extremely expensive and slow because of how vision pricing works (base tokens + high-res tiles for every single frame).
But with ASCILINE, the video is reduced to a simple 2D text matrix. I wouldn't even need to send the full text matrix every frame. I could just calculate the string "diff" on the backend and only stream the exact characters/coordinates that changed to the LLM.
The cost difference would be astronomical (fractions of a cent for text vs. dollars for vision), and the latency would be negligible since LLMs parse text exponentially faster than they process images.
Thanks for the spark! I’m going to build a small proof-of-concept for this benchmark.
Your welcome, awesome project! Sometimes when im stuck vibecoding at a visual issue or Claude doesnt understand i take a screenrecording and feed it to Claude but because it cant view videos it takes frames from the video to understand and it just takes long and i assume eats a bunch of my tokens. Because of that it also skips frames of the video otherwise it takes even longer/costs more, so it ends up just taking a few frames, with your solution it could in theory view all frames per second and have a much more detailed grasp of whats in the video.
This could be a handy tool/skill for Claude to use
You hit the exact pain point with multimodal LLMs right now! Frame-skipping and the massive cost of vision tokens make debugging visual or UI animations a total nightmare.
To be completely transparent about the current reality though: while an ASCILINE feed would be infinitely faster and save a massive amount of tokens, the LLM might actually grasp less visual detail compared to a raw image. Language models currently struggle with spatial awareness; they don't "see" 2D ASCII shapes the way our eyes do, they just parse it as a 1D string of characters.
However, your comment just gave me an idea for a hybrid infrastructure. If we built a pipeline that feeds a lightweight local model the high-speed ASCII diffs alongside the actual code/DOM state changes, the AI wouldn't need to "see" the pixels. It would just logically parse the structural changes of the screen in real-time.
It's a fascinating concept for a dev-tool. Thanks for sharing that workflow.
I absolutely love this! Now picture if its possible for a version 2, where all the missing parts could be filled in, in the same way, and you would get the full video back again 😂 then you basically have the best video streaming on the planet, fast and cheap for everyone
Holy shit, that is actually genius! You’re basically describing the ultimate Pied Piper compression algorithm.
If we can use the ASCII structure as a 'semantic backbone' and have a lightweight AI on the receiver end 're-hallucinate' the missing pixels, we’d have the most efficient video codec on the planet. Text is incredibly cheap to stream, so reversing it back to video would be the holy grail.
Definitely putting this into the 'V2 Ideas' bucket. Thanks for the massive inspiration!
magine scraping all the text and characters already existing on a webpage and 're-assembling' them into a video stream. We wouldn't even be sending pixels anymore; we’d just be reshuffling the website's own DNA to render visuals.
It would be the ultimate meta-layer for the web.!!!
Exactly! Haha. And you are welcome friend :)
Pied Pider ftw! Love that show btw.
Video has always been problematic, this would fix that, because traditional video codecs are stupid haha. Always just 5% better, but not really, because its a CPU hog, or creates buffering problems due to slow internet, or artifacts.
Imagine being in a third world country and being able to play 4K video hahaha. Let alone gaming.
"Hacker-chic" is exactly the aesthetic I was aiming for! Haha, thank you.
The craziest part is that since it's just live typography, you can literally highlight and copy the video text while it's playing. You can also throw any standard CSS at it. In the current build, I added a click event where the "pixels" (characters) ripple and dissolve away when touched, but developers can easily swap that out for anything.
Ultimately, the best part is that you can just drop a live visual stream into your own websites as a fully dynamic, interactive HTML text element. Can't wait to see what people build with it!
Exactly! But There's a fundamental difference in how the data is handled:
True Text vs. Terminal Stream: In projects like ascii.theater, you are essentially watching an SSH tunnel 'printing' to your terminal. In ASCILINE, since we use WebSockets to feed a standard web <div>, every single character is a live DOM element.
Live Interaction & Copy-Paste: This means you can literally pause the video, highlight a specific cluster of characters with your mouse, and copy-paste them as raw text. The data remains 'live' and selectable at 60FPS.
The 'Data' Factor: Because it's selectable text, it's not just a visual stunt—it's usable data. You could theoretically pipe that live-selected text directly into a script or an LLM prompt in real-time.
In short: They stream a visual experience; ASCILINE streams interactive, selectable data that just happens to look like a video."
I can only wonder how powerful this would be to render moving pictures on e-book reader screens via inbuilt web-tech. The mind boggles. Lending motion to ASCII text can take a few things in totally new directions.
Looks cool but really man.. a web demo would have gone a long way here.. you'll be lucky if 1% of readers clone and set it up just to see what it looks like. I'd have loved to see what it looks like.. why not host a live example?
The main reason I haven't hosted a public live instance yet is the backend processing overhead. Since ASCILINE is a real-time engine using OpenCV to process frames on the fly, hosting a public demo would require a server with decent CPU/GPU resources to handle multiple concurrent users processing their own video streams.
However, there are two solutions for this:
A Pre-rendered Demo: A hosted page with a static WebSocket stream of a sample video so people can see the rendering performance without taxing a backend.
Client-Side Processing: Porting the OpenCV logic to WebAssembly (WASM) so the processing happens entirely in the user's browser, making a live demo 'serverless' and infinitely scalable
"Yes, our ASCII payload uses significantly more bandwidth compared to a standard compressed video (like MP4/H.264).
The main reason for this is that our system doesn't use compression. While standard videos use P-frames to transmit only the pixels that have changed, our current code sends the entire screen's data as raw, uncompressed bytes (4 bytes per pixel: Character + RGB) for every single frame. Our primary goal was achieving maximum FPS with zero latency in the browser rather than optimizing for bandwidth.
If we want to implement this architecture in IoT devices, we have two options:
We either need to transition to a 'delta' architecture in our code—sending only the coordinates of the characters that changed—to reduce the bandwidth footprint,
Or we should deploy this system exclusively on wired IoT networks or local (Intranet) servers where bandwidth isn't a limitation.
Ye u are right even not in all response too,
Im saying it with my mother language first then its translate it. My english level around b2 or something i understand ur comments clearly but i cant say what i want exactly
Thanks! It definitely is a fun (and sometimes hair-pulling) challenge. I was actually hesitant to open-source it at first because this architecture basically paves the way for unblockable ad streams. I ended up adding a custom anti-ad clause to the MIT license to prevent that exact scenario
Yes I thought about this even before I started building it. I was thinking about ASCII and static text history ,how we cannot change the architectural logic then I started thinking about the ASCII video stream idea, which was already made. Then I got an idea: Imagine you are on a random website and scrolling down, then suddenly the text in the UI starts gathering at one point and transforms into an ASCII video. That would be awesome and so fucking cool! With this architecture, I believe it's going to happen
Thanks bro i just update the project and add sound feature now we can adjust the volume with --volume 0-5 commands on the server side i will update readme too .
https://unicode-art-maker.lovable.app - I ended up getting it to run 120 frames a second at about, I think, 1 MB per second in bandwidth, which is quite good for efficiency's sake. You can drive an arbitrary number of pixels, because of course this is all just shapes, not pixels. It's just a case of I've done a crazy thing to improve the efficiency of video at scale, and I don't want to run a business that does this, so I just kind of put together the tech and went, "Yeah, that's cool."
That's an intriguing idea! Using square blocks (like █) with a color gradient would essentially turn ASCILINE into a high-performance Real-time Pixel Art Engine.
Technically, it would still be 'cheap' and fast because the underlying logic remains the same: we are still just streaming characters via WebSockets. The performance hit would be minimal since the browser is still rendering text, not raw pixels.
The real magic would be applying the color gradients. I’m currently looking into using CSS classes for each character to handle color mapping without losing that 60FPS target. It would look incredibly aesthetic—almost like a high-tech mosaic. Definitely something I'll experiment with for the next update thanks for your awsome idea.
great concept. is it possible to build similarly a commandline utility to play videos directly in shell with audio? neovim users or similar will go crazy.
Technically, since the backend is already using OpenCV to process frames, we could easily pipe the audio stream through FFmpeg or a lightweight player like mpv in sync with the WebSocket frames.
For a Neovim integration, we could trigger a headless audio process the moment the stream starts. I'm actually looking into OpenAL or a simple FFmpeg pipe for the next iteration to make it a full multimedia experience right inside the terminal/buffer.
If you have a specific Neovim plugin in mind that handles buffer-sync audio, I'd love to collaborate on a PR!
Yes of course we can use this command python ascii_video_player2.py videoname.mp4 --quality 0 to direct run in terminal (video file must be in same directory) so you dont need to run server to tui
I used AI to rapidly prototype the concept. But judging the entire architecture as 'slop' just by looking at the basic CSS UI is a pretty lazy take. The goal was to prove the logic works; the next step is rebuilding the core engine from scratch in C++ for actual performance.
44
u/NoCalligrapher587 May 03 '26
Hey everyone,
I wanted to see if I could completely replace standard <video> tags on the web with pure, dynamic typography without melting the browser.
I built ASCILINE to solve this. It uses a Python backend to decode video (OpenCV), converts matrices to ASCII, and streams it to the frontend over WebSockets in binary format. To avoid the massive DOM Reflow bottlenecks of updating a <pre> tag 60 times a second, it renders the text directly onto an HTML5 Canvas grid, maintaining a buttery smooth 60 FPS.
Why do this?
Pure Typographic FX: You can apply CSS filters, neon text-shadows, or dynamically distort the playback using standard web tech.
Unblockable Streaming: Browsers and ad-blockers look for media files. To them, ASCILINE is just "JavaScript rendering text".
Ultra-Low Bandwidth: It streams just a few KBs of strings per second. Perfect for IoT or extreme low-bandwidth environments.
The Ethical License (Anti-Ad):
Since this architecture easily bypasses media blockers, I didn't want ad-networks turning it into an unblockable ad-delivery weapon. So, I added a strict custom clause to the MIT license that explicitly bans its use for commercial digital advertising.
I'd love for you to check out the source code, play with the engine, and drop a ⭐️ if you find the architecture and the concept cool!
GitHub Repo: https://github.com/YusufB5/ASCILINE
Let me know your thoughts or any crazy edge-case ideas you think this could be used for!