← Back to context

Comment by Maursault

3 years ago

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.

    • > Let's see you try that over ssh

      I do that everyday lol

      > What you have liked to is nothing of the sort and merely opening of a window within the command prompt on a local machine

      I don't think you understand: sixels work IN BAND, meaning ssh will transmit the full video flux "after" it's converted into sixels (it's a little more complicated than that, but I'm trying to say don't expect a SYN/ACK outside of ssh own), which will then be rendered on the remote terminal into pictures upon reception.

      It's just like doing 'cat' on a remote file: the content will be transmitted regardless, just at different speeds depending on your available bandwith

      > Why bother to do that when you're sitting locally at the machine with access to all the GUI applications?

      I prefer the terminal, it's more efficient.

      5 replies →