[FFmpeg-devel] [PATCH] lavf: add zip protocol

wm4 nfxjfg at googlemail.com
Sat Mar 28 22:24:55 CET 2015

On Sun, 29 Mar 2015 08:10:29 +1100
Peter Ross <pross at xvid.org> 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.

More information about the ffmpeg-devel mailing list