Hacker News Reader

Comment by aw3c2 | Hacker News Reader

Please let me middle/right click on videos so I can open them in tabs.

+1. Another nice (and I guess pretty simple) adjustment would be to show a circle on the map, to help user see, how much "5 km" (or whatever) exactly are.

I'd far prefer some sort of interface to allow me to queue the motherfucking videos in the queue-capable viewer of my choice. VLC has some of these features, though its tendency to catch fire and halt (destroying the queue in the process) is annoying.

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.

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).

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 :)

Hrm, sounds interesting. How are you buffering this, if at all?

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

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

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.

mktemp creates a normal file and stores to disk. The FIFO avoids that, which is why I'm interested.

Actually, as I mentioned, /tmp is (AFAIK) everywhere a tmpfs mount, which means these files are kept in RAM and stored to disk only if their pages are swapped.

/tmp is typically but not always a tmpfs mount. Presumptions about where files are or aren't actually written to disk given modern virtual memory is ... somewhat fraught.

It also happens that my /tmp is physically allocated.

And named pipes really and truly work differently (though there can still be buffering).

That said, no joy (though I tracked down the issue above -- configfile setting conflicting with commandline parameters, somewhat annoyingly).

That's cool! I have my TV connected to the sound system and just chromecast from my phone to TV.

Agreed. This is so frustrating. Stop trying to reinvent the UI with ridiculous restrictions like this.

thank you, I will improve it in the next version.

Thanks!

Reply on news.ycombinator.com