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
