Printvideo.com(justine.lol)
justine.lol
Printvideo.com
https://justine.lol/printvideo.html
37 comments
Try installing sox and ffmpeg if you have not already.
it's also possible to use ffmpeg with aalib to turn any video into moving ASCII. I have a copy of The Matrix somewhere that's entirely ascii text at 30 fps.
https://en.wikipedia.org/wiki/AAlib
https://www.google.com/search?channel=fs&client=ubuntu&q=ffm...
https://en.wikipedia.org/wiki/AAlib
https://www.google.com/search?channel=fs&client=ubuntu&q=ffm...
Does it work well with hardcoded subs?
You can also set mpv video output to caca, so you can watch things in ascii: https://unix.stackexchange.com/questions/160243/waching-yout...
> PRINTVIDEO.COM should also go fast enough to render 4K video on an old ThinkPad without needing APIs or GPUs, since experience has led me to believe...
Come on, Justine. It's fast enough to render that because you're using MPEG-1 (Older codecs take less CPU per unit of video, at the price of worse compression ratios) and because you're rendering to a postage stamp of a target. You can probably just skip most of the DCT and do the rendering off of 8x8 blocks. (IIRC MPEG-1 is very similar to JPEG, but moving)
> One of the properties of GNU/Linux code is it tends to approach read-only on a long enough timeline, in the absence of continual maintenance. That partly explains why we can't compile old GCC, or what may have frightened off John Carmack when he tried to share Quake with the Linux community.
I always appreciate a random potshot at the free software movement and one of the most popular kernels for dev-facing CPUs.
> In fact, it actually takes less CPU to decode + convolve + render high definition video than it does for OpenSSH and Zlib to copy the finished text to ethernet, possibly due to
to the fact that MPEG-1 is, again, a codec made for such 30-year-old CPUs.
Come on, Justine. It's fast enough to render that because you're using MPEG-1 (Older codecs take less CPU per unit of video, at the price of worse compression ratios) and because you're rendering to a postage stamp of a target. You can probably just skip most of the DCT and do the rendering off of 8x8 blocks. (IIRC MPEG-1 is very similar to JPEG, but moving)
> One of the properties of GNU/Linux code is it tends to approach read-only on a long enough timeline, in the absence of continual maintenance. That partly explains why we can't compile old GCC, or what may have frightened off John Carmack when he tried to share Quake with the Linux community.
I always appreciate a random potshot at the free software movement and one of the most popular kernels for dev-facing CPUs.
> In fact, it actually takes less CPU to decode + convolve + render high definition video than it does for OpenSSH and Zlib to copy the finished text to ethernet, possibly due to
to the fact that MPEG-1 is, again, a codec made for such 30-year-old CPUs.
> …MPEG-1 is, again, a codec made for such 30-year-old CPUs.
I'm picking a nit here, but for anyone interested in the history: MPEG-1 software decoders could not do realtime, full-framerate decoding on the most powerful workstations available in 1991.[1] (This is one reason Cinepak[2] was so monumentally important.)
I believe realtime, full-framerate MPEG-1 software decoding became possible on high-end PCs around 1995. Apple introduced their software decoder in 1997[3], after having introduced their hardware decoder in 1995.
[1] http://www.cs.unc.edu/~kmp/publications/mm93/MM93-paper.pdf [2] https://en.wikipedia.org/wiki/Cinepak [3] https://web.archive.org/web/19981202202315/http://product.in...
I'm picking a nit here, but for anyone interested in the history: MPEG-1 software decoders could not do realtime, full-framerate decoding on the most powerful workstations available in 1991.[1] (This is one reason Cinepak[2] was so monumentally important.)
I believe realtime, full-framerate MPEG-1 software decoding became possible on high-end PCs around 1995. Apple introduced their software decoder in 1997[3], after having introduced their hardware decoder in 1995.
[1] http://www.cs.unc.edu/~kmp/publications/mm93/MM93-paper.pdf [2] https://en.wikipedia.org/wiki/Cinepak [3] https://web.archive.org/web/19981202202315/http://product.in...
Author here. This a toy program demo. MPEG-1 is the only one that's legally unencumbered by patents if I understand correctly. I'm sorry you didn't like it! You might like the other demos.
MPEG-2 is also patent-free as of a few years ago.
That's cool, but i can't help but feel you loose some of the asethetic charm of ascii art once you get this level of fidelity and so many colours.
ASCII is cool but I feel like we've lost something since the days people used to do this on typewriters. Also if you're talking about the high fidelity of my 90 x 15 column text display, then I've done a damn good job I'd say!
Justine is basically a super genius. How do turn out one awesome thing after another.
(See actually portable Executable and ...dip! I can't keep up, what was the other recent one?)
Edit: I found it : https://news.ycombinator.com/item?id=26271117 - Red bean Single file webserver
(See actually portable Executable and ...dip! I can't keep up, what was the other recent one?)
Edit: I found it : https://news.ycombinator.com/item?id=26271117 - Red bean Single file webserver
Respect to Justine. I too have had fun handcrafting and optimizing anti Aliasing algorithms on CPUs. But let’s be honest shaders blaze through stuff like this. Nice s/o to gauss, you only know why if you’ve done this type of work.
Segfaults for me but still very cool concept!
Me too. If it helps OP: https://paste.sr.ht/blob/a9c9431df20e51106c21834abc321e64c23...
Edit: oh, so looking at strace, right before it crashes, the program is looking for sox, which it apparently needs to play audio. Installing sox makes the segfault goes away.
Edit: oh, so looking at strace, right before it crashes, the program is looking for sox, which it apparently needs to play audio. Installing sox makes the segfault goes away.
The way to keep your open source code relevant and working is to submit it as a patch to a large project. If "printvideo" had been written as a video output method for mplayer, ffmpeg, vlc, etc, somebody would have been doing all the day-to-day fixes to keep it working as libraries around it make changes.
Would be an improvement over AAlib or libcaca text output modes. Instead, it'll still just sit quietly neglected and bit-rotting in its forgotten corner of the web.
Would be an improvement over AAlib or libcaca text output modes. Instead, it'll still just sit quietly neglected and bit-rotting in its forgotten corner of the web.
I used to blow people's minds with `mplayer -vo aa`.
I’m not sure what this is describing - is it a thing that allows hires video to play on lowres displays?
You are observing the video of the crab playing over an SSH connection inside PuTTY, a terminal emulator.
I "think" it's a program that plays video (incl hi-res) on the terminal using pure text without using GPU decoding at all.
How much more space efficient is a pixelated video using pure text like this?
Relative to using a real codec at the same resolution? Not at all. That's not the point.
Isn’t the resolution greatly reduced?
A low resolution text stream gzipped may turn out to be smaller I think.
A low resolution text stream gzipped may turn out to be smaller I think.
Sure, but then your comparing apples and oranges. If you take a 4k stream and turn it into 80x25 resolution (ok, its not exactly that) its of course going to be smaller. But if you compare the same resolution, the one using a video codec is going to be smaller. Even uncompressed its going to be smaller in a raw video format compared to text based escape codes (although i dont know what gzip would do compared to uncompressed video)
Probably larger if you compare to full ASCII frames, but you could probably apply the same compression techniques used on video frames to the ASCII format as well. It’s just a grid of “pixels” after all.
There is a lot of really funny analysis of the state of... computer science things in his description.
The page mentions Facebook Magikarp and Photoshop cubic sharpen decimation, but there is no link for the latter. Would like for there to be a link or explanation about what they learned from Photoshop cubic sharpen decimation and where they learned that.
Surprised not to see a mention of sixels, it would fit the overall tone of this thing.
Sixels aren't widely supported in modern terminal emulators, and where they are supported I've found them to be super slow. Fun to play with for sure, but not something I've found any real use for.
Sixels is is an old feature from a couple DEC terminals that lets you print small BMP images in the terminal. We wouldn't be hacking the terminal if we were asking it to the things it was intended to do. I'm much more excited about KiTTY's new graphics protocol since it's very nearly DirectX for ANSI.
It's just kitty; KiTTY is something else.
https://sw.kovidgoyal.net/kitty/graphics-protocol.html
https://sw.kovidgoyal.net/kitty/graphics-protocol.html
```
error: Uncaught SIGSEGV on <omitted-name-of-machine> ./printvideo.com E?/err=2/errno:2/GetLastError:0 Linux <omitted-name-of-machine> 5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021
7fffea2de458 00000042cb19 UNKNOWN 7fffea2df360 000000401722 UNKNOWN 7fffea2df3a0 000000402fec UNKNOWN 7fffea2df3b0 00000040116a UNKNOWN
RAX 0000000000000000 RBX 0000000000000000 RDI 0000000000000000 ST(0) 0.000000 RCX 0000000000000000 RDX 00007fffea2df230 RSI 000000000046b8c0 ST(1) 0.000000 RBP 00007fffea2df360 RSP 00007fffea2df348 RIP 000000000042cb19 ST(2) 0.000000 R8 00007fffea2e0f49 R9 0000000000000004 R10 0000000000000000 ST(3) 0.000000 R11 0000000000000293 R12 00007fffea2df3c8 R13 0000000000000003 ST(4) 0.000000 R14 00007fffea2df3e8 R15 00007fffea2df578 VF PF ZF IF
XMM0 ffffffffffffffffffffffffffffffff XMM8 00000000000000000000000000000000 XMM1 00000000000000000000000000000000 XMM9 00000000000000000000000000000000 XMM2 00000000000000000000000000000000 XMM10 00000000000000000000000000000000 XMM3 ffffffffffffffffffffff0000000000 XMM11 00000000000000000000000000000000 XMM4 00000000000000000000000000000000 XMM12 00000000000000000000000000000000 XMM5 00000000000000000000000000000000 XMM13 00000000000000000000000000000000 XMM6 00000000000000000000000000000000 XMM14 00000000000000000000000000000000 XMM7 00000000000000000000000000000000 XMM15 00000000000000000000000000000000
./printvideo.com -ts /home/vincent/Downloads/crabrave.mpg ```