4 ms·

> 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 somethin

by csdvrx 4y ago

> 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 https://www.youtube.com/watch?v=IkUTkqctP28

Maursault 4y ago
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.
- csdvrx 4y ago
  > 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.
  - Maursault 4y ago
    >>Let's see you try that over ssh >I do that everyday lol Unconvincing. lol If you tried to transmit video using the sixel protocol over ssh, you will experience bandwidth issues and immediately fail. >>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, which will then be rendered on the remote terminal into pictures upon reception. It's just like doing 'cat' on a remote file This will not work. "Sixel is broken because the emulation behavior depends on the font size, thus theoretically can't be supported by terminals that don't have the concept of pixel size (e.g. a detached tmux). Sixel is broken because it cannot be supported by tmux with side-by-side panes. Sixel's palette-based approach is also a terrible legacy, practically unable to transfer photos."[1] [1] https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/26 https://gitlab.freedesktop.org/terminal-wg/specifications/-/...
    - anthk 4y ago
      False. I could open sixels images over SSH with an XTerm.
    - csdvrx 4y ago
      > If you tried to transmit video using the sixel protocol over ssh, you will experience bandwidth issues and immediately fail. Even abstracting away your incomplete understanding of how sixels work, have you considered the possibility I may have access to way more bandwidth than you? (and I most likely do) > This will not work. Yes it does. I have written lots of sixel code (I've yet to see any of yours), tried to explain you the failure in your reasoning, yet you still don't believe me, then you deny the reality of my lived sixel experience with... a biased quote? Whatever. Have it your way. I'm out.
      - Maursault 4y ago
        Extraordinary claims require extraordinary evidence. For sixels to be displayed, the terminal must have support for them, and most terminals don't support sixels, like Windows Terminal. xterm has some support, but only 16 colors. But xterm is otherwise an exceptionally feature-poor terminal. I don't think anyone uses xterm unless there is no other option. While sixels are a very old standard, lack of significant adoption and a code base that is notoriously buggy means that more often than not, the ability to display sixels just isn't there, and on the rare occasion that it is, artifacts are extremely common. ASCII, otoh, is supported by all terminals. Now, granted, no one wants to watch a video converted into text, but this isn't the point, which is merely a method to display something on the command line, and in the case of ASCII, every command line, every terminal, everywhere and always. mplayer is not dependent on the client, so any remote client can run it remotely from the server. sixel support is the opposite; the client must have support for sixels to be displayed. > I'm not sure why people expose themselves to something as bad and ugly in this day and age. > I don't think you understand > Even abstracting away your incomplete understanding of how sixels work > I have written lots of sixel code (I've yet to see any of yours) > tried to explain you the failure in your reasoning FWIW, all these arguments are ad hominem fallacies indicating invalid and otherwise faulty reasoning.

by csdvrx 4y ago

Maursault 4y ago

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.

csdvrx 4y ago
> 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.
- Maursault 4y ago
  >>Let's see you try that over ssh >I do that everyday lol Unconvincing. lol If you tried to transmit video using the sixel protocol over ssh, you will experience bandwidth issues and immediately fail. >>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, which will then be rendered on the remote terminal into pictures upon reception. It's just like doing 'cat' on a remote file This will not work. "Sixel is broken because the emulation behavior depends on the font size, thus theoretically can't be supported by terminals that don't have the concept of pixel size (e.g. a detached tmux). Sixel is broken because it cannot be supported by tmux with side-by-side panes. Sixel's palette-based approach is also a terrible legacy, practically unable to transfer photos."[1] [1] https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/26 https://gitlab.freedesktop.org/terminal-wg/specifications/-/...
  - anthk 4y ago
    False. I could open sixels images over SSH with an XTerm.
  - csdvrx 4y ago
    > If you tried to transmit video using the sixel protocol over ssh, you will experience bandwidth issues and immediately fail. Even abstracting away your incomplete understanding of how sixels work, have you considered the possibility I may have access to way more bandwidth than you? (and I most likely do) > This will not work. Yes it does. I have written lots of sixel code (I've yet to see any of yours), tried to explain you the failure in your reasoning, yet you still don't believe me, then you deny the reality of my lived sixel experience with... a biased quote? Whatever. Have it your way. I'm out.
    - Maursault 4y ago
      Extraordinary claims require extraordinary evidence. For sixels to be displayed, the terminal must have support for them, and most terminals don't support sixels, like Windows Terminal. xterm has some support, but only 16 colors. But xterm is otherwise an exceptionally feature-poor terminal. I don't think anyone uses xterm unless there is no other option. While sixels are a very old standard, lack of significant adoption and a code base that is notoriously buggy means that more often than not, the ability to display sixels just isn't there, and on the rare occasion that it is, artifacts are extremely common. ASCII, otoh, is supported by all terminals. Now, granted, no one wants to watch a video converted into text, but this isn't the point, which is merely a method to display something on the command line, and in the case of ASCII, every command line, every terminal, everywhere and always. mplayer is not dependent on the client, so any remote client can run it remotely from the server. sixel support is the opposite; the client must have support for sixels to be displayed. > I'm not sure why people expose themselves to something as bad and ugly in this day and age. > I don't think you understand > Even abstracting away your incomplete understanding of how sixels work > I have written lots of sixel code (I've yet to see any of yours) > tried to explain you the failure in your reasoning FWIW, all these arguments are ad hominem fallacies indicating invalid and otherwise faulty reasoning.