When I thought you were transferring monochrome videos, even though I know nothing about tech, I instantly thought of a good type of video to make into 3-bit terminal text video: black-and-white cartoons from the early movie days. Like the 30s Looney Tunes and Popeye cartoons. They were made with less than ideal optics in mind and generally had great contrasts throughout. Also, you would likely find a public domain cartoon and thus just put the entire video on UA-cam with audio. No demonitization nonsense to deal with.
Me too! #FreeBritney (it's still a good tag, we need to continue to look after her now that she is actually free, so they don't somehow hurt her again)
I wrote a C++ program to play full color video in the console, compatible with both Windows and Linux. Demo here: ua-cam.com/video/tehGAbRB-sw/v-deo.html On Linux it is actually much faster, even through SSH in Windows Subsystem for Linux, because the ANSI escape codes work much faster than Windows color change commands. I only change ASCII color for contiguous stripes of the same color. For the video I also use the trick to compare the new ASCII frame with the last, and only draw the pixel (stripes) that have changed between frames by jumping the cursor around.
Windows 3.x had 32 bit extensions for using features of the 386 and 486 processors, long before Windows 95 came around, despite the fact that it all ran on top of the ostensibly 16 bit MS DOS. There have also been several 32 bit versions of 'DOS' created over the years, which are broadly compatible with MS DOS. But that would probably be cheating. 😉
@@another3997 Win32s on Windows For Workgroups 3.11 with all the DOS drivers compatible with enabling both 32 bit disk access and 32 bit file access in Windows. That's how many programs circa 1995 were compatible with both Windows 3.1 and Windows 95. But since Windows 95 could run most Windows 3.1 software, many programs were just straight 16 bit but written to not run into any incompatibilities in Win 95. A problem with software written to work with Win32s is it will often run on 64 bit versions of Windows, but cannot be installed because the installer is 16 bit. Some programs can be extracted from their install files, dumped into a folder and work. Others that doesn't work for. The fix there is either to build a new 32 bit installer or use one of the open source ports of NTVDM to x64 to run 16 bit software in 64 bit Windows.
image to text conversion was something I got really into in IRC days years ago, making fullest use of the IRC color formating was it's own fine art. One suggestion I could make is to take each cell of graphical pixels you're encoding as text, and further analyzing them to determine which ascii character most closely matches the flow of contrast within that cell. So if it's a vertical line, the algo wants to use a vertical pipe to display it, even if the brightness isn't as close, etc. This is something I always wanted to try but never got motivated enough to actually do - maybe you're the one. An impressive display of ascii Britney here, nice job. Lately I've been working on a music visualizer in Unity, some clips on my channel - maybe that would be a fun ascii project, since then there's no need ot store any video at all, just procedurally generate it off the musical input.
I went down the colour route a while back and two things that greatly improved the quality were: - Using the lower half block character (▄) and setting foreground and background colour to double vertical resolution. - Using the rgb ANSI codes for full RGB playback. Not very compressible i'm sure...
Another way to increase "graphical" resolution in text-mode if you don't mind a bit of x86 assembler and not being portable: Use the 160*100 CGA text-mode hack. It sets the card to 80*25 text mode but tells the CGA card to use characters only 2 pixels tall and uses the horizontal half-block character and background/foreground colours to create makeshift pixels, giving a pseudo-graphics mode that can have all 16 CGA colours on screen at once (the actual graphics modes only allow 2 or 4 colours).
- There actually are ANSI escape sequences for full 24-bit RGB colors (the standard 16,777,216 different colors): "[38;2;RRR;GGG;BBBm" for foreground and "[48;2;RRR;GGG;BBBm" for background, with RRR, GGG, and BBB being the decimal color channel values (0-255). On Windows, if using ConHost (the "old" default console host application, as opposite to the new Windows Terminal UWP application), this is only supported as of Windows 10 (from around 2017 and going forward). - I've managed to get a 120x30 console buffer to update, with fully randomized RGB fore- and background colors for each character, around 60-100 times per second. The "framerate" with ConHost is tied to your CPU, with mine being a quadcore i5 from 2014. This was written in C#, however utilized P/Invoke to go around .NET's relatively slow "Console.Write" method, and instead utilize WinAPI's "WriteConsole" function, which dramatically increases performance.
Glad to see there's so many people find this interesting. Never thought of putting video on a floppy disk, I was always trying to see how much audio i could squeeze onto one and still find it acceptable to listen to. I peaked with fitting the whole of Breaking Bad onto a 6 GB USB stick okay its not 4K UHD but its perfectly watchable. Glad to see good old XP there. Thanks.
Could the compression be improved by looking at several frames at once? A "pixel" of a color should more or less stay the same in the next frame. (This would be the temporal equivalent to the spatial predictive coding you used ;D -- maybe it saves even more space)
Thought the same. Many video codecs do that to reduce file size. With only a handful of characters instead of 16 million colors that should be quite compact.
Also, much of the compression trouble comes from the "noise" introduced by dithering. Maybe you could store the raw data in 4 to 5 bit values (16 or 32 colors, roughtly one to 4 levels between the 7 exact values that lead to a solid "color" i.e. one character repeated over and over). That's more data but might compress just as well or even slightly better. Even more so if you only encode the differences to the last frame, and one "index" per frame (or maybe per block of 20x5 characters, since sometimes, there's a lot of static background behind the moving parts of the scene). The index could point to one of eight decoding tables, from #7 for a frame that's virtually unchanged where the "+0" value compresses very well, all the way down to table #0, which compresses only marginally but doesn't include a lot of overhead either if the values are completely different (maybe even make #0 mean "don't decode at all, just overwrite with those raw values." That #0 would come in handy after a hard cut, where there's no relation to the previous frame, or the first frame ever, which can't compare to any previous frame at all. That would impose the burden of dithering on the playback software, but that should be almost as easy as Huffman decoding.
It gets complicated, since you would then need to also keep track of pixel locations across frames, or increase the bit depth enough to be able to include a skip pixel length, which would bloat the overall frame overhead either way. It gets easier if you combine with zip compression. You can represent all pixels that don't change with the same value, and the zip compression will do the work squashing all the redundancies.
The nostalgia is STRONG with memories of me transferring old .avi files via floppy disk. I'm convinced that childhood in the 1990s was peak human experience.
@@StrangelyIronic Yeah it was cool seeing the “beginning” of everything, when simple things were cutting edge, like “wow I just downloaded my first MP3!!” but those slow speeds of both the internet and the computers themselves were just hell on Earth. So many hours wasted. Never again.
I like that you started with the actual content. And then explained how it works. I hate how no one does this, they put the content at the very very end to try to get you to watch longer, and it just makes me not want to watch their video, or in a lot of cases, never watch their channel again.
Amazing work! Another fine example of how hardware limitations push innovation. Paradoxically, limitations open up more opportunities to explore. Great job! 👍
Wasn't expecting a video again this soon, much less something this cool. It's even more of an accomplishment you made it work in Windows, because even Windows users will tell you. It's CLI is hilariously limited Without Powershell and later WSL, it would be worthless. Anyway, kinda funny you didn't think to sync it with a MIDI file as far as audio goes, but hey. Guess there's a thing for a future version 2. Also, I know it should be no surprise. But I was glad to see the code's open source, good on ya
Clever idea with the Markov chain. An easier approach would have been to encode only the difference between two consecutive frames. That way most of the pixels become 0 or very small numbers, unless there is a big scene transition. Good video!
Fun Fact: I actually have a few somewhat short videos that are small enough to fit on a floppy disk stored on my phone. Granted they aren't super long or high quality, but they are good enough to suit one's shitpost viewing pleasure
That's reminds me back in 2005 when we downloaded bunch of movie clip or MV from wap websites, they generally a 320x240 vids with size less than 500KB, they are so pixelated it almost like a Japanese hentai censorship
@@jan_harald Oh yah, there is even a player (BaWaMi) that can send midi output to the speaker and a program for DOS that can do the same with wav files. Let's just say What Is Love has never been that chiptuny.
@@Man-of-Steel674 I'm counting the short! I view them on desktop anyway, as regular videos so they won't auto-loop. Basically, if you load them from your Subscriptions page or the creator's channel -> Videos page, they'll play as a normal video in UA-cam's normal video player. (Not sure about the homepage, since I never visit it; I just jump straight to my subscriptions.)
I remember playing the BB demo over and over around the year 2003 (using a live Knoppix Linux CD) and absolutely loving it. 🙂 I still find AAlib amazing.
Once i experimented with Wolfenstein 3d-like renderer in windows terminal. C# standard write was too slow even when i sacrificed color and wrote all the buffer in one call. Then i tried using p/invoke and was shocked by it's performance, hundreds of writes per second even when i maxed terminal window and used different colours.
Yup, wasn't asking for this but I really enjoyed it, like you'd be the talk of the computer lab if you showed everyone the full Toxic video on those XP machines, totally cool if you ask me.
A long time ago, we just split archive with video into several parts, and several times we went to a neighbor who had Internet access with one floppy disk.
There's something else that could be done and would yield an actual video clip on floppy disk. If we just limit ourself to floppy disk, but not floppy drives, you can actually fit 32MB onto a regular floppy media. What you need is a SuperDisk LS-240 drive, which has the ability to format and store regular floppy to 32MB, instead of the usual 1,44MB. So data is on the floppy media, it's just not compatabile with anything other than LS-240. Now that we have 32MB to play with, we need to store the video as efficiently as possible. VVC (or H.266) is the latest and most efficient codec out there. With toxic being a 3.31min video, we have about ~1200Kbit to play with. I think 1080p@30FPS would yield a pretty decent result.
Since your goal was to distribute as an executable instead of ZIP, maybe you could've made use of an executable packer. UPX comes to mind, and there are probably a multitude of others.
The video was cool, and the idea was very interesting. But I've also tried the same thing, and it's perfectly possible to just compress an mp4 so it fits in a floppy. I've done so with ffmpeg, and I think I was able to keep the audio and color, with a 64p or 128p resolution
The terminal frame rate would improve significantly by going full screen (alt + enter) and allowing the system to use the native text mode of the display.
Years ago I ripped an mp3 file of the Peanuts tune "Linus and Lucy" @56Kbs in stereo to fit on a floppy but sound quality wasn't all that good. Wouldn't have thought video was possible. Very clever if you ask me. BTW,you can reformat a 1.44MB disk to 2.0MB using RLL encoded formatting
5:35 “every single port of this has been made by programmers far more talented then me” you are the most talented programmer on UA-cam you put ray tracing on a graphing calculator and then went hmmm not enough so you put Minecraft on a graphing calculator
I thought about suggesting that you port bad apple, but it indeed was ported everywhere by everyone. Also, I realised that I am already so used to modern tech that I forgot how infinitely small files needed to be back then
You could have further compress file by using wavelet transformation + plus huffman coding at 15fps then run it at 30 fps by interlacing or black frame insertion. With this way there may had been enough room for audio as well in the floppy. Still though amazing stuff.
I bet you could get 30FPS video working using some kind of temporal compression. My ideas is if most or the frame stays the same from the last frame, use some kind of RLE to compress the regions of the frame that stay the same, then use the compression you designed to encode the rest. Incidentally, I think you nearly reinvented LZMA. Come to think of it, LZMA might actually be just what you need, especially because the LZ77 component will efficiently encode any repeated data, such as data seen on a previous frame.
Super cool! I wonder if you could use an edge detection algorithm of sorts to figure out where notable 'lines' are in the video, and use the appropriate character based on weighting of pixels (e.g. * would be top-heavy, , would be bottom heavy and so on) to increase perceived sharpness?
One issue is that you never know how those character look on the target platform. For example, * could be perfectly centered on some low-res platforms like C64 and IBM CGA. Another example: ~ could be centered or top-heavy. I'd suggest characters which are always top- or bottom-heavy, like °, " and _ .
...except that it is patent encumbered making the result slightly less portable. An alternative would be Codec-2: a similar one that is open-source (and thus one could make Linux builds of the same executable). Note that both these codecs are speech codec, geared specifically to compressing human voice. The lyrics might still be intelligible, but the music will probably sound very garbled.
Last year, I was developing a wireless sensor system for a zero export solar inverter (a surprisingly complex task given the latency requirement is a few hundred microseconds or less, otherwise the inverter will not be able to follow the current waveform), I tried playing Toxic through it to see how it handled it. It came out slightly muffled, about the same as a cheap FM radio. Since the bandwidth requirement was quite modest - up to about 2kHz for the current waveform plus subcarriers at about 4kHz and 8kHz - that was good enough.
Clint did compressed a Floppy Disk video to a Floppy Disk so it will play on a disk via media player. I would say that you can Check out LGR Blerbs for his video.
Reminds me of something i did for fun some years ago... On a fedora core 2 linux machine in runlevel 3 (textmode), i had a lynx text mode browser and youtube was working in it - i would use ctrl + O to launch a little script i made (simple bash), it downloaded the video (mp4) and then displayed it as ascii video! (a fun little thing to do for anyone who is bored out there) Oh, and i remember my goto test video was shakira's "wherever, whenever"... Just because it was HQ and popular...
Last year I worked on a pet project inspired by SUPER HOT shaders that transformed images into colored ASCII, but you have certainly gotten further. I'd love to know how exactly you picked those combinations of background and character colors to make great colored images.
Several months ago I actually did something similar using Bad Apple (of course) to display video on the terminal. My version of course was a lot more feature-lacking and barebones, I only used spaces, '*', and '#' to render the different "intensities" of white, and forced it to run at a 80x30 character resolution. I went ahead and cross-compiled it for MIPS el and ran it through the UART port on my wifi router, it ran at like 5 fps but honestly I'm surprised I could get it to run at all on that thing.
Hay, I have Chinese android tab, I only shows compney logo since i changed its build.prop file, I tried but i couldn't find any recovery since tab is old. So what can be done by that tablet? As hardwere works properly, should i install any other os ? ( tab has 1gb ram 8gn internal storage, and it had android 4.1 jellybean)
Love your content, man. This is fantastic. Though you might consider using a logarithmic approach to your color values that's weighted towards the dark colors rather than having your color values spaced evenly. Your eyes are not as good distinguishing bright values from each other.
I think a better possible compression could've been something along these lines (using PNG compression as an inspiration): for each pixel select the closest match between the one above, left or temporally before, temporally before + left/right/up/down; but with some well chosen bias to make direction-difference pairs more similar on average. Store the direction-difference pairs for everything (except the first top left pixel) via Huffman coding You could get even better compression by modelling brightness as just a ring modulo [number of brightness levels] so that you can just wrap around from the highest to lowest with a low number, increasing compression rate for high contrast areas as well
I guess the 30 to 15 fps step doesn't inform any temporal information? That could reduce the filesize even more. Just how the compression works with the likelihood that a specific character is next to another, the same could be done for following frames. No improvement for scene changes, but within a scene that should help getting the size further down.
This was really fun and engaging to watch. Most of the techniques went over my head, but this is my "fault", as I have almost no experience in coding. Great job. :)
I don't know of any floppy drives that would allow for it, but if there were one that could put an arbitrary signal onto a floppy, and read that signal back into the computer, instead of the usual data patterns, how much low-res analog video could you cram onto one? I guess Sony figured it out already with the old analog Mavicas, but I haven't found the info on how many images they crammed onto a disk.
Alright, so I can't even begin to describe how awesome this is. As I type this comment, I am watching the movie Hackers in a MacOS terminal window! You rock.
Also, instead of Huffman, you should've used Range/Arithmetic encoding (or Asymmetric Numeral Tables if you want the fastest decoding with the compression ratio of arithmetic coding) which will more closely approach the Shannon limit of the data being compressed, whereas Huffman only excels where the frequency of symbols is at powers of two. Then you could've increased the rez a little bit!
What about PPMd compression, it works wonders in text and would work amazingly in sequenced frames of text. Also it's extremely lightweight in processing resources.
Kickin' Awesome, Man! I wonder what it'll be like to shove a compressed version of Shrek onto a floppy. I know there was a guy out there who was able to turn the entier movie into a gif.
We're talking about 5400 seconds of video. that means a max of around 30 kbps combined for audio and video. Even with Opus at lowest setttings we have maybe 14 kbps for video left What I have done so far is rendering Shrek at 2.5 mbps 96x56 pixel mpeg-2 video on my mp3 player. Size is around 212 MB at 2.5 mbps And Never Gonna Give You Up at 160x90 in HEVC/Opus with a total bitrate of 55 kbps and a quality that is just adequate to rickroll people from floppy. So I don't think we get Shrek down to floppy like that.
Making full length movie files in to an animated GIF isn't difficult. People have been doing that for 20 years or more. Making it small enough to fit on a 1.44Mb floppy disk? Well, if you drop the resolution to 16 x 9 pixels and settle for 3 frames per second, then do some epic compression, you might fit it on a disk. It won't be watchable, but hey... that's not the point. 😁
I love how he made it look easy, but I'm pretty sure it actually took a lot of effort, knowledge in math, computer science, and low level programming and research.
Check out 8088 Corruption by Trixter/Hornet (ua-cam.com/video/CcbyjWjxr_M/v-deo.html (download link in the description)). Text-mode full-motion video on an XT with CGA and a Sound Blaster. He later followed it up with 8088 Domination, which does the same thing in graphics mode. If you want to run them on a real period machine (as opposed to an emulator), you will need an entire hard drive for just one of them as they're 10 and 30 MB, respectively.
Sounds like a paradox to demonstrate the ability of store video into a 1980s media when no 1980s computer would have the processing power to play it. LoL.
1.44MB was just marketing speak for 1440KB (twice the old 720 DD floppies) - mixing base 2 and base 10 data units. Thats why you'd see something like 1.38MB free.
Yeah, whenever I see people talk about 1.44MB of storage, I think "nah man, you've only got 1.38!" That I remember this YEARS later and can't remember what I did two days ago is kinda wild.
It is still available. Remembered it last week and had to check it out again. That also goes more for a cartoon lineart style instead of translating video into text. If only I'd finally get network working under DOS.
It was pretty hard getting boku no pico first OVA fit into 8 MB (discord free file limit), the actual hardest part for me was audio, while video can go quite potato mode, the audio still takes up quite a lot space.
I on the past, made a program that outputs asterisk representation of letters inputted by the user, well now I saw a video represented in text... Well yeah! ... it might be even be played on some old space probes for aliens, good good.
back in the day i had a mp4 player that used AMV files, it would get a 1 minute video down to about 2-3mb and that was before i learned much about resolution, might have some luck with it
Could throw a MIDI version of Toxic in there and see if that syncs!
Exactly my suggestion!
Or, if your sound card supports it, an MP3.
@@siimplysiibliings3723 the mp3 would have to be very low quality to fit in the remaining space
@@RealEpikCartfrenYT Yeah at 16kbps or less (even in mono), MP3 does *not* make good use of the bits, and it sounds pretty awful.
Bonus points if it uses the PC Speaker!
When I thought you were transferring monochrome videos, even though I know nothing about tech, I instantly thought of a good type of video to make into 3-bit terminal text video: black-and-white cartoons from the early movie days. Like the 30s Looney Tunes and Popeye cartoons.
They were made with less than ideal optics in mind and generally had great contrasts throughout.
Also, you would likely find a public domain cartoon and thus just put the entire video on UA-cam with audio. No demonitization nonsense to deal with.
Oswald the Lucky Rabbit by Walt Disney has been in the public domain for a while, so he could use that
@@abso1utezer010 a Disney film in public domain? What kind of divine intervention is this?
Now there is Steamboat Willie, so a part 2 could be made
I really, really hope that porting Toxic becomes the new DOOM.
Me too! #FreeBritney (it's still a good tag, we need to continue to look after her now that she is actually free, so they don't somehow hurt her again)
Have you heard of something called bad apple?
@@catsame5703 Mhm. They also mentioned it in the video.
@@catsame5703 IDK if we can go much further than Bad Apple played on minecraft sheep. I wonder if we can do, like, Bad Apple on ARGB RAM sticks.
I don't hope, don't give more fame to that horrible song
“Compression?” -Modern Game Developer
I wrote a C++ program to play full color video in the console, compatible with both Windows and Linux. Demo here: ua-cam.com/video/tehGAbRB-sw/v-deo.html
On Linux it is actually much faster, even through SSH in Windows Subsystem for Linux, because the ANSI escape codes work much faster than Windows color change commands.
I only change ASCII color for contiguous stripes of the same color. For the video I also use the trick to compare the new ASCII frame with the last, and only draw the pixel (stripes) that have changed between frames by jumping the cursor around.
Awesome!
That is quite amazing!
in windows 10 (since some specific version), you can actually enable ansi escapes in terminal (and also utf8), which is a fun thing you could do
11:51 The Win32 API was also backported to Windows 3.1 and was available for download, so in theory, it should work on 16-bit (ish) systems.
Why not even in DOS? ☺️
@@intel386DX Put simply, MS DOS is 16-bit, Windows is 32bit. Thus, it needs a partial rewrite to be compatible.
Windows 3.x had 32 bit extensions for using features of the 386 and 486 processors, long before Windows 95 came around, despite the fact that it all ran on top of the ostensibly 16 bit MS DOS. There have also been several 32 bit versions of 'DOS' created over the years, which are broadly compatible with MS DOS. But that would probably be cheating. 😉
@@another3997 Nice! Maybe it could be ported to those extensions.
@@another3997 Win32s on Windows For Workgroups 3.11 with all the DOS drivers compatible with enabling both 32 bit disk access and 32 bit file access in Windows. That's how many programs circa 1995 were compatible with both Windows 3.1 and Windows 95. But since Windows 95 could run most Windows 3.1 software, many programs were just straight 16 bit but written to not run into any incompatibilities in Win 95.
A problem with software written to work with Win32s is it will often run on 64 bit versions of Windows, but cannot be installed because the installer is 16 bit. Some programs can be extracted from their install files, dumped into a folder and work. Others that doesn't work for. The fix there is either to build a new 32 bit installer or use one of the open source ports of NTVDM to x64 to run 16 bit software in 64 bit Windows.
Amazing! Very impressed with your analyses and the results were cool.
image to text conversion was something I got really into in IRC days years ago, making fullest use of the IRC color formating was it's own fine art.
One suggestion I could make is to take each cell of graphical pixels you're encoding as text, and further analyzing them to determine which ascii character most closely matches the flow of contrast within that cell. So if it's a vertical line, the algo wants to use a vertical pipe to display it, even if the brightness isn't as close, etc. This is something I always wanted to try but never got motivated enough to actually do - maybe you're the one.
An impressive display of ascii Britney here, nice job.
Lately I've been working on a music visualizer in Unity, some clips on my channel - maybe that would be a fun ascii project, since then there's no need ot store any video at all, just procedurally generate it off the musical input.
I didn't expect it to be text based... This really exceeded my expectations lol
Bet the next one will be "oops i did it again" 👀
Great video!
I went down the colour route a while back and two things that greatly improved the quality were:
- Using the lower half block character (▄) and setting foreground and background colour to double vertical resolution.
- Using the rgb ANSI codes for full RGB playback.
Not very compressible i'm sure...
Another way to increase "graphical" resolution in text-mode if you don't mind a bit of x86 assembler and not being portable: Use the 160*100 CGA text-mode hack. It sets the card to 80*25 text mode but tells the CGA card to use characters only 2 pixels tall and uses the horizontal half-block character and background/foreground colours to create makeshift pixels, giving a pseudo-graphics mode that can have all 16 CGA colours on screen at once (the actual graphics modes only allow 2 or 4 colours).
That should work under direct DOS, but I doubt that would run that nicely in the windowed command line on a more recent system.
At this point you're compressing a plain old video, just chunked down a bit. It's a lot harder, but still doable.
I mean, if the video's short enough, you could use something like the PL_MPEG decoder. Or roll your own format if you want longer videos.
What about PPMd compression, have you considered it?
- There actually are ANSI escape sequences for full 24-bit RGB colors (the standard 16,777,216 different colors): "[38;2;RRR;GGG;BBBm" for foreground and "[48;2;RRR;GGG;BBBm" for background, with RRR, GGG, and BBB being the decimal color channel values (0-255). On Windows, if using ConHost (the "old" default console host application, as opposite to the new Windows Terminal UWP application), this is only supported as of Windows 10 (from around 2017 and going forward).
- I've managed to get a 120x30 console buffer to update, with fully randomized RGB fore- and background colors for each character, around 60-100 times per second. The "framerate" with ConHost is tied to your CPU, with mine being a quadcore i5 from 2014. This was written in C#, however utilized P/Invoke to go around .NET's relatively slow "Console.Write" method, and instead utilize WinAPI's "WriteConsole" function, which dramatically increases performance.
Glad to see there's so many people find this interesting. Never thought of putting video on a floppy disk, I was always trying to see how much audio i could squeeze onto one and still find it acceptable to listen to. I peaked with fitting the whole of Breaking Bad onto a 6 GB USB stick okay its not 4K UHD but its perfectly watchable. Glad to see good old XP there. Thanks.
Could the compression be improved by looking at several frames at once? A "pixel" of a color should more or less stay the same in the next frame. (This would be the temporal equivalent to the spatial predictive coding you used ;D -- maybe it saves even more space)
Thought the same. Many video codecs do that to reduce file size. With only a handful of characters instead of 16 million colors that should be quite compact.
Also, much of the compression trouble comes from the "noise" introduced by dithering. Maybe you could store the raw data in 4 to 5 bit values (16 or 32 colors, roughtly one to 4 levels between the 7 exact values that lead to a solid "color" i.e. one character repeated over and over). That's more data but might compress just as well or even slightly better. Even more so if you only encode the differences to the last frame, and one "index" per frame (or maybe per block of 20x5 characters, since sometimes, there's a lot of static background behind the moving parts of the scene). The index could point to one of eight decoding tables, from #7 for a frame that's virtually unchanged where the "+0" value compresses very well, all the way down to table #0, which compresses only marginally but doesn't include a lot of overhead either if the values are completely different (maybe even make #0 mean "don't decode at all, just overwrite with those raw values."
That #0 would come in handy after a hard cut, where there's no relation to the previous frame, or the first frame ever, which can't compare to any previous frame at all.
That would impose the burden of dithering on the playback software, but that should be almost as easy as Huffman decoding.
Sounds like mp4 with their i frames and p frames. Good idea!
yes only redrawing what's changed, look at what accomplished there a lot ...... ,,,, xxxxx, in large patches on the screen, ?
It gets complicated, since you would then need to also keep track of pixel locations across frames, or increase the bit depth enough to be able to include a skip pixel length, which would bloat the overall frame overhead either way. It gets easier if you combine with zip compression. You can represent all pixels that don't change with the same value, and the zip compression will do the work squashing all the redundancies.
The nostalgia is STRONG with memories of me transferring old .avi files via floppy disk. I'm convinced that childhood in the 1990s was peak human experience.
I'll pass on going back to dialup ever again.
@@StrangelyIronic Yeah it was cool seeing the “beginning” of everything, when simple things were cutting edge, like “wow I just downloaded my first MP3!!” but those slow speeds of both the internet and the computers themselves were just hell on Earth. So many hours wasted. Never again.
I like that you started with the actual content. And then explained how it works.
I hate how no one does this, they put the content at the very very end to try to get you to watch longer, and it just makes me not want to watch their video, or in a lot of cases, never watch their channel again.
Dude cool project , just as always , glad you're back
I like how this pop-upped on my recommendations the day Britney dropped her autobiography lol.
Amazing work! Another fine example of how hardware limitations push innovation. Paradoxically, limitations open up more opportunities to explore. Great job! 👍
Or limitations create problems that motivates to solve and makes exploration cobined with creativity a necessity.
I thought fitting 3 seasons of Aqua Teen Hunger force on a CD in 2005 was impressive damn that's pretty cool good job!
Wasn't expecting a video again this soon, much less something this cool. It's even more of an accomplishment
you made it work in Windows, because even Windows users will tell you. It's CLI is hilariously limited
Without Powershell and later WSL, it would be worthless. Anyway, kinda funny you didn't think
to sync it with a MIDI file as far as audio goes, but hey. Guess there's a thing for a future version 2.
Also, I know it should be no surprise. But I was glad to see the code's open source, good on ya
I love this sort of stuff... the Demo Scene is full of fun stuff like this
I never knew i needed this until now 😂
Clever idea with the Markov chain. An easier approach would have been to encode only the difference between two consecutive frames. That way most of the pixels become 0 or very small numbers, unless there is a big scene transition. Good video!
When you talked about color limitations, I was expecting you to mention Bad Apple, and I'm very happy that you did :)
Fun Fact: I actually have a few somewhat short videos that are small enough to fit on a floppy disk stored on my phone.
Granted they aren't super long or high quality, but they are good enough to suit one's shitpost viewing pleasure
shitpost delivery service, for a monthly fee, you get sent a box of floppy disks containing nothing but shitposts every month
That's reminds me back in 2005 when we downloaded bunch of movie clip or MV from wap websites, they generally a 320x240 vids with size less than 500KB, they are so pixelated it almost like a Japanese hentai censorship
My old nokia could record 10 second avi clips the resolution was 96p at 10 fps the files where 128kb.
@@belstar1128 cool
@@windowsxpnt2347 You should sign me up...
You’ve very good at explaining complex concepts in simple terms. Great video!
Yes Good Right -!
When the video looks like that, you don't need the audio to be "decent quality", you can crush that too. 🤷
pc-speaker beeps all the way, babyyy! (it can actually beep out surprisingly legible music)
@@jan_harald Oh yah, there is even a player (BaWaMi) that can send midi output to the speaker and a program for DOS that can do the same with wav files.
Let's just say What Is Love has never been that chiptuny.
Fully embrace "The Toxic we have bad home"!
Put it through that one shit mic from a Logitech camera
When there's a new Elf video you know it's going to be a good day
When the world needed him the most he returned. Hurrayyyyy.....
Yes I am aware that this is his 3rd video since the long break he had.
Technically his fourth since he posted a short
@@DistrosProjects calling "shorts" an actual video is bit of stretch for me. 🤣
@@Man-of-Steel674 I'm counting the short! I view them on desktop anyway, as regular videos so they won't auto-loop.
Basically, if you load them from your Subscriptions page or the creator's channel -> Videos page, they'll play as a normal video in UA-cam's normal video player. (Not sure about the homepage, since I never visit it; I just jump straight to my subscriptions.)
glad to see you're still around, thank you so much
I remember playing the BB demo over and over around the year 2003 (using a live Knoppix Linux CD) and absolutely loving it. 🙂 I still find AAlib amazing.
Once i experimented with Wolfenstein 3d-like renderer in windows terminal. C# standard write was too slow even when i sacrificed color and wrote all the buffer in one call. Then i tried using p/invoke and was shocked by it's performance, hundreds of writes per second even when i maxed terminal window and used different colours.
I remember passing around copies of Doom on a 3.5 inch floppy in school and playing it in I.T.
Yup, wasn't asking for this but I really enjoyed it, like you'd be the talk of the computer lab if you showed everyone the full Toxic video on those XP machines, totally cool if you ask me.
A long time ago, we just split archive with video into several parts, and several times we went to a neighbor who had Internet access with one floppy disk.
There's something else that could be done and would yield an actual video clip on floppy disk. If we just limit ourself to floppy disk, but not floppy drives, you can actually fit 32MB onto a regular floppy media. What you need is a SuperDisk LS-240 drive, which has the ability to format and store regular floppy to 32MB, instead of the usual 1,44MB. So data is on the floppy media, it's just not compatabile with anything other than LS-240.
Now that we have 32MB to play with, we need to store the video as efficiently as possible. VVC (or H.266) is the latest and most efficient codec out there. With toxic being a 3.31min video, we have about ~1200Kbit to play with. I think 1080p@30FPS would yield a pretty decent result.
Since your goal was to distribute as an executable instead of ZIP, maybe you could've made use of an executable packer. UPX comes to mind, and there are probably a multitude of others.
The video was cool, and the idea was very interesting. But I've also tried the same thing, and it's perfectly possible to just compress an mp4 so it fits in a floppy. I've done so with ffmpeg, and I think I was able to keep the audio and color, with a 64p or 128p resolution
Ah yes, Bit-ney Spears...
kek
Ayyy, glad to see you're back :)
The terminal frame rate would improve significantly by going full screen (alt + enter) and allowing the system to use the native text mode of the display.
Yoo I swear you have the most underrated channel. It's so entertaining to watch even to me as I don't know anything about programming lol
This kind of tecnology was used many times for game boy games
Years ago I ripped an mp3 file of the Peanuts tune "Linus and Lucy" @56Kbs in stereo to fit on a floppy but sound quality wasn't all that good. Wouldn't have thought video was possible. Very clever if you ask me. BTW,you can reformat a 1.44MB disk to 2.0MB using RLL encoded formatting
now i want to watch youtube in ascii
5:35 “every single port of this has been made by programmers far more talented then me” you are the most talented programmer on UA-cam you put ray tracing on a graphing calculator and then went hmmm not enough so you put Minecraft on a graphing calculator
I thought about suggesting that you port bad apple, but it indeed was ported everywhere by everyone. Also, I realised that I am already so used to modern tech that I forgot how infinitely small files needed to be back then
Imagine instead of storing the file, use it to broadcast!
You could have further compress file by using wavelet transformation + plus huffman coding at 15fps then run it at 30 fps by interlacing or black frame insertion. With this way there may had been enough room for audio as well in the floppy. Still though amazing stuff.
Oh god, now all I can imagine is this playing as a keygen song with the asciitext video and I'm OBSESSED.
I’d love to see a pc speaker single voice square wave version of Toxic playing along with it.
[Coder's evil grin:] With or without PWM?
I bet you could get 30FPS video working using some kind of temporal compression.
My ideas is if most or the frame stays the same from the last frame, use some kind of RLE to compress the regions of the frame that stay the same, then use the compression you designed to encode the rest.
Incidentally, I think you nearly reinvented LZMA. Come to think of it, LZMA might actually be just what you need, especially because the LZ77 component will efficiently encode any repeated data, such as data seen on a previous frame.
Its great seeing you upload regularly :)
Super cool! I wonder if you could use an edge detection algorithm of sorts to figure out where notable 'lines' are in the video, and use the appropriate character based on weighting of pixels (e.g. * would be top-heavy, , would be bottom heavy and so on) to increase perceived sharpness?
One issue is that you never know how those character look on the target platform. For example, * could be perfectly centered on some low-res platforms like C64 and IBM CGA. Another example: ~ could be centered or top-heavy. I'd suggest characters which are always top- or bottom-heavy, like °, " and _ .
The fact that you’ve chosen Toxic gets you an instant like from 00:00 from me
This is amazing! I'd legit love to see all my favourite video clips like this 😅
I'd recommend looking at AMR encoding for tiny audio. It sounds awful, but has surprisingly widespread support.
...except that it is patent encumbered making the result slightly less portable. An alternative would be Codec-2: a similar one that is open-source (and thus one could make Linux builds of the same executable).
Note that both these codecs are speech codec, geared specifically to compressing human voice. The lyrics might still be intelligible, but the music will probably sound very garbled.
The Toxic music video will turn into the video form of Doom and people will try to play it on everything imaginable
Bad Apple round 2 kickoff!
Last year, I was developing a wireless sensor system for a zero export solar inverter (a surprisingly complex task given the latency requirement is a few hundred microseconds or less, otherwise the inverter will not be able to follow the current waveform), I tried playing Toxic through it to see how it handled it. It came out slightly muffled, about the same as a cheap FM radio. Since the bandwidth requirement was quite modest - up to about 2kHz for the current waveform plus subcarriers at about 4kHz and 8kHz - that was good enough.
Oh, hey! An HP TC1100! I still use mine for drawing.
Ive literally put a 3 minute 3gp on a Floppy disk without a problem. IT had like 900kb
I love it when "science" answers to questions that no one asks when there are so many relevant unanswered questions.
"let's choose this video because it has a lot of contrast"
"Wait now this Huffman algorithm won't work because too much contrast"
The duality of man
Clint did compressed a Floppy Disk video to a Floppy Disk so it will play on a disk via media player. I would say that you can Check out LGR Blerbs for his video.
Reminds me of something i did for fun some years ago... On a fedora core 2 linux machine in runlevel 3 (textmode), i had a lynx text mode browser and youtube was working in it - i would use ctrl + O to launch a little script i made (simple bash), it downloaded the video (mp4) and then displayed it as ascii video! (a fun little thing to do for anyone who is bored out there) Oh, and i remember my goto test video was shakira's "wherever, whenever"... Just because it was HQ and popular...
Last year I worked on a pet project inspired by SUPER HOT shaders that transformed images into colored ASCII, but you have certainly gotten further. I'd love to know how exactly you picked those combinations of background and character colors to make great colored images.
Several months ago I actually did something similar using Bad Apple (of course) to display video on the terminal. My version of course was a lot more feature-lacking and barebones, I only used spaces, '*', and '#' to render the different "intensities" of white, and forced it to run at a 80x30 character resolution. I went ahead and cross-compiled it for MIPS el and ran it through the UART port on my wifi router, it ran at like 5 fps but honestly I'm surprised I could get it to run at all on that thing.
Video via text has been around since at least the 80s. We used to swap a few seconds of... mature... content on 360K disks that way. :)
I was asking for this, thankyou!
Port it to the TI-84
Can you download the video you made in ascii so I can put it on my floppy disk please
Hay,
I have Chinese android tab,
I only shows compney logo since i changed its build.prop file, I tried but i couldn't find any recovery since tab is old. So what can be done by that tablet? As hardwere works properly, should i install any other os ? ( tab has 1gb ram 8gn internal storage, and it had android 4.1 jellybean)
1. Hay is for horses.
2. Good ruck not bleaking your tabret in flustlation.
3. I don't know.
5:14 I’ve seen Rickroll so many times that I swear I could see the colors of his hair and skin….that is such a weird illusion
Nice to see people other than me doing this stuff
Really cool stuff man!
Love your content, man. This is fantastic. Though you might consider using a logarithmic approach to your color values that's weighted towards the dark colors rather than having your color values spaced evenly. Your eyes are not as good distinguishing bright values from each other.
I think a better possible compression could've been something along these lines (using PNG compression as an inspiration):
for each pixel select the closest match between the one above, left or temporally before, temporally before + left/right/up/down; but with some well chosen bias to make direction-difference pairs more similar on average. Store the direction-difference pairs for everything (except the first top left pixel) via Huffman coding
You could get even better compression by modelling brightness as just a ring modulo [number of brightness levels] so that you can just wrap around from the highest to lowest with a low number, increasing compression rate for high contrast areas as well
I guess the 30 to 15 fps step doesn't inform any temporal information? That could reduce the filesize even more. Just how the compression works with the likelihood that a specific character is next to another, the same could be done for following frames. No improvement for scene changes, but within a scene that should help getting the size further down.
Thank you for subtitling this!
This was really fun and engaging to watch. Most of the techniques went over my head, but this is my "fault", as I have almost no experience in coding. Great job. :)
Pixel perfect dithering looks terrible when it moves.smoothly
You should make a video about the Sloot Digital Coding System.
I don't know of any floppy drives that would allow for it, but if there were one that could put an arbitrary signal onto a floppy, and read that signal back into the computer, instead of the usual data patterns, how much low-res analog video could you cram onto one? I guess Sony figured it out already with the old analog Mavicas, but I haven't found the info on how many images they crammed onto a disk.
There was a consumer camera called the mavica that used floppy disk. Later models allowed you to record short low res videos
Alright, so I can't even begin to describe how awesome this is. As I type this comment, I am watching the movie Hackers in a MacOS terminal window! You rock.
' "But" I pretend to hear you ask.'
Big fan of that lol
Also, instead of Huffman, you should've used Range/Arithmetic encoding (or Asymmetric Numeral Tables if you want the fastest decoding with the compression ratio of arithmetic coding) which will more closely approach the Shannon limit of the data being compressed, whereas Huffman only excels where the frequency of symbols is at powers of two. Then you could've increased the rez a little bit!
What about PPMd compression, it works wonders in text and would work amazingly in sequenced frames of text. Also it's extremely lightweight in processing resources.
Kickin' Awesome, Man! I wonder what it'll be like to shove a compressed version of Shrek onto a floppy. I know there was a guy out there who was able to turn the entier movie into a gif.
Eh, maybe a floptical or something. Shrek would likely just be too long to compress well enough.
We're talking about 5400 seconds of video. that means a max of around 30 kbps combined for audio and video.
Even with Opus at lowest setttings we have maybe 14 kbps for video left
What I have done so far is rendering Shrek at 2.5 mbps 96x56 pixel mpeg-2 video on my mp3 player. Size is around 212 MB at 2.5 mbps
And Never Gonna Give You Up at 160x90 in HEVC/Opus with a total bitrate of 55 kbps and a quality that is just adequate to rickroll people from floppy.
So I don't think we get Shrek down to floppy like that.
Making full length movie files in to an animated GIF isn't difficult. People have been doing that for 20 years or more. Making it small enough to fit on a 1.44Mb floppy disk? Well, if you drop the resolution to 16 x 9 pixels and settle for 3 frames per second, then do some epic compression, you might fit it on a disk. It won't be watchable, but hey... that's not the point. 😁
Your short had sound. Was that movie magic?
I love how he made it look easy, but I'm pretty sure it actually took a lot of effort, knowledge in math, computer science, and low level programming and research.
I love representing formats like pictures or video in weird ways like through sound or text or whatever else.
Check out 8088 Corruption by Trixter/Hornet (ua-cam.com/video/CcbyjWjxr_M/v-deo.html (download link in the description)). Text-mode full-motion video on an XT with CGA and a Sound Blaster. He later followed it up with 8088 Domination, which does the same thing in graphics mode. If you want to run them on a real period machine (as opposed to an emulator), you will need an entire hard drive for just one of them as they're 10 and 30 MB, respectively.
Sounds like a paradox to demonstrate the ability of store video into a 1980s media when no 1980s computer would have the processing power to play it. LoL.
I've watched that BB Demo so many times. Always thought it was so cool
1.44MB was just marketing speak for 1440KB (twice the old 720 DD floppies) - mixing base 2 and base 10 data units. Thats why you'd see something like 1.38MB free.
Yeah, whenever I see people talk about 1.44MB of storage, I think "nah man, you've only got 1.38!"
That I remember this YEARS later and can't remember what I did two days ago is kinda wild.
I remember the ASCII star wars movie, but that was streamed though telnet so it focused on smaller bandwith rather than capacity, similar idea though
It is still available. Remembered it last week and had to check it out again.
That also goes more for a cartoon lineart style instead of translating video into text.
If only I'd finally get network working under DOS.
I would like to see this.
It was pretty hard getting boku no pico first OVA fit into 8 MB (discord free file limit), the actual hardest part for me was audio, while video can go quite potato mode, the audio still takes up quite a lot space.
I on the past, made a program that outputs asterisk representation of letters inputted by the user, well now I saw a video represented in text... Well yeah! ... it might be even be played on some old space probes for aliens, good good.
back in the day i had a mp4 player that used AMV files, it would get a 1 minute video down to about 2-3mb and that was before i learned much about resolution, might have some luck with it
i think some science elves have moved into my shed. send help please.