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

[Nicolas George]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150328/2285bfbb/attachment.asc>