Terminal Video – Watch YouTube Videos in Terminal

adobe-flashterminalvideo

I'm looking for a way to watch YouTube videos in terminal (not in a browser or another window, but right there, in any bash session).

Is there a simple way to do this?

I imagine something like this:

$ youtube <video-url>

I already know how to play a video using mplayer:

$ mplayer -vo caca local-file.avi

However, this opens a new window. It would be cool to play it in terminal.

Also, it should be compatible with tmux sessions.

I asked another question for how to prevent opening a new window.

For those that wonder where I need such a functionality, I started an experimental project named TmuxOS — with the concept that everything should run inside of a tmux session.

So, indeed I need a video player for local and remote videos. 🙂

Best Answer

You can download videos and/or just the audio and then watch/listen to them using youtube-dl. The script is written in Python and makes use of ffmpeg I believe.

$ youtube-dl --help
Usage: youtube-dl [options] url [url...]

Options:
  General Options:
    -h, --help                       print this help text and exit
    --version                        print program version and exit
    -U, --update                     update this program to latest version.
                                     Make sure that you have sufficient 
                                     permissions (run with sudo if needed)
...
...

To download videos you simply give it the URL from the page you want the video on and the script does the rest:

$ youtube-dl https://www.youtube.com/watch?v=OwvZemXJhF4
[youtube] Setting language
[youtube] OwvZemXJhF4: Downloading webpage
[youtube] OwvZemXJhF4: Downloading video info webpage
[youtube] OwvZemXJhF4: Extracting video information
[youtube] OwvZemXJhF4: Encrypted signatures detected.
[youtube] OwvZemXJhF4: Downloading js player 7N
[youtube] OwvZemXJhF4: Downloading js player 7N
[download] Destination: Joe Nichols - Yeah (Audio)-OwvZemXJhF4.mp4
[download] 100% of 21.74MiB in 00:16

You can then use vlc or mplayer to watch these locally:

$ vlc "Joe Nichols - Yeah (Audio)-OwvZemXJhF4.mp4"
VLC media player 2.1.5 Rincewind (revision 2.1.4-49-gdab6cb5)
[0x1cd1118] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"

OK but I want to watch these videos as they're streamed & in ASCII

I found this blog article titled: On ascii, youtube and letting go that demonstrates the method that I discussed in the chatroom, mainly using youtube-dl as the "backend" which could do the downloading of the YouTube stream and then redirecting it to some other app.

This article shows it being done with mplayer:

$ youtube-dl http://www.youtube.com/watch?v=OC83NA5tAGE -o - | \
    mplayer -vo aa -monitorpixelaspect 0.5 -

The video being downloaded by youtube-dl is redirected via STDOUT above, -o -. There's a demo of the effect here.

ss#1

With the installation of additional libraries the ASCII video can be enhanced further.

ss#2

OK but I want the video in my actual terminal?

I found this trick which allows video to be played in an xterm in the O'Reilly articled titled: Watch Videos in ASCII Art.

$ xterm -fn 5x7 -geometry 250x80 -e "mplayer -vo aa:driver=curses j.mp4

The above results in a xterm window being opened where the video plays.

ss#3

So I thought, why not put the peanut butter and the chocolate together like this:

$ xterm -fn 5x7 -geometry 250x80 -e \
    "youtube-dl http://www.youtube.com/watch?v=OC83NA5tAGE -o - | \
    mplayer -vo aa:driver=curses -"

This almost works! I'm not sure why the video cannot play in the window, but it would seem like it should be able to. The window comes up and starts to play but then closes. I see video for a brief few seconds and then nothing.

Perhaps the above will get you closer to your ultimate solution, or perhaps it just needs to be tweaked a bit on the options.

Additional libraries

If you have libcaca installed (the colorized version of aalib) and you reduce the font size in your gnome-terminal to something really small, like say 3, the following command will display a much better looking ASCII video directly within the terminal:

$ CACA_DRIVER=ncurses mplayer -vo caca video.mp4

ss#4

Terminals

It would seem that the choice of terminal can make a big deal as to whether mplayer can play directly inside the terminal or whether it opens a separate window. Caching too on mplayer made a dramatic difference in being able to play directly in ones terminals.

Using this command I was able to play in terminator, at least for the first 1/4 of the video before it cut out:

$ youtube-dl http://www.youtube.com/watch?v=OC83NA5tAGE -o - | \
    mplayer -cache 32767 -vo aa:driver=curses -

The colored version used this command:

$ youtube-dl http://www.youtube.com/watch?v=OC83NA5tAGE -o - | \
    CACA_DRIVER=ncurses mplayer -cache 64000 -vo caca -

These same commands could play in gnome-terminal & xterm too.

ss montage

NOTE: That's (from Left to Right) xterm, terminator, gnome-terminal, and terminology.

Related Solutions

Broadcast messages don’t appear on gnome-terminal, but appear on xterm

The terminals listed hints that the behavior is seen with Linux: The clues are in the manual page for wall (Solaris for instance is different):

wall displays a message, or the contents of a file, or otherwise its standard input, on the terminals of all currently logged in users.

Some sessions, such as wdm, that have in the beginning of utmp(5) ut_type data a ':' character will not get the message from wall. This is done to avoid write errors.

That is, wall uses the utmp data, looks for terminals in use (i.e., logged-in users), and writes to the associated device. Each line in the output of w shows a (possible) terminal, recorded by the terminal in the utmp file. For instance, I am ssh'd into a server and running screen while at the same time I logged into a console. Just for completeness, I ran xterm using the -ls (login-shell) option. Here is the output of w:

$ w
 19:53:15 up  4:08,  5 users,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
tom      tty2                      19:48    5:11   0.04s  0.02s -tcsh
tom      pts/0    michener:S.0     15:51   13:18   0.35s  0.24s ssh -X thomas@b
tom      pts/2    michener:S.1     16:34    2.00s  0.14s  0.00s sh -c w
tom      pts/4    michener:S.3     15:52    3:59m  0.12s  0.00s /bin/sh /users/
tom      pts/3    localhost:10.0   19:53    7.00s  0.03s  0.03s -tcsh

and running wall writes to each of those TTY devices.

However, if the terminal does not write to the utmp file, it will not be listed — and wall will ignore it.

Now, some programs may have the feature compiled-in, but lack privileges to change it. That is why some programs are run with setgid to the "utmp" group. Other programs (such as xterm — or gnome-terminal) may use an external program that updates utmp on their behalf.

With gnome-terminal, the feature has been deprecated due to the mindset of the gnome developers that (a) users run on a local machine, where gdm handles login, and (b) consequently there's no distinction worth bothering about between login shells and non-login shells. That makes for some interesting bug reports:

Terminal – What is Switching Environments System-Wide Called?

They are kernel virtual terminal devices, multiplexed onto the physical framebuffer and human-input devices by a terminal emulator program that is built into the kernel itself. To applications programs running on top of the kernel, they look like any other terminal devices, such as a serial terminal device. (They have a line discipline, but no modem control.)

The system implements terminal login by dint of running a getty program (or equivalent) and a login program that accept user credentials and invoke login sessions.

The X server program also needs to use the physical framebuffer and human-input devices. It needs to negotiate sharing them with the kernel terminal emulator. It does so by allocating one virtual terminal and telling the kernel to disconnect that from the kernel terminal emulator.

Hence why it appears that the X server "runs" on a particular terminal. When the kernel terminal emulator sees the hotkey chord for switching to the allocated virtual terminal, it cedes control of the framebuffer and human-input devices to to the X server. When the X server sees the hotkey chord for switching to another virtual terminal, the X server cedes control back.

These hotkey chords are not necessarily symmetrical. On one of my systems the hotkey chord implemented by the kernel terminal emulation program for switching to virtual terminal #2 is Alt+F2 whereas the hotkey chord implemented by the X server for the same action is Ctrl+Alt+F2.

When it comes to graphical login, a display manager handles starting up X servers with greeter programs. You're just starting an X server directly and not using a display manager, of course. Once the user credentials have been authenticated, a desktop manager displays a desktop environment, which comprises a set of X client applications of varying degrees of complexity. For complex desktop environments, there is a whole bunch of server programs interconnected via a desktop bus. (On one of my systems, the so-called "small and lightweight" GNOME Editor requires a D-BUS broker and nine other server programs to be running.)

Some of those X client programs can be other terminal emulators, userspace ones, such as LXTerminal, Unicode RXVT, GNOME Terminal, Terminate, roxterm, evilvte, xterm, and so forth. These do not directly use physical framebuffer and human-input devices, and they make use of pseudo-terminal devices.