On Sun, 29 Mar 2015 01:12:32 +0200 Ivan Kalvachev <ikalvac...@gmail.com> wrote:
> On 3/28/15, Peter Ross <pr...@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 <pr...@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. You forgot // in your second example? Anyway, you can name a directory amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly valid unix path. Multiple slashes are coalesced into 1. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel