Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: