summaryrefslogtreecommitdiffstats
path: root/demux/demux_libarchive.c
Commit message (Collapse)AuthorAgeFilesLines
* demux, stream: add option to prevent opening referenced fileswm42016-12-041-0/+3
| | | | Quite irresponsibly hacked together. Sue me.
* libarchive: unify entry iteration between stream/demux layerswm42016-07-181-16/+3
| | | | No really good reason to duplicate this.
* libarchive: remove redundant log prefixKevin Mitchell2015-11-091-1/+1
| | | | "libarchive:" is already added by the logging system
* demux_libarchive: don't allow probing to read unlimited datawm42015-08-241-5/+17
| | | | | | | | | | | | | | | | | Instead, allow reading 2KB only. This seems to be sufficient for libarchive to recognize zip, 7z, rar, tar. Good enough. This is implemented by creating an in-memory stream with a copy of the file header. If libarchive succeeds opening this, the actual stream is opened. Allowing unlimited reading could break unseekable streams, such as playing from http servers with no range request support or pipes. Also, we try not to read too much data in the first probe pass. Some slow network streams like shoutcast services could make probing much slower if we allow it to read too much. In the second probing pass, actually allow 200KB.
* demux_libarchive: reject 0-sized fileswm42015-08-181-0/+3
| | | | libarchive does strange things with them.
* demux_libarchive: open flat compressed fileswm42015-08-171-1/+4
| | | | | | | | Things like .gz etc., which have no real file header. A mixed bag, because it e.g. tends to misdetect mp3 files as compressed files or something (of course it has no mp3 support - I don't know as what it detects them). But requested by someone (or maybe not, I'm not sure how to interpret that).
* stream: libarchive wrapper for reading compressed archiveswm42015-08-171-0/+88
This works similar to the existing .rar support, but uses libarchive. libarchive supports a number of formats, including zip and (most of) rar. Unfortunately, seeking does not work too well. Most libarchive readers do not support seeking, so it's emulated by skipping data until the target position. On backwards seek, the file is reopened. This works fine on a local machine (and if the file is not too large), but will perform not so well over network connection. This is disabled by default for now. One reason is that we try libarchive on every file we open, before trying libavformat, and I'm not sure if I trust libarchive that much yet. Another reason is that this breaks multivolume rar support. While libarchive supports seeking in rar, and (probably) supports multivolume archive, our support of libarchive (probably) does not. I don't care about multivolume rar, but vocal users do.