Hacker News new | past | comments | ask | show | jobs | submit login

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 | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact