From fc76d41194813754fb687189a312f564c941e5fa Mon Sep 17 00:00:00 2001 From: wm4 Date: Wed, 21 Feb 2018 17:02:18 +0100 Subject: stream_file: add mode for reading appended files Do this because retrying reading on higher levels (like the demuxer) usually causes tons of problems. A hack like this is simpler and could allow to remove some of the higher level retry behavior. This works by trying to detect whether the file is appended. If we reach EOF, check if the file size changed compared to the initial value. If it did, it means the file was appended at least once, and we set the p->appending flag. If that flag is set, we simply retry reading more data every time we encounter EOF. The only way to do this is polling, and we poll for at most 10 times, after waiting for 200ms every time. --- DOCS/man/mpv.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'DOCS') diff --git a/DOCS/man/mpv.rst b/DOCS/man/mpv.rst index ec68d9a9da..5ce5d43e25 100644 --- a/DOCS/man/mpv.rst +++ b/DOCS/man/mpv.rst @@ -803,6 +803,19 @@ PROTOCOLS ``PATH`` itself should start with a third ``/`` to make the path an absolute path. +``appending://PATH`` + + Play a local file, but assume it's being appended to. This is useful for + example for files that are currently being downloaded to disk. This will + block playback, and stop playback only if no new data was appended after + a timeout of about 2 seconds. + + Using this is still a bit of a bad idea, because there is no way to detect + if a file is actually being appended, or if it's still written. If you're + trying to play the output of some program, consider using a pipe + (``something | mpv -``). If it really has to be a file on disk, use tail to + make it wait forever, e.g. ``tail -f -c +0 file.mkv | mpv -``. + ``fd://123`` Read data from the given file descriptor (for example 123). This is similar -- cgit v1.2.3