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

Lukasz Marek lukasz.m.luki2 at gmail.com
Sat Mar 28 20:38:40 CET 2015


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.



More information about the ffmpeg-devel mailing list