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 RU-vid 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)
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.
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.
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.
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.
Amazing work! Another fine example of how hardware limitations push innovation. Paradoxically, limitations open up more opportunities to explore. Great job! 👍
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 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.
@@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.
I wrote a C++ program to play full color video in the console, compatible with both Windows and Linux. Demo here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-tehGAbRB-sw.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.
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.
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!
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
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
@@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 RU-vid'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.
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.
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.
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.
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
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.
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 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.
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.
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.
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. 😁
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.
...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.
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.
5:35 “every single port of this has been made by programmers far more talented then me” you are the most talented programmer on RU-vid you put ray tracing on a graphing calculator and then went hmmm not enough so you put Minecraft on a graphing calculator
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!
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
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 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.
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 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.
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.
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.
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 (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-CcbyjWjxr_M.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.
Back in the day, I used to send floppies to friends with Real player and around a minute of low res video for fun. That was when dialup was the norm and much too slow for video.
Ha, I remember back in the day we didn't have USB drives and CD burners were expensive, so my friend handed me a Diskette with a 10 second clip of AMV Hell on it Except it was an actual video file and I watched it in RealPlayer. Just a heads up, Linux is not the only option for color in the terminal. Windows and DOS have been able to do it since, well, the dawn of the color graphics adapter for the PC! Only 16 colors but that is still a level that Linux supports as well. The Windows console just does it in a much more convenient and speed oriented way. You should really look into the 8088 Corruption/ Domination music video. Get color, full motion, and audio out of it next! Since you are returning to home every frame, why didn't you also go the compression route of only storing the data that changed between frames? This could have saved you a bunch of data as well while retaining a bit more quality!
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...
