4 ms·

https://github.com/rg3/youtube-dl https://github.com/rg3/youtube-dl 1. right-click -> "Copy Link Location" 2. middle click to paste the link into you s

by pdkl95 11y ago

https://github.com/rg3/youtube-dl https://github.com/rg3/youtube-dl 1. right-click -> "Copy Link Location" 2. middle click to paste the link into you shell 3. run "youtube-dl" on the URL(s) 4. watch the videos in whatever video player you want One of these days I should make a quick firefox extension that adds a context-menu option to collapse it down to one step. You will have to update youtube-dl every time (see the "-U" option) Google decides to change the obfuscation. Also, you may want to try the --list-extractors and --extractor-descriptions options, to see the long list of sites that are supported, which includes support for things like youtube playlists searches.

dredmorbius 11y ago
That is in fact my working solution. The disadvantage over VLC is that you've got the videos sitting on disk, sucking space, while VLC will queue and buffer videos. Depending on what you're watching, youtube-dl can suck up a lot of space. Mind the -F and -f options -- these list and select video quality. I find '43' for YouTube (640x360) is usually sufficient for instructional materials (lectures/presentations).
thegeomaster 11y ago
I have a cute setup for playing YouTube videos (mostly music) via SSH from my phone when I'm lying on my bed and too lazy to get up. There's a small CL script which searches YouTube based on a query, then fires up youtube-dl and dumps the raw file to a named pipe. Then, when the header and everything needed for VLC to start streaming is ready, it starts up VLC via its ncurses interface, so I can volume up/down, pause/play and seek if needed from my phone. VLC is nice enough to fire up an X11 window if you give it the right DISPLAY environment variable over SSH, so you can watch the video (even make it fullscreen via the ncurses interface). Once the video finishes playing, obviously, the named pipe and the data is gone---everything's in memory anyways. These days I'll get to uploading it to GitHub, maybe even turn it into a Firefox extension/Android app. Though it's a little specific to my use case: I have a quality sound system attached to my desktop computer so it doesn't feel right to listen to stuff on my laptop/phone when there is such a great setup lying around. And setting up SBCL and Shelly just to run Common Lisp scripts is a little bit of an overkill. Sorry for the off-topic, just felt like sharing this bit of my computer-aided laziness :)
- dredmorbius 11y ago
  Hrm, sounds interesting. How are you buffering this, if at all?
  - thegeomaster 11y ago
    Well, everything goes through the FIFO pipe. VLC should block on reading if there is not enough data, though I haven't tested it in that case (I have a cable connection so video hiccups don't normally happen). The script buffers the first couple of kilobytes so the header is immediately available, but beyond that buffering should be handled by the kernel. Though I might be misunderstanding your question...
    - dredmorbius 11y ago
      I tried writing to a named pipe but youtube-dl griped. mkfifo FIFO youtube-dl -o - $SOME_URL > FIFO & mplayer FIFO youtube-dl quits: youtube-dl: error: using output template conflicts with using title, video ID or auto number
      - thegeomaster 11y ago
        Hm, this works for me. Maybe try with `-f best`? Here's a minimal working example (just figured out it doesn't even need the header buffering hack I was using so far): $ mkfifo FIFO $ youtube-dl -f best -o - 6h9vr_xwTj4 > FIFO & $ vlc - < FIFO And VLC plays the video just fine. youtube-dl downloads it from YouTube as the bytes are read() by VLC, so the D/L speed is around 25KiB/s. Though I assume you can also stream this at full speed by doing a `mktemp` and dumping the data into the file. In my experience, VLC handles files which are still being appended data just fine, but it'll freak out if it reaches EOF before the end of the stream. If your /tmp is tmpfs, which it is everywhere AFAIK, the only difference is that the video is being downloaded in full speed. Alternatively, if your downlink is fast (for instance, 4MiB/s) and you don't mind the slight delay, you can as well download the file wholly as mentioned in one of the ancestor comments.

by pdkl95 11y ago

dredmorbius 11y ago

That is in fact my working solution. The disadvantage over VLC is that you've got the videos sitting on disk, sucking space, while VLC will queue and buffer videos. Depending on what you're watching, youtube-dl can suck up a lot of space. Mind the -F and -f options -- these list and select video quality. I find '43' for YouTube (640x360) is usually sufficient for instructional materials (lectures/presentations).

thegeomaster 11y ago

I have a cute setup for playing YouTube videos (mostly music) via SSH from my phone when I'm lying on my bed and too lazy to get up. There's a small CL script which searches YouTube based on a query, then fires up youtube-dl and dumps the raw file to a named pipe. Then, when the header and everything needed for VLC to start streaming is ready, it starts up VLC via its ncurses interface, so I can volume up/down, pause/play and seek if needed from my phone. VLC is nice enough to fire up an X11 window if you give it the right DISPLAY environment variable over SSH, so you can watch the video (even make it fullscreen via the ncurses interface). Once the video finishes playing, obviously, the named pipe and the data is gone---everything's in memory anyways. These days I'll get to uploading it to GitHub, maybe even turn it into a Firefox extension/Android app. Though it's a little specific to my use case: I have a quality sound system attached to my desktop computer so it doesn't feel right to listen to stuff on my laptop/phone when there is such a great setup lying around. And setting up SBCL and Shelly just to run Common Lisp scripts is a little bit of an overkill. Sorry for the off-topic, just felt like sharing this bit of my computer-aided laziness :)

dredmorbius 11y ago
Hrm, sounds interesting. How are you buffering this, if at all?
- thegeomaster 11y ago
  Well, everything goes through the FIFO pipe. VLC should block on reading if there is not enough data, though I haven't tested it in that case (I have a cable connection so video hiccups don't normally happen). The script buffers the first couple of kilobytes so the header is immediately available, but beyond that buffering should be handled by the kernel. Though I might be misunderstanding your question...
  - dredmorbius 11y ago
    I tried writing to a named pipe but youtube-dl griped. mkfifo FIFO youtube-dl -o - $SOME_URL > FIFO & mplayer FIFO youtube-dl quits: youtube-dl: error: using output template conflicts with using title, video ID or auto number
    - thegeomaster 11y ago
      Hm, this works for me. Maybe try with `-f best`? Here's a minimal working example (just figured out it doesn't even need the header buffering hack I was using so far): $ mkfifo FIFO $ youtube-dl -f best -o - 6h9vr_xwTj4 > FIFO & $ vlc - < FIFO And VLC plays the video just fine. youtube-dl downloads it from YouTube as the bytes are read() by VLC, so the D/L speed is around 25KiB/s. Though I assume you can also stream this at full speed by doing a `mktemp` and dumping the data into the file. In my experience, VLC handles files which are still being appended data just fine, but it'll freak out if it reaches EOF before the end of the stream. If your /tmp is tmpfs, which it is everywhere AFAIK, the only difference is that the video is being downloaded in full speed. Alternatively, if your downlink is fast (for instance, 4MiB/s) and you don't mind the slight delay, you can as well download the file wholly as mentioned in one of the ancestor comments.