On Wed, Jun 25, 2008 at 11:29 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> Angus Lees schreef: > > On Sat, Jun 21, 2008 at 1:53 AM, Dennis Schridde <[EMAIL PROTECTED]> > wrote: > >> I get an assert when running this on devastation.rpl via Wine: > >> > >> 022] [1023] [1024] ces/devastation.rpl: avifile.c:1460: > AVIFILE_AddRecord: > >> Assertion `This->nIdxRecords < This->cbIdxRecords/sizeof(AVIINDEXENTRY)' > >> failed. > >> > >> Works "fine" in a VBox though. > >> > >> It creates a huge avi file, which neither xine nor ffplay can play. > (Only > >> mplayer, after complaining a lot.) > >> Additionaly the colours are wrong. red and blue seem to be swapped. > >> On top of that, mplayer claims to have found an audio stream, but does > not > >> playback anything. > > > > I have a long-standing bug report open against wine over their 1024 frame > > limit :( > > Is that a limit of 1024 frames per decoded stream or per what exactly? > There's a 1024 frame limit when writing an AVI using the functions in wine's avifil32. The fix is trivial (adding a realloc instead of an assert), but clearly no-one writes large avis under wine because the bug has sat unaddressed for years, except for people coming along and asking if the bug still exists every year or so. My code works around this if __WINE__ is defined (as it is when compiling with winegcc). There is no 1024 frame limit with this rpl2avi.c under wine, when compiled with winegcc (as the Makefile does). > The code you have should have some #ifdef __WINE__ code that hacks around > > that limit - are you compiling with winegcc or gcc directly? I just > > compiled rpl2avi again from source and managed to convert a 5650 frame > rpl > > with no problems. > > How did you compile this yourself (gcc vs winegcc)? Any specific command > line options you used? > See the Makefile. I typed 'make'. > > To avoid confusion, I've replaced the rpl2avi copies on > > gna with my latest full .tar.gz. Unpack, install wine-dev, make sure the > > rpl/dec130 dlls are in the source directory, type 'make'. > > I think we should import this tool into our Subversion repository to be > able to decently track development (I'm thinking of something like > "trunk/tools/rpl2avi/"). Because obviously a tarball is far from a long > term solution as source code management (it's poor even for short term > IMO). > Sure. License-wise, the streamer.h header file is there unmodified from the original warzone source release and I have some adpcm code lifted from warzone which in turn came from alsa (according to a comment). It requires the proprietary but I believe freely available winstr/dec130 dlls - I think they too were bundled into the original warzone release. Everything else is my code, including the RPL decoder. I donate it to the public domain so we can stop discussing licenses ;) -- - Gus
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
