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

[Ivan Kalvachev]

On 3/28/15, Peter Ross <pross at xvid.org> wrote:
> On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote:
>> 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.
>
> 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.