[MPlayer-dev-eng] [PATCH] unrarlib on AMD64
Jindrich Makovicka
makovick at kmlinux.fjfi.cvut.cz
Sun Apr 17 17:35:18 CEST 2005
Rich Felker wrote:
> On Sun, Apr 17, 2005 at 04:37:32PM +0200, Dominik 'Rathann' Mierzejewski wrote:
>
>>On Sunday, 17 April 2005 at 11:37, Jindrich Makovicka wrote:
>>
>>>Rich Felker wrote:
>>>
>>>>>diff -Naur MPlayer-20050416/unrarlib.h MPlayer-20050416-patched/unrarlib.h
>>>>>--- MPlayer-20050416/unrarlib.h 2005-04-15 20:48:03.000000000 +0200
>>>>>+++ MPlayer-20050416-patched/unrarlib.h 2005-04-16 18:17:38.000000000 +0200
>>>>>@@ -97,13 +97,13 @@
>>>>>#ifdef _WIN_32
>>>>>typedef unsigned char UBYTE; /* WIN32 definitions */
>>>>>typedef unsigned short UWORD;
>>>>>-typedef unsigned long UDWORD;
>>>>>+typedef unsigned int UDWORD;
>>>>>#endif
>>>>>
>>>>>#ifdef _UNIX /* LINUX/UNIX definitions */
>>>>>typedef unsigned char UBYTE;
>>>>>typedef unsigned short UWORD;
>>>>>-typedef unsigned long UDWORD;
>>>>>+typedef unsigned int UDWORD;
>>>>>#endif
>>>>
>>>>
>>>>The correct solution is:
>>>>typedef uint32_t UDWORD;
>>>
>>>What about adding an (optional) support for rar executable, instead of
>>>unrarlib? Recent rars cannot be read by unrarlib anyway.
>>
>>Because we strive not to require proprietary libs/tools. Though unrar
>>source is available, the license is not GPL compatible. No rar3 support
>>is planned in unrarlib, so we just have to live with it or write rar3
>>decompression routines ourselves.
>
>
> i propose the latter, and adding rar3 compression routines while we're
> at it. :)
another option is to ditch rar support, import decompression routines
from bzip2 and provide migration scripts :) bzip2 compresses vobsubs
better anyway.
--
Jindrich Makovicka
More information about the MPlayer-dev-eng
mailing list