4 ms·

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 co

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.
  - dredmorbius 11y ago
    mktemp creates a normal file and stores to disk. The FIFO avoids that, which is why I'm interested.
    - thegeomaster 11y ago
      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.
      - dredmorbius 11y ago
        /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).

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.
- dredmorbius 11y ago
  mktemp creates a normal file and stores to disk. The FIFO avoids that, which is why I'm interested.
  - thegeomaster 11y ago
    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.
    - dredmorbius 11y ago
      /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).