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

[Zuxy Meng]

Hi,

2007/11/24, Gianluigi Tiesi <mplayer at netfarm.it>:
> On Sat, Nov 24, 2007 at 07:19:03PM +0800, Ulion wrote:
> > 2007/11/24, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > > Hello,
> > > On Sat, Nov 24, 2007 at 02:50:59PM +0800, Ulion wrote:
> > > > We already discussed the libunrar patch, that was linked to mplayer so
> > > > it's rejected.
> > > > But we can safely use external decompress tool 'unrar' for this purpose.
> > >
> > > Please before writing a patch search the archives carefully, there were
> > > at least three different attempts in the past, we do not need another
> > > flawed implementation of the same thing, we need a proper one.
> > > And honestly a proper solution will most likely have to clean up the
> > > _unspeakable utter and complete mess_ the current code is (the one using
> > > unrarlib, well, actually unrarlib itself probably is a mess as well).
> > > An additional point is that I am not at all too happy about spending
> > > time improving support for a proprietary format, but not
> > > reverse-engineering it but instead jumping through all kinds of hoops
> > > while not supporting any of the opensource compression formats that
> > > would work as well if not better.
> >
> > I'd like say, the unrarlib.c is already there, but it only support rar
> > 2.* files, since rar 3.* it's been 5 years. If we need not this
> > feature, please remove unrarlib.c forever since it's useless. Else
> > make this feature to work with current rar files. unrar is free
> > opensource tool from offical rarlab, but has license conflict with
> > GPL, else libunrar will be a good choice. Then we can still use the
> > binary in this way to do it.
> >
> > Also let's discuss this feature itself -- "open vobsub files from rar
> > file which has same filename part with the media file." Why it's here,
> > in mplayer's svn? Because the .sub file is normally large and can be
> > compressed to save space, specially for dvdrips (dvdrip normally keeps
> > a 700M size per file, to record them in a cd-r with vobsubs, it has to
> > be compressed) and on windows the most popular compress tool winrar
> > was used to compress these .sub files. Why windows? Because most of
> > users in the world is using windows to play videoes. So this is a fact
> > that the rar packaged vobsub files is full of the current world. The
> > question is whether mplayer would to support this feature. From
> > unrarlib.c, I see 'yes' but broken, so I'd like to make it works it in
> > an easy way.
> >
>
> unrar is not opensource, and lib that unpacks rar v3 is not compatible
> with gpl, a borderline for making compatible is make a standalone lib
> __dynamic__ linked and calling a function that does not share
> private data with the lib, so let's say rarunpack(filename, destination)
> clamav has the same problem, they perhaps searching for a solution
> but for sure it's not statically linkable (or add the code inside
> mplayer), the only legal way is calling an external process,
> yes unsure, so I suggest to remove unrarlib.c that at this point
> is useless and make a patch that spawn the unrar process,
> but not apply it to upstream.

If not applicable to upstream, why bother the license issues? RARv2 is
fine, then just keep it. At least existing code provides a good
framework for others to hack in RARv3 support.

> So if the user want to have rar v3 support is he will known
> risks and he need to manually apply the patch
>
> ps: I still don't understand why ppl not switched to 7z

Like I never know why they didn't choose zip at first:-)

-- 
Zuxy
Beauty is truth,
While truth is beauty.
PGP KeyID: E8555ED6