summaryrefslogtreecommitdiffstats
path: root/stream/stream_libarchive.c
Commit message (Collapse)AuthorAgeFilesLines
* stream_libarchive: make libarchive seek callback lazyKevin Mitchell2015-11-091-3/+22
| | | | This fixes problems seeking http streams to their end.
* stream_libarchive: add multivolume supportKevin Mitchell2015-11-091-15/+155
| | | | | | | | | | | | | | This commit introduces logic to read other volumes from the same source as the primary archive. Both .rar formats as well as 7z are supported for now. It also changes the libarchive callback structure to be per-volume consistent with the libarchive intenal client data array constructed with archive_read_append_callback_data. Added open, close and switch callbacks. Only the latter is strictly required to make sure that the streams always start at position 0, but leaving all volumes open can eat a lot of memory for archives with many parts.
* libarchive: remove redundant log prefixKevin Mitchell2015-11-091-3/+3
| | | | "libarchive:" is already added by the logging system
* stream_libarchive: read tar only in "unsafe" modewm42015-08-221-2/+4
| | | | | | | | | | As expected, probing with libarchive is a disaster. Both libavformat and libarchive are too eager to misdetect file formats just because files "might" be of a specific type. In this case, it's mp3 vs. tar. To be fair, neither file format has an actual header. I'm not sure why we'd need tar support, but since libarchive provides it, and idiots on the internet apparently pack media files in tar sometimes (really, idiots), keep it for now, and probe tar last.
* stream_libarchive: disable raw filterwm42015-08-201-2/+0
| | | | | Too many false positives (it accepts things like unspecific text files), and also relatively useless.
* stream_libarchive: fix libarchive callback signaturewm42015-08-201-1/+1
| | | | | | | | | | | libarchive uses a quite confusing ifdeffery mess for some of the types used in callbacks. Currently, archive_read_set_seek_callback() causes a warning at least on Windows due to mismatching return type. The header file uses __LA_INT64_T as return type, so I think the user is intended to use int64_t. (The ssize_t return type for the read_cb seems correct, on the other hand.)
* stream_libarchive: restrict number of allowed formatswm42015-08-181-2/+11
| | | | | Most of what is not in this list is extremely obscure, or increases the file format misdetection rate.
* stream: provide a stream_get_size() convenience functionwm42015-08-181-2/+1
| | | | | And use it everywhere, instead of retrieving the size manually. Slight simplification.
* demux_libarchive: open flat compressed fileswm42015-08-171-2/+5
| | | | | | | | 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/+260
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.