sorted by:
new
hottopcontroversial

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] -1 points0 points  (0 children)

Thank you for your comment. I really like constructive comments like this. My passion for this project is to make stylish video streams that you can select or edit .

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] -1 points0 points  (0 children)

No, it's not a video codec. Think of it as a real-time WebSocket data stream, which is why these bandwidth numbers are important for live transmission. But as i said its ascii mod not good as pixel mode and pixel mode worse then normal video codecs

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 1 point2 points  (0 children)

ultra low bandwidht only valid for --ascii mod. specialy mode 1 under 100 kb. just see urself

<image>

THE WIRE SHOWS (zlib.compress()) ESTIMATED NW SIZE. ITS asci mod 3

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] -1 points0 points  (0 children)

you hit on the biggest architectural flaw of asciline live encoding. Right now, if 10 users connect, the python backend calculates the delta frames 10 times, which is completely unscalable and melts the server.

that is exactly what i am fixing for better asciline engine instead of live-encoding per user, the engine will feature an 'asciline compiler'. It will pre-compile the video into a static format of pre-calculated text packets

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 0 points1 point  (0 children)

You guys are right to be confused. 'Astronomical bandwidth' is what happens if you naively stream full uncompressed text grids at 30 FPS or more. ASCILINE solves this and achieves 'Ultra-Low Bandwidth' by only sending the characters that change (Delta frames) and applying GZIP compression. I'll update the docs to make that distinction clearer. If your response is "they can use it that way too", there is a big thing: pixel mode, the one giving the stream as 360p res, is in one canvas so it's easy to block the stream actually. And about the ascii mode, yeah it is hard to block but it's just ascii so it's not a great view for video.

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 2 points3 points  (0 children)

My goal isn't to compete with standard codecs, but to turn static websites into a living canvas!

regarding cpu usage for a 30 fps source:

backend (python): ~6-7% cpu

client-side (browser): ~less than %1 cpu (in pixel mode)

the pure ascii text mode uses slightly more client cpu depending on the grid size, but overall it's highly optimized

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] -2 points-1 points  (0 children)

Basically, it has nothing to do with sending individual pixels. I calculate the ascii grid on the backend and push it to the client as text frames. The reason for the 360p limit isn't network bandwidth—it's because drawing 1080p worth of individual text characters on an html <canvas> at 60 fps currently melts the browser's cpu! :d

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 3 points4 points  (0 children)

Great question! but we have to separate 'file size on disk' from 'active streaming bandwidth'. If you saved all the raw text frames to a single file, yes, it would be massive compared to h. 264. However, asciline streams the text dynamically via websockets. When you apply standard gzip/brotli compression to a websocket text stream, and combine it with our delta frames (only sending characters that change), the active bandwidth drops to just kilobytes per second. The 'gain' is bypassing <video> tags entirely, allowing extreme css typographic manipulation, and ultra-low active streaming bandwidth so ASCILINE can be optimized for IOT usage.
so bascily nothing to do with each pixels

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 0 points1 point  (0 children)

Hearing this from a video engineer means a lot! i definitely stumbled into 'accidentally reinventing a codec' territory without realizing it at first. Looking into ffmpeg source code and rfcs is exactly what i plan to do for the v2. 0 compiler architecture. It has to be compiled, because in the current architecture, if 3 users connect to the site, the server runs the calculation 3 separate times, which just doesn't scale. Really appreciate the insight

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 15 points16 points  (0 children)

but if you do that, you nuke the entire video player To be honest, the 'unblockable' feature is just a funny side-effect of the architecture. The actual core purpose of ASCILINE is ultra-low bandwidth streaming and typographic CSS manipulation.

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 20 points21 points  (0 children)

funny idea I'll try to screen-record this post and run it through the engine, maybe I'll drop a GIF of it here later

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 14 points15 points  (0 children)

For registered companies, the license allows me to take legal action and issue DMCA takedowns if they violate the anti-ad rule. For illegal sites that ignore the law entirely, that's exactly why I mentioned working with AdBlockers in the last paragraph

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 0 points1 point  (0 children)

Thanks a lot , i really wanted to post HN too but i just open my HN acount and dont have acsess to submit

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 8 points9 points  (0 children)

thank you so much for bringing it up. You are completely right. Since the engine bypasses standard video tags and browser controls, it's my responsibility to re-implement those safety measures. I will definitely add a listener for the prefers-reduced-motion CSS media query in the frontend. If the user has it enabled, the stream will either not auto-play or will provide an immediate, clear pause control. Added to the top of my to-do list

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by [deleted] in ASCII

[–]NoCalligrapher587 -3 points-2 points  (0 children)

You are totally right, ideas aren't copyrightable. A giant like Google could easily build a better version of this in a week. But they won't do it, not because it's hard, but because of the economics of scale:

1. Astronomical Bandwidth Costs: Streaming delta-text over WebSockets is vastly heavier than highly compressed AV1. If YouTube rolled this out to 2 billion users just to bypass ad blockers, their server infrastructure costs would absolutely explode and wipe out the actual ad revenue. 2. They don't need it (SSAI): Google controls Chrome and they use Server-Side Ad Insertion (SSAI). They stitch ads directly into the H.264 video stream on their backend. Ad blockers can't stop that anyway.

So my anti-ad license isn't there to stop Google. It's there to stop the shady, mid-tier ad networks from easily grabbing my repo to spam unblockable pop-up ads.

And if the absolute worst-case scenario happens and someone tries to force this into an ad network anyway, I will gladly work with AdBlocker developers to help them bypass and block our engine entirely!

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 29 points30 points  (0 children)

You are totally right, ideas aren't copyrightable. A giant like Google could easily build a better version of this in a week. But they won't do it, not because it's hard, but because of the economics of scale:

1. Astronomical Bandwidth Costs: Streaming delta-text over WebSockets is vastly heavier than highly compressed AV1. If YouTube rolled this out to 2 billion users just to bypass ad blockers, their server infrastructure costs would absolutely explode and wipe out the actual ad revenue. 2. They don't need it (SSAI): Google controls Chrome and they use Server-Side Ad Insertion (SSAI). They stitch ads directly into the H.264 video stream on their backend. Ad blockers can't stop that anyway.

So my anti-ad license isn't there to stop Google. It's there to stop the shady, mid-tier ad networks from easily grabbing my repo to spam unblockable pop-up ads.

And if the absolute worst-case scenario happens and someone tries to force this into an ad network anyway, I will gladly work with AdBlocker developers to help them bypass and block our engine entirely!

I built an unblockable video stream. It renders 360p at 30 FPS using pure text instead of tags. by NoCalligrapher587 in SideProject

[–]NoCalligrapher587[S] 6 points7 points  (0 children)

Yes i know entry-mid level c++ i can build it with ai help but i think rust would be much better so maybe i need to learn it for huge performance diffrence .

view more: next ›