[MPlayer-dev-eng] [PATCH] Use unrar for open vobsubs if available

[Michael Niedermayer]

On Tue, Nov 27, 2007 at 04:21:59PM +0100, Diego Biurrun wrote:
> On Tue, Nov 27, 2007 at 08:50:38PM +0800, Ulion wrote:
> > 2007/11/27, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > > On Tue, Nov 27, 2007 at 01:16:16PM +0100, Diego Biurrun wrote:
> > > > On Tue, Nov 27, 2007 at 08:07:59PM +0800, Ulion wrote:
> > > > > 2007/11/27, Diego Biurrun <diego at biurrun.de>:
> > > > > > On Tue, Nov 27, 2007 at 08:35:39AM +0800, Ulion wrote:
> > > > > > > Here's updated patch.
> > > > > >
> > > > > > Will this supersede our included unrarlib?  I sure hope so.  You could
> > > > > > then remove unrarlib first and save yourself from some of the #ifdefs.
> > > > >
> > > > > Maybe not, because indeed the unrarlib can list files  even the file
> > > > > is compressed in rar 3.*
> > > > > So keep them will save some external call to list files in rar, would
> > > > > you think so?
> > > >
> > > > Huh?  The internal unrarlib only supports rar v2, that's its main
> > > > problem...
> > >
> > > I think he means that the RAR format header did not change between v2
> > > and v3, thus the old unrarlib still can give you the list of files in
> > > the archive, it just can't decompress them.
> > > I am not really sure that the header format did not change, since I
> > > thought that around that time header compressions was added, but I may
> > > of course mis-remember.
> > 
> > If even so, current patch code will fallback to use external unrar to
> > list file if unrarlib fail to list. I use unrarlib first since it will
> > probably can list most of current rar files.
> 
> We are having a misunderstanding here.
> 
> What I am trying to say is that external unrar should replace the
> internal unrarlib, not coexist with it.

yes i think so as well, and then we should add support for bzip2, gzip,
and all the other (non exploitable) compressors around :)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20071129/a072339f/attachment.pgp>