Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 01.04.2015 21:22, Alexander Strasser wrote:
On 2015-03-28 23:30 +0100, Lukasz Marek wrote:
W dniu sobota, 28 marca 2015 Peter Ross napisał(a):
What about the following?
ffplay zip://dir/a.zip/m.mkv # open dir/a.zip, read file m.mkv inside
ffplay -file m.mkv zip://dir/a.zip # same effect as above
ffplay zip://dir.zip/a.ass/m.txt # open dir.zip, read file a.ass/m.txt inside
ffplay -file m.txt zip://dir.zip/a.ass # open dir.zip/a.ass, read file m.txt
inside
Patch that implements that on top of Lukasz's patch is attached.
Beware it is quickly implemented and only lightly tested, just to
show that it is possible to implement that behaviour. Do not expect
it to be beautiful and flawless.
Also I didn't even attempt to work out details like option name and if
we should match first or last .zip occurrence when guessing.
I've attached another implementation based on libarchive. It is also
just demo patch, not something that is ready to be merged.
I skipped totally the problem with selecting internal file. I just open
the first available.
Libarchive allows:
1. Using protocols, so archive can be on remote host, tested via ftp and
sftp (didn't check extracting from inner archive)
2. It provides archive_seek_data which seems to allow make this protocol
seekable, but it is not working for me. Official documentation doesn't
mention this function. Doxy in header is not much more helpful.
Libarchive does not allows:
1. Decompress encrypted archives (there is a ticket for that)
2. I cannot decompress rar archives (still better than libzip)
It still needs some tests and possibly digging in libarchive code.
Some contact with them may resolve some doubts.
Regarding selecting inner file, IMHO additional parameter and guessing
by extension is the best choice until protocols support stat operation
in efficient way. Of course assuming it should use protocols.
I will not work on this withing next week at least so if someone wants
to continue then go ahead, just let me know please, so we don't
duplicate the work again.
>From 71e69b5d3beed3429a310c413e4139f640e837e2 Mon Sep 17 00:00:00 2001
From: Lukasz Marek
Date: Fri, 20 Mar 2015 18:31:00 +0100
Subject: [PATCH] lavf: add zip protocol
TODO: add doc, update doc/APIChanges, bump minor
---
configure| 4 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 1 +
libavformat/libarchive.c | 193 +++
4 files changed, 200 insertions(+)
create mode 100644 libavformat/libarchive.c
diff --git a/configure b/configure
index 392946a..9cb4cfc 100755
--- a/configure
+++ b/configure
@@ -276,6 +276,7 @@ External library support:
--disable-sdldisable sdl [autodetect]
--enable-x11grab enable X11 grabbing (legacy) [no]
--disable-xlib disable xlib [autodetect]
+ --enable-libarchive enable libarchive [no]
--disable-zlib disable zlib [autodetect]
Toolchain options:
@@ -1406,6 +1407,7 @@ EXTERNAL_LIBRARY_LIST="
libxcb_shape
libxcb_xfixes
libxvid
+libarchive
libzmq
libzvbi
lzma
@@ -2599,6 +2601,7 @@ udp_protocol_select="network"
udplite_protocol_select="network"
unix_protocol_deps="sys_un_h"
unix_protocol_select="network"
+libarchive_protocol_deps="libarchive"
# filters
amovie_filter_deps="avcodec avformat"
@@ -4981,6 +4984,7 @@ enabled libsmbclient && { use_pkg_config smbclient libsmbclient.h smbc_init
require smbclient libsmbclient.h smbc_init -lsmbclient; }
enabled libsoxr && require libsoxr soxr.h soxr_create -lsoxr
enabled libssh&& require_pkg_config libssh libssh/sftp.h sftp_init
+enabled libarchive&& require_pkg_config libarchive archive.h archive_read_open
enabled libspeex && require_pkg_config speex speex/speex.h speex_decoder_init -lspeex
enabled libstagefright_h264 && require_cpp libstagefright_h264 "binder/ProcessState.h media/stagefright/MetaData.h
media/stagefright/MediaBufferGroup.h media/stagefright/MediaDebug.h media/stagefright/MediaDefs.h
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2118ff2..c971ef1 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -522,6 +522,8 @@ OBJS-$(CONFIG_TLS_PROTOCOL) += tls.o
OBJS-$(CONFIG_UDP_PROTOCOL) += udp.o
OBJS-$(CONFIG_UDPLITE_PROTOCOL) += udp.o
OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
+OBJS-$(CONFIG_LIBARCHIVE_PROTOCOL) += libarchive.o
+
OBJS-$(HAVE_LIBC_MSVCRT) += file_open.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 26ccc27..9a9eef4 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -379,6 +379,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(UDP, udp);
REGISTER_PROTOCOL(UDPLITE, udplite);
REGISTER_PROTOCOL(UNIX, unix);
+REGISTER_P
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 2015-03-28 23:30 +0100, Lukasz Marek wrote:
> W dniu sobota, 28 marca 2015 Peter Ross napisał(a):
>
> > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote:
> > > I assumed it is local file (no other option so far). So I stat full path
> > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then
> > I
> > > opened it as zip file and used fallback to open first file.
> > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so
> > on...
> > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a path
> > > inside zip.
> >
> > walking the path means that the archive protocol must know about the
> > syntax of the underlying protocol (file, http, ftp, etc.). that seems
> > messy.
> > also inefficient if you have got to walk a long ftp path.
>
>
> I think filesystem looks the same on every server, no matter it is http,
> ftp or any other server.
>
> wouldn't we be better off defining a special character that seperates the
> > zip
> > path from the inner path. obviously we'd need some way of escaping the
> > character
> > if it is legitimately part of either path.
>
> > In real life you might assume that archive has extension zip, rar,
> 7z,... and try to open according to it in first try, if user has archive
> with "ass" extension in directory called "data.zip" then they have to wait.
> i really would avoid to escape anything. this is just annoying. i remember
> i used to escape urls with so many ifs, if file then dont escape, if http
> then escape, and so on. handling archives with its own escapes is kinda
> stupid. it would be easier just to add an option to pass inner file.
What about the following?
ffplay zip://dir/a.zip/m.mkv # open dir/a.zip, read file m.mkv inside
ffplay -file m.mkv zip://dir/a.zip # same effect as above
ffplay zip://dir.zip/a.ass/m.txt # open dir.zip, read file a.ass/m.txt inside
ffplay -file m.txt zip://dir.zip/a.ass # open dir.zip/a.ass, read file m.txt
inside
Patch that implements that on top of Lukasz's patch is attached.
Beware it is quickly implemented and only lightly tested, just to
show that it is possible to implement that behaviour. Do not expect
it to be beautiful and flawless.
Also I didn't even attempt to work out details like option name and if
we should match first or last .zip occurrence when guessing.
Alexander
From 0af78adac09fb6b93a4cc39c71d6e562f9689153 Mon Sep 17 00:00:00 2001
Message-Id:
<0af78adac09fb6b93a4cc39c71d6e562f9689153.1427915596.git.eclip...@gmx.net>
From: Alexander Strasser
Date: Wed, 1 Apr 2015 21:08:42 +0200
Subject: [PATCH] WIP: lavf/zip: Guess zip file or use full path and option to
select the file inside the archive
Signed-off-by: Alexander Strasser
---
libavformat/zip.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/libavformat/zip.c b/libavformat/zip.c
index c9d6679..a240002 100644
--- a/libavformat/zip.c
+++ b/libavformat/zip.c
@@ -32,6 +32,7 @@ typedef struct {
struct zip *z;
struct zip_file *f;
+char *file; //< file path relative to the root of the archive
char *password;
int file_index;
int64_t filesize;
@@ -56,8 +57,7 @@ static int ffzip_split_url(URLContext *h, const char *url,
char **file)
{
ZIPContext *zip = h->priv_data;
int ret = 0;
-struct stat st;
-char *filename, *pos;
+char *filename;
*file = NULL;
@@ -68,25 +68,23 @@ static int ffzip_split_url(URLContext *h, const char *url,
char **file)
if (!filename)
return AVERROR(ENOMEM);
-pos = filename;
-while (pos) {
-if (pos != filename)
-*pos = 0;
-if ((stat(filename, &st) == 0) && S_ISREG(st.st_mode)) {
-av_log(h, AV_LOG_DEBUG, "Trying to open file: %s\n", filename);
-zip->z = zip_open(filename, 0, NULL);
-break;
+if (zip->file) {
+*file = zip->file;
+} else {
+char * ext = filename;
+while ((ext = strchr(ext, '.')) && ext) {
+if (!strncmp(ext, ".zip/", 5)) {
+*file = av_strdup(ext + 5);
+*(ext + 5-1) = 0;
+break;
+}
+++ext;
}
-if (pos != filename)
-*pos = '/';
-pos = strchr(pos + 1, '/');
}
+av_log(h, AV_LOG_DEBUG, "Trying to open file: %s\n", filename);
+zip->z = zip_open(filename, 0, NULL);
if (!zip->z) {
ret = AVERROR(EIO);
-} else if (pos != filename && pos[1]) {
-*file = av_strdup(pos + 1);
-if (!*file)
-ret = AVERROR(ENOMEM);
}
av_free(filename);
return ret;
@@ -154,6 +152,7 @@ static int64_t ffzip_seek(URLContext *h, int64_t pos, int
whence)
#define E AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
{"file_index", "set file index", OFFSET(file_index), AV_OPT_TYPE_INT,
{.i64 = 0}, -1, INT_MAX, D|E },
+{"file",
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 2015-03-29 00:32 +0100, Timo Rothenpieler wrote: > > Le nonidi 9 germinal, an CCXXIII, wm4 a écrit : > >> amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly > >> valid unix path. Multiple slashes are coalesced into 1. > > > > Just as you say it without realizing it, it is valid but useless. > > While it is useless, for example scripts frequently generate such paths. > Changing the behaviour on valid paths is a bad idea, however useless > they might seem. +1 Alexander pgp8MfGOUjZmv.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sun, 29 Mar 2015 00:20:53 +0100 Nicolas George wrote: > Le nonidi 9 germinal, an CCXXIII, wm4 a écrit : > > amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly > > valid unix path. Multiple slashes are coalesced into 1. > > Just as you say it without realizing it, it is valid but useless. Just because it's useless you can't randomly change its semantics. Or do you want API users being forced to "normalize" paths just so libavformat doesn't mess it up for them? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
> Le nonidi 9 germinal, an CCXXIII, wm4 a écrit : >> amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly >> valid unix path. Multiple slashes are coalesced into 1. > > Just as you say it without realizing it, it is valid but useless. While it is useless, for example scripts frequently generate such paths. Changing the behaviour on valid paths is a bad idea, however useless they might seem. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
Le nonidi 9 germinal, an CCXXIII, wm4 a écrit : > amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly > valid unix path. Multiple slashes are coalesced into 1. Just as you say it without realizing it, it is valid but useless. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sun, 29 Mar 2015 01:12:32 +0200 Ivan Kalvachev wrote: > On 3/28/15, Peter Ross wrote: > > On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote: > >> On Sun, 29 Mar 2015 08:10:29 +1100 > >> Peter Ross wrote: > >> > >> > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > >> > > On 28.03.2015 20:13, Nicolas George wrote: > >> > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > >> > > >>I will try to use this libarchive first and do some tests. Your > >> > > >> approach may > >> > > >>collapse in case compression libraries doesn't support parallel > >> > > >>compression/decompression (I mean that you write or read several > >> > > >> files from > >> > > >>single archive file) I would be much surprised if at least writing > >> > > >> will not > >> > > >>work. > >> > > > > >> > > >This is a likely issue, but fortunately it would not prevent all use > >> > > > cases. > >> > > > > >> > > >>I wonder if there is other solution: zip could be protocol as it is > >> > > >> now, it > >> > > >>allows to benefit from list API and gives flexibility other demuxers > >> > > >> to > >> > > >>benefit from it. There could also be a "directory" demuxer which > >> > > >> would also > >> > > >>use that API and possibly could serve streams in your way. That > >> > > >> demuxer > >> > > >>could also handle directories over any protocol that supports that > >> > > >> API. > >> > > > > >> > > >That was the kind of idea that I had. But I believe that to get that > >> > > > working > >> > > >a bit reliably, we will need to extend the directory listing > >> > > > callbacks to > >> > > >allow a URL context to create new URL contexts, to open remote files > >> > > > without > >> > > >establishing a new connection (and it will also be necessary for > >> > > > network > >> > > >servers). Some kind of VFS API, then. > >> > > >> > Agree. > >> > > >> > > This can be even harder as opening archive file require stat or other > >> > > smart > >> > > way to check some candidates that ought to be a archive file. See > >> > > below. > >> > > >> > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > >> > > >>libzip can't handle it (the same way it cannot handle files via > >> > > >> protocols), > >> > > >>maybe libarchive will be better > >> > > > > >> > > >I think you misunderstood the question. I was not asking whether it > >> > > > would be > >> > > >able to decode nested files, but how your code did split nested > >> > > > paths: would > >> > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > >> > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone > >> > > > was > >> > > >stupid enough to name a directory dot-zip)? > >> > > > >> > > I assumed it is local file (no other option so far). So I stat full > >> > > path > >> > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so > >> > > then I > >> > > opened it as zip file and used fallback to open first file. > >> > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so > >> > > on... > >> > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a > >> > > path > >> > > inside zip. > >> > > >> > walking the path means that the archive protocol must know about the > >> > syntax of the underlying protocol (file, http, ftp, etc.). that seems > >> > messy. > >> > also inefficient if you have got to walk a long ftp path. > >> > > >> > wouldn't we be better off defining a special character that seperates > >> > the zip > >> > path from the inner path. obviously we'd need some way of escaping the > >> > character > >> > if it is legitimately part of either path. > >> > > >> > ffplay /tmp/amovie.zip > >> > ffplay http://subtitles.org/amovie.zip#amovie.srt > >> > > >> > the syntax should support nested archives (even if the libzip/archive > >> > cannot handle > >> > that yet). e.g. > >> > > >> > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt > >> > > >> > -- Peter > >> > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) > >> > >> No. '#' is perfectly allowed in URLs and local filenames. > > > > of course it is, hence my qualification above: > >>> obviously we'd need some way of escaping the character > > > > so if '##' reduces to '#', then: > > ffplay /tmp/amovie##1.zip#amovie##1.srt would open 'amovie#1.srt' inside > > '/tmp/amovie#1.zip' > > > > '#' was only given as an example. > > pick a character (or character sequence) that is easy to type, but > > infrequently used in > > uris/filenames, such to avoid having to escape to often. > > How about: > ffplay /tmp/amovie1.zip//amovie.srt > > Aka, using double directory separator to indicate diving into an archive. > This way "ffplay /tmp/amovie1.zip/amovie" would imply amovie1.zip is > directory. You forgot // in your second example? Anyway, you can name a directory amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly valid unix path. Multiple slashes are coalesced into 1. ___
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 3/28/15, Peter Ross wrote: > On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote: >> On Sun, 29 Mar 2015 08:10:29 +1100 >> Peter Ross wrote: >> >> > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: >> > > On 28.03.2015 20:13, Nicolas George wrote: >> > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : >> > > >>I will try to use this libarchive first and do some tests. Your >> > > >> approach may >> > > >>collapse in case compression libraries doesn't support parallel >> > > >>compression/decompression (I mean that you write or read several >> > > >> files from >> > > >>single archive file) I would be much surprised if at least writing >> > > >> will not >> > > >>work. >> > > > >> > > >This is a likely issue, but fortunately it would not prevent all use >> > > > cases. >> > > > >> > > >>I wonder if there is other solution: zip could be protocol as it is >> > > >> now, it >> > > >>allows to benefit from list API and gives flexibility other demuxers >> > > >> to >> > > >>benefit from it. There could also be a "directory" demuxer which >> > > >> would also >> > > >>use that API and possibly could serve streams in your way. That >> > > >> demuxer >> > > >>could also handle directories over any protocol that supports that >> > > >> API. >> > > > >> > > >That was the kind of idea that I had. But I believe that to get that >> > > > working >> > > >a bit reliably, we will need to extend the directory listing >> > > > callbacks to >> > > >allow a URL context to create new URL contexts, to open remote files >> > > > without >> > > >establishing a new connection (and it will also be necessary for >> > > > network >> > > >servers). Some kind of VFS API, then. >> > >> > Agree. >> > >> > > This can be even harder as opening archive file require stat or other >> > > smart >> > > way to check some candidates that ought to be a archive file. See >> > > below. >> > >> > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin >> > > >>libzip can't handle it (the same way it cannot handle files via >> > > >> protocols), >> > > >>maybe libarchive will be better >> > > > >> > > >I think you misunderstood the question. I was not asking whether it >> > > > would be >> > > >able to decode nested files, but how your code did split nested >> > > > paths: would >> > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or >> > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone >> > > > was >> > > >stupid enough to name a directory dot-zip)? >> > > >> > > I assumed it is local file (no other option so far). So I stat full >> > > path >> > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so >> > > then I >> > > opened it as zip file and used fallback to open first file. >> > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so >> > > on... >> > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a >> > > path >> > > inside zip. >> > >> > walking the path means that the archive protocol must know about the >> > syntax of the underlying protocol (file, http, ftp, etc.). that seems >> > messy. >> > also inefficient if you have got to walk a long ftp path. >> > >> > wouldn't we be better off defining a special character that seperates >> > the zip >> > path from the inner path. obviously we'd need some way of escaping the >> > character >> > if it is legitimately part of either path. >> > >> > ffplay /tmp/amovie.zip >> > ffplay http://subtitles.org/amovie.zip#amovie.srt >> > >> > the syntax should support nested archives (even if the libzip/archive >> > cannot handle >> > that yet). e.g. >> > >> > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt >> > >> > -- Peter >> > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) >> >> No. '#' is perfectly allowed in URLs and local filenames. > > of course it is, hence my qualification above: >>> obviously we'd need some way of escaping the character > > so if '##' reduces to '#', then: > ffplay /tmp/amovie##1.zip#amovie##1.srt would open 'amovie#1.srt' inside > '/tmp/amovie#1.zip' > > '#' was only given as an example. > pick a character (or character sequence) that is easy to type, but > infrequently used in > uris/filenames, such to avoid having to escape to often. How about: ffplay /tmp/amovie1.zip//amovie.srt Aka, using double directory separator to indicate diving into an archive. This way "ffplay /tmp/amovie1.zip/amovie" would imply amovie1.zip is directory. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
W dniu sobota, 28 marca 2015 Peter Ross napisał(a): > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > > I assumed it is local file (no other option so far). So I stat full path > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then > I > > opened it as zip file and used fallback to open first file. > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so > on... > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a path > > inside zip. > > walking the path means that the archive protocol must know about the > syntax of the underlying protocol (file, http, ftp, etc.). that seems > messy. > also inefficient if you have got to walk a long ftp path. I think filesystem looks the same on every server, no matter it is http, ftp or any other server. wouldn't we be better off defining a special character that seperates the > zip > path from the inner path. obviously we'd need some way of escaping the > character > if it is legitimately part of either path. In real life you might assume that archive has extension zip, rar, 7z,... and try to open according to it in first try, if user has archive with "ass" extension in directory called "data.zip" then they have to wait. i really would avoid to escape anything. this is just annoying. i remember i used to escape urls with so many ifs, if file then dont escape, if http then escape, and so on. handling archives with its own escapes is kinda stupid. it would be easier just to add an option to pass inner file. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sun, 29 Mar 2015 08:55:42 +1100 Peter Ross wrote: > On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote: > > On Sun, 29 Mar 2015 08:10:29 +1100 > > Peter Ross wrote: > > > > > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > > > > On 28.03.2015 20:13, Nicolas George wrote: > > > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > > > > >>I will try to use this libarchive first and do some tests. Your > > > > >>approach may > > > > >>collapse in case compression libraries doesn't support parallel > > > > >>compression/decompression (I mean that you write or read several > > > > >>files from > > > > >>single archive file) I would be much surprised if at least writing > > > > >>will not > > > > >>work. > > > > > > > > > >This is a likely issue, but fortunately it would not prevent all use > > > > >cases. > > > > > > > > > >>I wonder if there is other solution: zip could be protocol as it is > > > > >>now, it > > > > >>allows to benefit from list API and gives flexibility other demuxers > > > > >>to > > > > >>benefit from it. There could also be a "directory" demuxer which > > > > >>would also > > > > >>use that API and possibly could serve streams in your way. That > > > > >>demuxer > > > > >>could also handle directories over any protocol that supports that > > > > >>API. > > > > > > > > > >That was the kind of idea that I had. But I believe that to get that > > > > >working > > > > >a bit reliably, we will need to extend the directory listing callbacks > > > > >to > > > > >allow a URL context to create new URL contexts, to open remote files > > > > >without > > > > >establishing a new connection (and it will also be necessary for > > > > >network > > > > >servers). Some kind of VFS API, then. > > > > > > Agree. > > > > > > > This can be even harder as opening archive file require stat or other > > > > smart > > > > way to check some candidates that ought to be a archive file. See below. > > > > > > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > > > > >>libzip can't handle it (the same way it cannot handle files via > > > > >>protocols), > > > > >>maybe libarchive will be better > > > > > > > > > >I think you misunderstood the question. I was not asking whether it > > > > >would be > > > > >able to decode nested files, but how your code did split nested paths: > > > > >would > > > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > > > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was > > > > >stupid enough to name a directory dot-zip)? > > > > > > > > I assumed it is local file (no other option so far). So I stat full path > > > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so > > > > then I > > > > opened it as zip file and used fallback to open first file. > > > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so > > > > on... > > > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a > > > > path > > > > inside zip. > > > > > > walking the path means that the archive protocol must know about the > > > syntax of the underlying protocol (file, http, ftp, etc.). that seems > > > messy. > > > also inefficient if you have got to walk a long ftp path. > > > > > > wouldn't we be better off defining a special character that seperates the > > > zip > > > path from the inner path. obviously we'd need some way of escaping the > > > character > > > if it is legitimately part of either path. > > > > > > ffplay /tmp/amovie.zip > > > ffplay http://subtitles.org/amovie.zip#amovie.srt > > > > > > the syntax should support nested archives (even if the libzip/archive > > > cannot handle > > > that yet). e.g. > > > > > > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt > > > > > > -- Peter > > > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) > > > > No. '#' is perfectly allowed in URLs and local filenames. > > of course it is, hence my qualification above: > >> obviously we'd need some way of escaping the character > > so if '##' reduces to '#', then: > ffplay /tmp/amovie##1.zip#amovie##1.srt would open 'amovie#1.srt' inside > '/tmp/amovie#1.zip' > > '#' was only given as an example. > pick a character (or character sequence) that is easy to type, but > infrequently used in > uris/filenames, such to avoid having to escape to often. > > -- Peter > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) There's no such character - you can _always_ clash with unix filenames. The only way to disambiguate this is using a protocol prefix. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote: > On Sun, 29 Mar 2015 08:10:29 +1100 > Peter Ross wrote: > > > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > > > On 28.03.2015 20:13, Nicolas George wrote: > > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > > > >>I will try to use this libarchive first and do some tests. Your > > > >>approach may > > > >>collapse in case compression libraries doesn't support parallel > > > >>compression/decompression (I mean that you write or read several files > > > >>from > > > >>single archive file) I would be much surprised if at least writing will > > > >>not > > > >>work. > > > > > > > >This is a likely issue, but fortunately it would not prevent all use > > > >cases. > > > > > > > >>I wonder if there is other solution: zip could be protocol as it is > > > >>now, it > > > >>allows to benefit from list API and gives flexibility other demuxers to > > > >>benefit from it. There could also be a "directory" demuxer which would > > > >>also > > > >>use that API and possibly could serve streams in your way. That demuxer > > > >>could also handle directories over any protocol that supports that API. > > > > > > > >That was the kind of idea that I had. But I believe that to get that > > > >working > > > >a bit reliably, we will need to extend the directory listing callbacks to > > > >allow a URL context to create new URL contexts, to open remote files > > > >without > > > >establishing a new connection (and it will also be necessary for network > > > >servers). Some kind of VFS API, then. > > > > Agree. > > > > > This can be even harder as opening archive file require stat or other > > > smart > > > way to check some candidates that ought to be a archive file. See below. > > > > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > > > >>libzip can't handle it (the same way it cannot handle files via > > > >>protocols), > > > >>maybe libarchive will be better > > > > > > > >I think you misunderstood the question. I was not asking whether it > > > >would be > > > >able to decode nested files, but how your code did split nested paths: > > > >would > > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was > > > >stupid enough to name a directory dot-zip)? > > > > > > I assumed it is local file (no other option so far). So I stat full path > > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then I > > > opened it as zip file and used fallback to open first file. > > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so on... > > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a path > > > inside zip. > > > > walking the path means that the archive protocol must know about the > > syntax of the underlying protocol (file, http, ftp, etc.). that seems messy. > > also inefficient if you have got to walk a long ftp path. > > > > wouldn't we be better off defining a special character that seperates the > > zip > > path from the inner path. obviously we'd need some way of escaping the > > character > > if it is legitimately part of either path. > > > > ffplay /tmp/amovie.zip > > ffplay http://subtitles.org/amovie.zip#amovie.srt > > > > the syntax should support nested archives (even if the libzip/archive > > cannot handle > > that yet). e.g. > > > > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt > > > > -- Peter > > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) > > No. '#' is perfectly allowed in URLs and local filenames. of course it is, hence my qualification above: >> obviously we'd need some way of escaping the character so if '##' reduces to '#', then: ffplay /tmp/amovie##1.zip#amovie##1.srt would open 'amovie#1.srt' inside '/tmp/amovie#1.zip' '#' was only given as an example. pick a character (or character sequence) that is easy to type, but infrequently used in uris/filenames, such to avoid having to escape to often. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sun, 29 Mar 2015 08:10:29 +1100 Peter Ross wrote: > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > > On 28.03.2015 20:13, Nicolas George wrote: > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > > >>I will try to use this libarchive first and do some tests. Your approach > > >>may > > >>collapse in case compression libraries doesn't support parallel > > >>compression/decompression (I mean that you write or read several files > > >>from > > >>single archive file) I would be much surprised if at least writing will > > >>not > > >>work. > > > > > >This is a likely issue, but fortunately it would not prevent all use cases. > > > > > >>I wonder if there is other solution: zip could be protocol as it is now, > > >>it > > >>allows to benefit from list API and gives flexibility other demuxers to > > >>benefit from it. There could also be a "directory" demuxer which would > > >>also > > >>use that API and possibly could serve streams in your way. That demuxer > > >>could also handle directories over any protocol that supports that API. > > > > > >That was the kind of idea that I had. But I believe that to get that > > >working > > >a bit reliably, we will need to extend the directory listing callbacks to > > >allow a URL context to create new URL contexts, to open remote files > > >without > > >establishing a new connection (and it will also be necessary for network > > >servers). Some kind of VFS API, then. > > Agree. > > > This can be even harder as opening archive file require stat or other smart > > way to check some candidates that ought to be a archive file. See below. > > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > > >>libzip can't handle it (the same way it cannot handle files via > > >>protocols), > > >>maybe libarchive will be better > > > > > >I think you misunderstood the question. I was not asking whether it would > > >be > > >able to decode nested files, but how your code did split nested paths: > > >would > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was > > >stupid enough to name a directory dot-zip)? > > > > I assumed it is local file (no other option so far). So I stat full path > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then I > > opened it as zip file and used fallback to open first file. > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so on... > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a path > > inside zip. > > walking the path means that the archive protocol must know about the > syntax of the underlying protocol (file, http, ftp, etc.). that seems messy. > also inefficient if you have got to walk a long ftp path. > > wouldn't we be better off defining a special character that seperates the zip > path from the inner path. obviously we'd need some way of escaping the > character > if it is legitimately part of either path. > > ffplay /tmp/amovie.zip > ffplay http://subtitles.org/amovie.zip#amovie.srt > > the syntax should support nested archives (even if the libzip/archive cannot > handle > that yet). e.g. > > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt > > -- Peter > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) No. '#' is perfectly allowed in URLs and local filenames. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > On 28.03.2015 20:13, Nicolas George wrote: > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > >>I will try to use this libarchive first and do some tests. Your approach may > >>collapse in case compression libraries doesn't support parallel > >>compression/decompression (I mean that you write or read several files from > >>single archive file) I would be much surprised if at least writing will not > >>work. > > > >This is a likely issue, but fortunately it would not prevent all use cases. > > > >>I wonder if there is other solution: zip could be protocol as it is now, it > >>allows to benefit from list API and gives flexibility other demuxers to > >>benefit from it. There could also be a "directory" demuxer which would also > >>use that API and possibly could serve streams in your way. That demuxer > >>could also handle directories over any protocol that supports that API. > > > >That was the kind of idea that I had. But I believe that to get that working > >a bit reliably, we will need to extend the directory listing callbacks to > >allow a URL context to create new URL contexts, to open remote files without > >establishing a new connection (and it will also be necessary for network > >servers). Some kind of VFS API, then. Agree. > This can be even harder as opening archive file require stat or other smart > way to check some candidates that ought to be a archive file. See below. > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > >>libzip can't handle it (the same way it cannot handle files via protocols), > >>maybe libarchive will be better > > > >I think you misunderstood the question. I was not asking whether it would be > >able to decode nested files, but how your code did split nested paths: would > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was > >stupid enough to name a directory dot-zip)? > > I assumed it is local file (no other option so far). So I stat full path > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then I > opened it as zip file and used fallback to open first file. > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so on... > /tmp/outer.zip is a file so I open it and treat rest of the uri as a path > inside zip. walking the path means that the archive protocol must know about the syntax of the underlying protocol (file, http, ftp, etc.). that seems messy. also inefficient if you have got to walk a long ftp path. wouldn't we be better off defining a special character that seperates the zip path from the inner path. obviously we'd need some way of escaping the character if it is legitimately part of either path. ffplay /tmp/amovie.zip ffplay http://subtitles.org/amovie.zip#amovie.srt the syntax should support nested archives (even if the libzip/archive cannot handle that yet). e.g. ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 28.03.2015 20:13, Nicolas George wrote: L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : I will try to use this libarchive first and do some tests. Your approach may collapse in case compression libraries doesn't support parallel compression/decompression (I mean that you write or read several files from single archive file) I would be much surprised if at least writing will not work. This is a likely issue, but fortunately it would not prevent all use cases. I wonder if there is other solution: zip could be protocol as it is now, it allows to benefit from list API and gives flexibility other demuxers to benefit from it. There could also be a "directory" demuxer which would also use that API and possibly could serve streams in your way. That demuxer could also handle directories over any protocol that supports that API. That was the kind of idea that I had. But I believe that to get that working a bit reliably, we will need to extend the directory listing callbacks to allow a URL context to create new URL contexts, to open remote files without establishing a new connection (and it will also be necessary for network servers). Some kind of VFS API, then. This can be even harder as opening archive file require stat or other smart way to check some candidates that ought to be a archive file. See below. ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin libzip can't handle it (the same way it cannot handle files via protocols), maybe libarchive will be better I think you misunderstood the question. I was not asking whether it would be able to decode nested files, but how your code did split nested paths: would it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or /tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was stupid enough to name a directory dot-zip)? I assumed it is local file (no other option so far). So I stat full path (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then I opened it as zip file and used fallback to open first file. If not then I stat by path components: /tmp/, /tmp/outer.zip, and so on... /tmp/outer.zip is a file so I open it and treat rest of the uri as a path inside zip. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > I will try to use this libarchive first and do some tests. Your approach may > collapse in case compression libraries doesn't support parallel > compression/decompression (I mean that you write or read several files from > single archive file) I would be much surprised if at least writing will not > work. This is a likely issue, but fortunately it would not prevent all use cases. > I wonder if there is other solution: zip could be protocol as it is now, it > allows to benefit from list API and gives flexibility other demuxers to > benefit from it. There could also be a "directory" demuxer which would also > use that API and possibly could serve streams in your way. That demuxer > could also handle directories over any protocol that supports that API. That was the kind of idea that I had. But I believe that to get that working a bit reliably, we will need to extend the directory listing callbacks to allow a URL context to create new URL contexts, to open remote files without establishing a new connection (and it will also be necessary for network servers). Some kind of VFS API, then. > >ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > libzip can't handle it (the same way it cannot handle files via protocols), > maybe libarchive will be better I think you misunderstood the question. I was not asking whether it would be able to decode nested files, but how your code did split nested paths: would it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or /tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was stupid enough to name a directory dot-zip)? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 28.03.2015 11:53, Nicolas George wrote: Le septidi 7 germinal, an CCXXIII, Lukasz Marek a écrit : But, this time I dont understand you comments, could you elaborate it? What's wrong, what can I do? What I am saying is that there are a lot of different cases where we want to read archives (not only zip, see my previous mail, but that does not matter for now) on the fly with FFmpeg, and I am not sure your proposal is convenient for all these use cases. You implement it as a protocol, to access a single file in the archive. If it was gzip, that would be fine, because it is a stream compression format. In fact, I now realize we should have stackable protocols for all common stream compression tools. But a zip file is not just a compressed stream: it contains structure, several files. In FFmpeg architecture, that may map better to a demuxer: each file as a stream or as an attachment. This is yet another case where the distinction between protocols and formats is not entirely clear. If you think about it, an input protocol is just a demuxer that outputs a single stream of AVMEDIA_TYPE_DATA packets. Of course, for "normal" protocols and formats, like reading a Matroska file from a plain file, the separation makes sense. But with more complex and tied-in protocols and formats, it makes things actually harder. See the RTP issues for example. I have not yet looked closely enough at it, but I suspect the directory listing API that you have just landed may start a bridge between the two: a protocol may no longer be just an API for accessing a single stream but a whole filesystem. Then we can have demuxers that use it. I suppose one of the most pressing tasks would be to have the image2 demuxer use the directory listing API, is it not? I know that line between protocol and format is very thin. I will try to use this libarchive first and do some tests. Your approach may collapse in case compression libraries doesn't support parallel compression/decompression (I mean that you write or read several files from single archive file) I would be much surprised if at least writing will not work. But I will test it, there is no point in guessing here. Of course making it protocol doesn't solve that potential issue, but it may be less confusing for the user. I wonder if there is other solution: zip could be protocol as it is now, it allows to benefit from list API and gives flexibility other demuxers to benefit from it. There could also be a "directory" demuxer which would also use that API and possibly could serve streams in your way. That demuxer could also handle directories over any protocol that supports that API. Personally I don't favor any of the approaches, but if I had to decide then probably a protocol. So my actual proposal about this patch is: keep it near at hand, but not apply it; rather, use it as a work case to see the most we can do with new APIs. (Well, I do not oppose actually applying it. But if so, let us make us very clear that this is something really experimental. Not experimental "it probably works poorly" but experimental "we may change it completely tomorrow because we had another idea, we will not bother AT ALL with compatibility for now".) I have no pressure to merge asap. At least this libarchive is worth to try. I think you misunderstood this. There is no doc, but reading files by index is a fallback when user doesn't specify file explicitly. For example: Thanks for correcting me, I really missed that. ./ffplay zip://zipfile.zip/aaa.avi Ok, but that leads me to another question: what does this do: ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin libzip can't handle it (the same way it cannot handle files via protocols), maybe libarchive will be better ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
Le septidi 7 germinal, an CCXXIII, Lukasz Marek a écrit : > But, this time I dont understand you comments, could you elaborate it? > What's wrong, what can I do? What I am saying is that there are a lot of different cases where we want to read archives (not only zip, see my previous mail, but that does not matter for now) on the fly with FFmpeg, and I am not sure your proposal is convenient for all these use cases. You implement it as a protocol, to access a single file in the archive. If it was gzip, that would be fine, because it is a stream compression format. In fact, I now realize we should have stackable protocols for all common stream compression tools. But a zip file is not just a compressed stream: it contains structure, several files. In FFmpeg architecture, that may map better to a demuxer: each file as a stream or as an attachment. This is yet another case where the distinction between protocols and formats is not entirely clear. If you think about it, an input protocol is just a demuxer that outputs a single stream of AVMEDIA_TYPE_DATA packets. Of course, for "normal" protocols and formats, like reading a Matroska file from a plain file, the separation makes sense. But with more complex and tied-in protocols and formats, it makes things actually harder. See the RTP issues for example. I have not yet looked closely enough at it, but I suspect the directory listing API that you have just landed may start a bridge between the two: a protocol may no longer be just an API for accessing a single stream but a whole filesystem. Then we can have demuxers that use it. I suppose one of the most pressing tasks would be to have the image2 demuxer use the directory listing API, is it not? So my actual proposal about this patch is: keep it near at hand, but not apply it; rather, use it as a work case to see the most we can do with new APIs. (Well, I do not oppose actually applying it. But if so, let us make us very clear that this is something really experimental. Not experimental "it probably works poorly" but experimental "we may change it completely tomorrow because we had another idea, we will not bother AT ALL with compatibility for now".) > I think you misunderstood this. There is no doc, but reading files by index > is a fallback when user doesn't specify file explicitly. For example: Thanks for correcting me, I really missed that. > ./ffplay zip://zipfile.zip/aaa.avi Ok, but that leads me to another question: what does this do: ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin ? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 27.03.2015 15:49, Nicolas George wrote:
Le septidi 7 germinal, an CCXXIII, Lukasz Marek a écrit :
TODO: add doc, update doc/APIChanges, bump minor
This is interesting, but the use case must be considered very carefully,
there are tons of things that can be done with a zip file, even relevant to
FFmpeg:
- demux a bunch of images as a kind of image2 stream;
- present an archive of font files as attachments (with the patch I have not
yet pushed to MPlayer, that means you could use them directly);
- read several files in parallel (with split audio and video for example;
does the zip format allow interleaving);
- etc.
Hi Nicolas, I missed you comment my patches :)
But, this time I dont understand you comments, could you elaborate it?
What's wrong, what can I do?
+{"file_index", "set file index", OFFSET(file_index), AV_OPT_TYPE_INT,
{.i64 = 0}, -1, INT_MAX, D|E },
That is not very user-friendly.
I think you misunderstood this. There is no doc, but reading files by
index is a fallback when user doesn't specify file explicitly. For example:
./ffplay zip://zipfile.zip/aaa.avi
will provide aaa.avi file from zipfile.zip
./ffplay zip://zipfile.zip
will provide first file (with index 0) in zip file
./ffplay -file_index n zip://zipfile.zip
will provide n + 1 (with index n) file in zip file
this might be helpful when user know there is only one file in zip
archive. Yes, it must be documented. Probably it can be even better to
allow provide whitelist/blacklist for filenames.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
Le septidi 7 germinal, an CCXXIII, Lukasz Marek a écrit :
> TODO: add doc, update doc/APIChanges, bump minor
This is interesting, but the use case must be considered very carefully,
there are tons of things that can be done with a zip file, even relevant to
FFmpeg:
- demux a bunch of images as a kind of image2 stream;
- present an archive of font files as attachments (with the patch I have not
yet pushed to MPlayer, that means you could use them directly);
- read several files in parallel (with split audio and video for example;
does the zip format allow interleaving);
- etc.
> +{"file_index", "set file index", OFFSET(file_index), AV_OPT_TYPE_INT,
> {.i64 = 0}, -1, INT_MAX, D|E },
That is not very user-friendly.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf: add zip protocol
TODO: add doc, update doc/APIChanges, bump minor
---
configure| 4 ++
libavformat/Makefile | 2 +
libavformat/allformats.c | 1 +
libavformat/zip.c| 176 +++
4 files changed, 183 insertions(+)
create mode 100644 libavformat/zip.c
diff --git a/configure b/configure
index a96bfb7..a36c357 100755
--- a/configure
+++ b/configure
@@ -275,6 +275,7 @@ External library support:
--disable-sdldisable sdl [autodetect]
--enable-x11grab enable X11 grabbing (legacy) [no]
--disable-xlib disable xlib [autodetect]
+ --enable-libzip enable libzip [no]
--disable-zlib disable zlib [autodetect]
Toolchain options:
@@ -1404,6 +1405,7 @@ EXTERNAL_LIBRARY_LIST="
libxcb_shape
libxcb_xfixes
libxvid
+libzip
libzmq
libzvbi
lzma
@@ -2582,6 +2584,7 @@ udp_protocol_select="network"
udplite_protocol_select="network"
unix_protocol_deps="sys_un_h"
unix_protocol_select="network"
+zip_protocol_deps="zlib"
# filters
amovie_filter_deps="avcodec avformat"
@@ -4963,6 +4966,7 @@ enabled libsmbclient && { use_pkg_config smbclient
libsmbclient.h smbc_init
require smbclient libsmbclient.h smbc_init
-lsmbclient; }
enabled libsoxr && require libsoxr soxr.h soxr_create -lsoxr
enabled libssh&& require_pkg_config libssh libssh/sftp.h sftp_init
+enabled libzip&& require_pkg_config libzip zip.h zip_open
enabled libspeex && require_pkg_config speex speex/speex.h
speex_decoder_init -lspeex
enabled libstagefright_h264 && require_cpp libstagefright_h264
"binder/ProcessState.h media/stagefright/MetaData.h
media/stagefright/MediaBufferGroup.h media/stagefright/MediaDebug.h
media/stagefright/MediaDefs.h
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2118ff2..47d3804 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -522,6 +522,8 @@ OBJS-$(CONFIG_TLS_PROTOCOL) += tls.o
OBJS-$(CONFIG_UDP_PROTOCOL) += udp.o
OBJS-$(CONFIG_UDPLITE_PROTOCOL) += udp.o
OBJS-$(CONFIG_UNIX_PROTOCOL) += unix.o
+OBJS-$(CONFIG_ZIP_PROTOCOL) += zip.o
+
OBJS-$(HAVE_LIBC_MSVCRT) += file_open.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 26ccc27..96fe484 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -379,6 +379,7 @@ void av_register_all(void)
REGISTER_PROTOCOL(UDP, udp);
REGISTER_PROTOCOL(UDPLITE, udplite);
REGISTER_PROTOCOL(UNIX, unix);
+REGISTER_PROTOCOL(ZIP, zip);
/* external libraries */
REGISTER_DEMUXER (LIBGME, libgme);
diff --git a/libavformat/zip.c b/libavformat/zip.c
new file mode 100644
index 000..c9d6679
--- /dev/null
+++ b/libavformat/zip.c
@@ -0,0 +1,176 @@
+/*
+ * Copyright (c) 2015 Lukasz Marek
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include "libavutil/opt.h"
+#include "libavutil/avstring.h"
+#include "avformat.h"
+#include "internal.h"
+#include "url.h"
+
+typedef struct {
+const AVClass *class;
+
+struct zip *z;
+struct zip_file *f;
+
+char *password;
+int file_index;
+int64_t filesize;
+} ZIPContext;
+
+
+static int ffzip_close(URLContext *h)
+{
+ZIPContext *zip = h->priv_data;
+if (zip->f) {
+zip_fclose(zip->f);
+zip->f = NULL;
+}
+if (zip->z) {
+zip_close(zip->z);
+zip->z = NULL;
+}
+return 0;
+}
+
+static int ffzip_split_url(URLContext *h, const char *url, char **file)
+{
+ZIPContext *zip = h->priv_data;
+int ret = 0;
+struct stat st;
+char *filename, *pos;
+
+*file = NULL;
+
+if (strnlen(url, 7) < 7 || !av_strstart(url, "zip://", NULL))
+return AVERROR(EINVAL);
+
+filename = av_strdup(url + 6);
+if (!filename)
+return AVERROR(ENOMEM);
+
+pos = filename;
+while (pos) {
+if (pos != filename)
+*pos = 0;
+if ((stat(filename, &st) == 0) && S_ISREG(st.st_mode)) {
+av_log(h, AV_LOG_DEBUG, "Trying to open file: %s\n", filename);
