Far far better than caca. But if you want a picture-perfect quality try instead mpv with a sixel output
The subset of usable characters (glyphs) roughly defines how accurate the picture can be represented: if all you have is - and _ and you want to represent an horizontal pipe, it'll be ugly.
Of course it's more complicated than that, but caca uses ascii, while chafa uses a larger unicode range.
The example is illustrated in picture on https://github.com/csdvrx/derasterize where the left is the original basicidea.c using only unicode halfblocks, and the right has more candidate of different shapes.
Derasterize lets you select the width of the range you want to use, to improve encoding time say for video - but ideally, you would be able to test that whatever font you are using contains the glyphs you want.
The few times I've ever used libcaca/mplayer to try and play videos, it was on Linux consoles with no working X server, or when I had broken the X server, or I was just amused to try it.
The thing about sixel is it's only supported on old DEC glass terminals, xterm with a non-default configuration, mintty, and several emulators that are fairly unlikely to be preinstalled anywhere. So I struggle to imagine a scenario outside of the novelty of playing video media in a terminal where you'd use sixel for playing video over either a dedicated streaming API (raw video stream, networked X, VNC, waypipe) or accessing media over a networked filesystem (e.g. sshfs, which I regularly use to watch videos).
Images are a different matter, where the compromise makes more sense. Juxtaposing images with terminal output is a nifty feature. But the (IMO limited) utility of programs like caca and chafa is being "universal enough" that I can write a script that vomits a jpeg to some vague common denominator standard and it'll probably work for all my coworkers using a smorgasbord of emulators.
> The thing about sixel is it's only supported on old DEC glass terminals, xterm with a non-default configuration, mintty, and several emulators that are fairly unlikely to be preinstalled anywhere
Uh, no?
Just start xterm (say from another xterm) with the correct flag.
Sixels are also supported on the BSD console.
The lack of support in the likes of gnome-terminal is a willful and ugly political decision that I've already documented.
> Images are a different matter, where the compromise makes more sense.
Indeed, I love to do remote gnuplots
> I can write a script that vomits a jpeg to some vague common denominator standard and it'll probably work for all my coworkers using a smorgasbord of emulators.
This is the idea of tmux-sixel https://github.com/csdvrx/sixel-tmux : intercept sixels sequences and, if your terminal doesn't support it (or if you use the scrollback buffer, to save or RAM), render a unicode representation instead (like Chafa), but if it does, pass through the original sixel sequence.
I'm not sure chafa works with video like, say, mplayer built with aalib and libcaca will convert movie files to color or B&W ASCII on the command line (iirc w/ audio only on the host machine). Similarly, on PPC Macs, there was QuickASCII,[1] which lacks audio. I have used tiv,[2] (available with MacPorts) which works very well with images, not video. There was a way to configure the browser links (not lynx) to use tiv to browse the web on cli with converted images.
Let's see you try that over ssh. The subject is command line graphics and video. What you have liked to is nothing of the sort, those are not terminal graphics but rather conventional GPU graphics and merely opening a graphic window within the command prompt on a local machine to play the video. Why bother to do that when you're sitting locally at the machine with access to the GUI and all the GUI media applications?
ffmpeg is a dependency of mplayer, but ffmpeg on it's own can't transcode or reinterpret video as ASCII. The reason for the exercise is only to show that video and graphics can be displayed on the command line within the limitations of the command line, namely, text only.
Far far better than caca. But if you want a picture-perfect quality try instead mpv with a sixel output
The subset of usable characters (glyphs) roughly defines how accurate the picture can be represented: if all you have is - and _ and you want to represent an horizontal pipe, it'll be ugly.
Of course it's more complicated than that, but caca uses ascii, while chafa uses a larger unicode range.
The example is illustrated in picture on https://github.com/csdvrx/derasterize where the left is the original basicidea.c using only unicode halfblocks, and the right has more candidate of different shapes.
Derasterize lets you select the width of the range you want to use, to improve encoding time say for video - but ideally, you would be able to test that whatever font you are using contains the glyphs you want.
The few times I've ever used libcaca/mplayer to try and play videos, it was on Linux consoles with no working X server, or when I had broken the X server, or I was just amused to try it.
The thing about sixel is it's only supported on old DEC glass terminals, xterm with a non-default configuration, mintty, and several emulators that are fairly unlikely to be preinstalled anywhere. So I struggle to imagine a scenario outside of the novelty of playing video media in a terminal where you'd use sixel for playing video over either a dedicated streaming API (raw video stream, networked X, VNC, waypipe) or accessing media over a networked filesystem (e.g. sshfs, which I regularly use to watch videos).
Images are a different matter, where the compromise makes more sense. Juxtaposing images with terminal output is a nifty feature. But the (IMO limited) utility of programs like caca and chafa is being "universal enough" that I can write a script that vomits a jpeg to some vague common denominator standard and it'll probably work for all my coworkers using a smorgasbord of emulators.
> The thing about sixel is it's only supported on old DEC glass terminals, xterm with a non-default configuration, mintty, and several emulators that are fairly unlikely to be preinstalled anywhere
Uh, no?
Just start xterm (say from another xterm) with the correct flag. Sixels are also supported on the BSD console.
The lack of support in the likes of gnome-terminal is a willful and ugly political decision that I've already documented.
> Images are a different matter, where the compromise makes more sense.
Indeed, I love to do remote gnuplots
> I can write a script that vomits a jpeg to some vague common denominator standard and it'll probably work for all my coworkers using a smorgasbord of emulators.
This is the idea of tmux-sixel https://github.com/csdvrx/sixel-tmux : intercept sixels sequences and, if your terminal doesn't support it (or if you use the scrollback buffer, to save or RAM), render a unicode representation instead (like Chafa), but if it does, pass through the original sixel sequence.
1 reply →
I'm not sure chafa works with video like, say, mplayer built with aalib and libcaca will convert movie files to color or B&W ASCII on the command line (iirc w/ audio only on the host machine). Similarly, on PPC Macs, there was QuickASCII,[1] which lacks audio. I have used tiv,[2] (available with MacPorts) which works very well with images, not video. There was a way to configure the browser links (not lynx) to use tiv to browse the web on cli with converted images.
[1] http://quickascii.sourceforge.net/
[2] https://github.com/radare/tiv
> mplayer built with aalib and libcaca will convert movie files to color or B&W ASCII on the command line
I'm not sure why people expose themselves to something as bad and ugly in this day and age.
Even in 2016 you could use ffmpeg on a sixel-aware terminal like mintty or xterm: check https://www.youtube.com/watch?v=IkUTkqctP28
Let's see you try that over ssh. The subject is command line graphics and video. What you have liked to is nothing of the sort, those are not terminal graphics but rather conventional GPU graphics and merely opening a graphic window within the command prompt on a local machine to play the video. Why bother to do that when you're sitting locally at the machine with access to the GUI and all the GUI media applications?
ffmpeg is a dependency of mplayer, but ffmpeg on it's own can't transcode or reinterpret video as ASCII. The reason for the exercise is only to show that video and graphics can be displayed on the command line within the limitations of the command line, namely, text only.
6 replies →
There's a patch out there to use chafa as output for ffmpeg.