Re: [Warzone-dev] rpl2avi converter
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? 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? 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). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release
Am Dienstag, 26. August 2008 14:43:28 schrieb Christian Ohm: On Thursday, 12 June 2008 at 23:54, Angus Lees wrote: So .ogg theora/vorbis is a pretty big saving in size. sequences_ogg.zip was generated via my rpl2avi wine program with the original eidos dlls and then reencoded using ffmpeg2theora - if you're interested in the resulting file or any of the pipeline just ask. Do you know how large the intermediate AVIs are? It might be nice to have the raw files somewhere for testing encoding options etc., or reencode when the Theora encoder improvements I mentioned in my last mail are finished. If I recall correctly, the devastation avi I created using Angus' rpl2avi tool was about 500MB. --Devurandom signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] rpl2avi converter
Am Donnerstag, 26. Juni 2008 00:29:50 schrieb Giel van Schijndel: 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? 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? This will work for Windows: mingw32-gcc -o rpl2avi.exe rpl2avi.c -lvfw32 -L. -ldec130 -ledec -lwinsdec -lwinstr (crosscompiled, but the binary will have the abovementioned problem under Wine) 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). I dont object against an import in general, but if we do it, we should figure out what license the code is under, whom it belongs, etc. --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] rpl2avi converter
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
[Warzone-dev] rpl2avi converter
So I figured the best way forward with FMV sequences was to keep the released content, but avoid the unreleased codec130 video codec. Once we aren't keeping the original files, we may as well dump RPL and use a better known format. As a step in that direction, here's a tool that will use the binary dlls to extract RPL content into a standard (uncompressed) AVI file. Compiles against libwine, might even work on windows with a different Makefile. Requires winstr.dll, dec130.dll, edec.dll, winsdec.dll in the same directory as the executable (or in the wine dll search path). streamer.h from original source release is included. This is my first windows code, but it seems to actually work :P Using this, then reencoding the result as a divx AVI file, we can get ~1/3 of the original file size. We can vary that a lot up and down by using various quality tradeoffs / codecs, etc. It'd be kinda neat to use ogg/theora/speex, but I need to find an encoder that works in order to compare sizes/quality. (I've also got a patch to add an RPL demuxer (but not codec130) to mplayer, if anyone is interested. I was going to just forget that experiment and stick with the rpl2avi approach) -- - Gus rpl2avi.tar.gz Description: GNU Zip compressed data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release
On Tue, Aug 26, 2008 at 9:48 PM, Dennis Schridde [EMAIL PROTECTED] wrote: Am Dienstag, 26. August 2008 14:43:28 schrieb Christian Ohm: On Thursday, 12 June 2008 at 23:54, Angus Lees wrote: So .ogg theora/vorbis is a pretty big saving in size. sequences_ogg.zip was generated via my rpl2avi wine program with the original eidos dlls and then reencoded using ffmpeg2theora - if you're interested in the resulting file or any of the pipeline just ask. Do you know how large the intermediate AVIs are? It might be nice to have the raw files somewhere for testing encoding options etc., or reencode when the Theora encoder improvements I mentioned in my last mail are finished. If I recall correctly, the devastation avi I created using Angus' rpl2avi tool was about 500MB. Yes, they're big. It doesn't even RLE encode the video frames - each one is stored totally uncompressed in the avi. If you really want the avis somewhere, I suggest you recreate them from the rpls (I can help with the tools if what I've said already isn't sufficient). -- - Gus ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] rpl2avi converter
On Sat, Jun 21, 2008 at 1:53 AM, Dennis Schridde [EMAIL PROTECTED] wrote: Am Dienstag, 18. März 2008 00:40:24 schrieb Angus Lees: On Thu, Jan 10, 2008 at 5:45 PM, Giel van Schijndel [EMAIL PROTECTED] wrote: At Wed, 19 Apr 2006 16:05:46 +0100 Angus Lees wrote: So I figured the best way forward with FMV sequences was to keep the released content, but avoid the unreleased codec130 video codec. Once we aren't keeping the original files, we may as well dump RPL and use a better known format. As a step in that direction, here's a tool that will use the binary dlls to extract RPL content into a standard (uncompressed) AVI file. Compiles against libwine, might even work on windows with a different Makefile. Requires winstr.dll, dec130.dll, edec.dll, winsdec.dll in the same directory as the executable (or in the wine dll search path). streamer.h from original source release is included. This is my first windows code, but it seems to actually work :P The attached rpl2avi.c mentions GPL - Angus Lees mail-address-here April 2006 as it's licensing header. Which version of the GPL does that mean? Can I use this: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. ?? That is to say, would you agree with attaching the standard GPLv2 boiler plate message to that file (rpl2avi.c) as its license header? (I'm assuming GPLv2 since the GPLv3 didn't exist yet at that point). (digging through old mail) Yes, you can absolutely do whatever you want with the code. Relicense it as you see fit, realising that I'm compiling against the original 'proprietary' streamer.h header and (now) have some adpcm code that I believe came from alsa. I found I had trouble getting the audio to decode correctly for large files (devastation.rpl) - so ended up hacking in my own adpcm code (I just ripped the warzone code in fact). I've attached the hacked up version which you should probably use - I think it has a few other annoyances fixed too. I also have the full set of warzone fmvs cleanly converted to avi/ogg if you just want them. 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 :( 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. 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'. Each frame is stored in the avis totally uncompressed, so yes - they can get big.. In particular, once they fall out of disk cache you might find your disk can't feed the frames quickly enough to avoid skipping during video playback. Not a problem once they're recompressed, of course. -- - Gus ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] rpl2avi converter
On 4/19/06, Angus Lees [EMAIL PROTECTED] wrote: So I figured the best way forward with FMV sequences was to keep the released content, but avoid the unreleased codec130 video codec. Once we aren't keeping the original files, we may as well dump RPL and use a better known format. As a step in that direction, here's a tool that will use the binary dlls to extract RPL content into a standard (uncompressed) AVI file. This is very cool work. One problem is that we have not, strictly speaking, been given permission to distribute the videos. One could argue that they would have released the videos as well, if only they had thought we could have made use of them, but it just so happens they did not, and it seems hard to impossible to arrange such permissions now because the original team and/or rights to the game seems to have been dispersed all over. If someone could manage to track down someone with the authority to release the videos for free distribution, that would be really good. If that turns out to be impossible, I do not know what we can do. We could perhaps announce that we interpret the intention of the GPL release as releasing everything in the Warzone release that we can play without infringing on third-party copyrights or patents. Converting the RPL videos to Theora would cover that. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] rpl2avi converter
On 4/20/06, Christian Vest Hansen [EMAIL PROTECTED] wrote: We could simply make warzone capable of playing theora files, and then just leave it at that.Then anyone willing to distribute the videos, or some other videos forthis purpose, can doso on their own behalf and responsibility. Yes, I guess something like that was what I had in mind. I think there is little (personal) risk of being sued over the videos, since it'd be pretty hard for anyone to demonstrate economic loss at this point - but I understand this project (and others, like Debian) not wanting to ship the video content in any form. Anyway, here's a newer version that flips the video frames (apparently I had them upside down and never noticed..) has much smaller output files (forgot a /8) and hacks around a wine max index size limitation. I've run it across most of the warzone RPL files and the only remaining problem I see (via mplayer on the result) is in a handful of cases the audio goes corrupt about half way through - not sure if that's a code problem or my original RPL files.. Just fyi, my early tests show the original RPL files being comparable to a naive ogg/theora/vorbis version and an avi/mpeg4/mp3 only being ~half that. So it looks like we mightn't actually gain a whole lot in file size, without tweaking the quality way down :( Having seen that, I might actually look harder into supporting the original RPL files directly.. -- - Gus rpl2avi.tar.gz Description: GNU Zip compressed data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release
On Tue, Aug 26, 2008 at 1:43 PM, Christian Ohm [EMAIL PROTECTED] wrote: On Thursday, 12 June 2008 at 23:54, Angus Lees wrote: For reference, a no-fancy-options recompression of the rpl files into ogg ends up at about this resulting size: 187Msequences_ogg.zip 777Msequences_rpl.zip Could you upload the Theora files somewhere? As nobody seems to do anything regarding the videos currently, perhaps I'll have a look into it. Uploading sequences_ogg.zip to gna:warzone/videos/ now. I hope we don't have some kind of disk limit I'm about to abuse :/ Please let me know if you notice any quality problems - I'm not aware of any remaining video or audio problems with the conversion process. So .ogg theora/vorbis is a pretty big saving in size. sequences_ogg.zip was generated via my rpl2avi wine program with the original eidos dlls and then reencoded using ffmpeg2theora - if you're interested in the resulting file or any of the pipeline just ask. Do you know how large the intermediate AVIs are? It might be nice to have the raw files somewhere for testing encoding options etc., or reencode when the Theora encoder improvements I mentioned in my last mail are finished. The uncompressed avis are simply too big (many, many gigabytes - I discarded the intermediate avis during conversion so I don't actually know). I can upload the full set of RPLs as well if you want. I'm happy to reencode the oggs with different options, tools, whatever - just let me know (and feel free to ping alees at google.com if I'm not answering, I check my other accounts less and less often as the email burnout gets worse) -- - Gus ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release
On 6/12/08, Christian Ohm [EMAIL PROTECTED] wrote: On Thursday, 12 June 2008 at 23:54, Angus Lees wrote: My intention with the fmvs originally was to provide a separate 'fmv.wz' which could just be dropped into the right directory - as other's have suggested. Look for the movie and fall back to current behaviour if not found (and when the movie ends). Distros-and-whatever would presumably package it separately, and (when the legal situation was murky) users could choose to download/distribute it themselves. The patch I sent some time ago supported both .ogg and .rpl formats, again my intention being allowing those few people with the original game to use their .rpls (or something) and the rest of us can use .oggs. And the code is structured to allow other formats if something better turns up. Since the reencoded movies are quite a bit smaller and can now definitely be redistributed, the RPL code isn't really needed anymore, I think. For playback I'd prefer using FFMPEG to the OGG libraries directly, since this will make it easier for others to make movies for mods without lossy reencoding into obscure formats. You mean launch a external program to handle this? I am not sure this is the best way to go on all platforms, you would also need some way to make sure each platform has ffmpeg available. Right now, I am playing around with ogg libraries... For reference, a no-fancy-options recompression of the rpl files into ogg ends up at about this resulting size: 187Msequences_ogg.zip 777Msequences_rpl.zip So .ogg theora/vorbis is a pretty big saving in size. sequences_ogg.zip was generated via my rpl2avi wine program with the original eidos dlls and then reencoded using ffmpeg2theora - if you're interested in the resulting file or any of the pipeline just ask. What codec was the intermediate AVI? If it was lossy, the double reencoding degraded the quality/size more than necessary (i.e. with direct encoding to the target format the files could be smaller or of better quality (or even both)). For my experiment into this, I just dumped out each frame, and the sound, and then used ffmpeg to make that into a ogg/theora video. I used a bitrate of 2400K (unsure what I should use), and the results are pretty much what the originals look like. The only other thing I was trying to figure out is, that the original videos are all 320x240 or less. The 'full screen' option renders the video every other scanline. If you know a good way to upscale from 320x240 without big ugly pixelazation, I am all ears. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release
On Thursday, 12 June 2008 at 23:54, Angus Lees wrote: My intention with the fmvs originally was to provide a separate 'fmv.wz' which could just be dropped into the right directory - as other's have suggested. Look for the movie and fall back to current behaviour if not found (and when the movie ends). Distros-and-whatever would presumably package it separately, and (when the legal situation was murky) users could choose to download/distribute it themselves. The patch I sent some time ago supported both .ogg and .rpl formats, again my intention being allowing those few people with the original game to use their .rpls (or something) and the rest of us can use .oggs. And the code is structured to allow other formats if something better turns up. Since the reencoded movies are quite a bit smaller and can now definitely be redistributed, the RPL code isn't really needed anymore, I think. For playback I'd prefer using FFMPEG to the OGG libraries directly, since this will make it easier for others to make movies for mods without lossy reencoding into obscure formats. For reference, a no-fancy-options recompression of the rpl files into ogg ends up at about this resulting size: 187Msequences_ogg.zip 777Msequences_rpl.zip So .ogg theora/vorbis is a pretty big saving in size. sequences_ogg.zip was generated via my rpl2avi wine program with the original eidos dlls and then reencoded using ffmpeg2theora - if you're interested in the resulting file or any of the pipeline just ask. What codec was the intermediate AVI? If it was lossy, the double reencoding degraded the quality/size more than necessary (i.e. with direct encoding to the target format the files could be smaller or of better quality (or even both)). As for the original patch, it was deliberately against 2.0, since I figured that was where the unmodified game was (this may not be the intention anymore however). I tried briefly to port it to svn head, but I don't think I finished the job. I can easily throw what I've got into an svn branch and everyone can hack on it, although there seemed little interest from other developers last time.. I guess because of the uncertainty regarding the movies it never made it into SVN and thus fell by the wayside. My code always had a strange opengl bug I could never track down: after playing an fmv, the closest LOD textures were corrupted. As far as I could work out I was correctly resetting the texture page and other obvious things - I figure I wasn't cleaning up sufficiently after the various YUV opengl shenanigans and I expect someone who actually understands GL would be able to spot it fairly easily. The RPL dec130 decoder also always had some output corruption I could never work out. The ogg/theora decoder works fine though. Oh and I hadn't reverted enough of our hacks to be able to show the windowed research videos again, but that should be quite possible. Is the YUV stuff really necessary? I don't really know the OGG libs, but FFMPEG includes yuv2rgb conversion that could be used as a baseline, and the OpenGL YUV converters as optional optimizations. That also has the advantage of working always (if not that fast, but for the low-res FMVs that shouldn't matter much) - IIRC none of the mplayer OpenGL YUV variants works correctly on my system. -- * dark has changed the topic on channel #debian to: Later tonight: After months of careful refrigeration, Debian 2.0 is finally cool enough to release. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release
On 6/12/08, Angus Lees [EMAIL PROTECTED] wrote: The patch I sent some time ago supported both .ogg and .rpl formats, again my intention being allowing those few people with the original game to use their .rpls (or something) and the rest of us can use .oggs. And the code is structured to allow other formats if something better turns up. I didn't see your patch on the tracker @ GNA, or maybe I am blind? The current ones are from Gerard, and one supports lua which is https://gna.org/patch/?908 and the other one is patch #885. I currently updated #885 for trunk, but it still has some issues. I would like to check out your ogg playback code, and see if it works better. For reference, a no-fancy-options recompression of the rpl files into ogg ends up at about this resulting size: 187Msequences_ogg.zip 777Msequences_rpl.zip So .ogg theora/vorbis is a pretty big saving in size. sequences_ogg.zip was generated via my rpl2avi wine program with the original eidos dlls and then reencoded using ffmpeg2theora - if you're interested in the resulting file or any of the pipeline just ask. I haven't done much with video stuff, but I used ffmpeg with a bitrate of 2400K, and used the 'double sized' video (as in, it skips ever other scanline to make the FMV appear bigger than it is), so while the original FMVs are 320x240 (and some are less than this), the one I converted is 640x480. The issue with the 320x240 is that if we stretch that out to fill the screen, then we get really ugly pixelization. Is there any filter or some other program that we can use to fix this? The original vid I converted from is 30,996,655 bytes (320x240), and the new one is 32,095,488 bytes (640x480). As for the original patch, it was deliberately against 2.0, since I figured that was where the unmodified game was (this may not be the intention anymore however). I tried briefly to port it to svn head, but I don't think I finished the job. I can easily throw what I've got into an svn branch and everyone can hack on it, although there seemed little interest from other developers last time.. My code always had a strange opengl bug I could never track down: after playing an fmv, the closest LOD textures were corrupted. As far as I could work out I was correctly resetting the texture page and other obvious things - I figure I wasn't cleaning up sufficiently after the various YUV opengl shenanigans and I expect someone who actually understands GL would be able to spot it fairly easily. The RPL dec130 decoder also always had some output corruption I could never work out. The ogg/theora decoder works fine though. Oh and I hadn't reverted enough of our hacks to be able to show the windowed research videos again, but that should be quite possible. -- - Gus I rather we just skip the RPL headaches, and just convert them to ogg/theora. Would seem to be the best bet, and less code maintenance. I dunno about our mac friends, and if the RPL playback code is endian safe or not. Actually, I don't even know if the ogg playback code we have on the tracker is endian safe either. Sorry Ari. :( Maybe Jobs will give the devs a few macs so we can test? ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Video support
Fwiw, I've had this code sitting around gathering dust for most of a year now. http://www.inodes.org/~gus/warzone-sequence.patch.gz Its a mostly complete ogg (theora/vorbis) and rpl openal/opengl video player for warzone. The video used to display fine using SDL overlays, but when I moved it to opengl calls I got a bit lost and haven't got it working again :( (I don't know much about opengl and don't really know how to debug it - I'm just copying code from the mplayer gl renderer atm..) Oh and the audio timing seems to be out a bit on the vorbis player but I'm sure thats a simple bug somewhere - I just haven't put the time into tracking it down yet. The patch contains a standalone video player that I've been using to test with (lib/sequence/myplayer). The sequence API is slightly simpler than what was in warzone originally (and you can have multiple sequences playing at once), I haven't adapted the rest of the warzone code to actually use it yet but that will be trivial. I have a few small video glitches in the RPL rendering, I'd be very interested in trading notes with you Constantine to see if we can track that down at all. Early last year somewhere I posted a bit of win32 code that would use the dec130 dlls to convert RPL to uncompressed AVI files (search for 'rpl2avi'). Using that I have all the original content available in both RPL and OGG formats .. Sorry guys, I meant to post this a long time ago.. - Gus On 4/6/07, Constantine Pokrovsky [EMAIL PROTECTED] wrote: On Thu, Apr 05, 2007 at 04:19:33PM -0400, [EMAIL PROTECTED] wrote: On Thu, 05 Apr 2007 07:07:05 -0400 Constantine Pokrovsky [EMAIL PROTECTED] wrote: On Thu, Apr 05, 2007 at 12:15:37PM +0200, Gerard Krol wrote: Constantine Pokrovsky wrote: Hi. I have reversed the video decompressor. Please, give me some information how to implement the rendering mechanism in the best way. I suppose you mean the decoder for the RPL format? That's quite an achievement, but I'm afraid that does not help us in any way. The original video's were not released under the GPL, and we will thus not be adding any support for them. This does not mean we will do entirely without FMV's however, as I am working on a new sequence system that already supports OGG/Theora. This will however only be used to play free (as in freedom) movies. For more information about the FMV's I suggest to take a look at this forum thread: http://wz2100.net/forum/index.php?topic=458.0 - Gerard The game have everything except the video decompressing function and the sequence rendering function, which have to be implemented. The sound works properly. I don't propose to distribute the original video. If you have the original CD's then you can copy the sequences to the data directory and enjoy watching it. I think this is better than nothing. Yes! Excellent work! Can you post code someplace? I think those that do have original CD, then we use your decode code to show movie. If file is not found, then we can use what we have now. Then no have to wait for diff of other version which have video supports from what I am told. Gerard, you have working code for any video? You post that someplace? If yes, then add Constantine Pokrovsky decode code will be easy. If no, then add code to show video will have to be done first. -- Click for free info on associates degrees and make $150K/ year http://tagline.hushmail.com/fc/CAaCXv1JDCUP6eeVOOvtfMr7muRtd20N/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev I'm working on it. The code will be shown, when the job will be done. But I don't think that it will take too much time. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev -- - Gus ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] rpl2avi converter
On Thu, Jan 10, 2008 at 5:45 PM, Giel van Schijndel [EMAIL PROTECTED] wrote:
At Wed, 19 Apr 2006 16:05:46 +0100 Angus Lees wrote:
So I figured the best way forward with FMV sequences was to keep the
released content, but avoid the unreleased codec130 video codec. Once
we aren't keeping the original files, we may as well dump RPL and use a
better known format. As a step in that direction, here's a tool that
will use the binary dlls to extract RPL content into a standard
(uncompressed) AVI file.
Compiles against libwine, might even work on windows with a different
Makefile. Requires winstr.dll, dec130.dll, edec.dll, winsdec.dll in the
same directory as the executable (or in the wine dll search path).
streamer.h from original source release is included.
This is my first windows code, but it seems to actually work :P
The attached rpl2avi.c mentions GPL - Angus Lees mail-address-here
April 2006 as it's licensing header.
Which version of the GPL does that mean? Can I use this:
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
??
That is to say, would you agree with attaching the standard GPLv2 boiler
plate message to that file (rpl2avi.c) as its license header? (I'm
assuming GPLv2 since the GPLv3 didn't exist yet at that point).
(digging through old mail)
Yes, you can absolutely do whatever you want with the code. Relicense it as
you see fit, realising that I'm compiling against the original 'proprietary'
streamer.h header and (now) have some adpcm code that I believe came from
alsa.
I found I had trouble getting the audio to decode correctly for large files
(devastation.rpl) - so ended up hacking in my own adpcm code (I just ripped
the warzone code in fact). I've attached the hacked up version which you
should probably use - I think it has a few other annoyances fixed too.
I also have the full set of warzone fmvs cleanly converted to avi/ogg if you
just want them.
--
- Gus
/* Convert ARMovie/Eidos' Replay (.RPL) file to uncompressed AVI
* GPL - Angus Lees [EMAIL PROTECTED] April 2006
*/
/* There seems to be a bug somewhere in the streamer adpcm decode code
(at least under wine). It throws a whole bunch of '-1's into the
decoded audio stream for long files, which sounds like lots of
static. Work around this by doing the decoding ourselves. */
#define USE_MY_CODE 1
#define WIN32_LEAN_AND_MEAN /* heh */
#include windows.h
#include vfw.h
#include stdlib.h
#include stdio.h
#include errno.h
#include string.h
#include assert.h
#include streamer.h
#define STREAMER_AUDIOOUT_BITSIZE 16 /* streamer always outputs SLE16 */
#ifdef __WINE__
/* This throws a stub warning on wine at present (Wine 0.9.9) */
#define AVIFileExit() do {} while (0)
#endif
#ifdef __WINE__
/* HACK HACK HACK: We need to increase cbIdxRecords to work around an
* index size limitation in current (0.9.12) wine versions */
#define MAX_AVISTREAMS 8
typedef struct _IAVIFileImpl IAVIFileImpl;
typedef struct _EXTRACHUNKS {
LPVOID lp;
DWORD cb;
} EXTRACHUNKS, *LPEXTRACHUNKS;
typedef struct _IPersistFileImpl {
/* IUnknown stuff */
const void *lpVtbl;
/* IPersistFile stuff */
void *paf;
} IPersistFileImpl;
struct _IAVIFileImpl {
/* IUnknown stuff */
const void *lpVtbl;
LONG ref;
/* IAVIFile stuff... */
IPersistFileImpl iPersistFile;
AVIFILEINFOW fInfo;
void *ppStreams[MAX_AVISTREAMS];
EXTRACHUNKS fileextra;
DWORD dwMoviChunkPos; /* some stuff for saving ... */
DWORD dwIdxChunkPos;
DWORD dwNextFramePos;
DWORD dwInitialFrames;
MMCKINFO ckLastRecord;
AVIINDEXENTRY*idxRecords; /* won't be updated while loading */
DWORD nIdxRecords; /* current fill level */
DWORD cbIdxRecords;/* size of idxRecords */
/* IPersistFile stuff ... */
HMMIO hmmio;
LPWSTRszFileName;
UINT uMode;
BOOL fDirty;
};
#endif
static const char *avierror(HRESULT err) {
switch (err) {
case AVIERR_OK: return OK;
case AVIERR_UNSUPPORTED: return UNSUPPORTED;
case AVIERR_BADFORMAT: return BADFORMAT;
case AVIERR_MEMORY: return MEMORY;
case AVIERR_INTERNAL: return INTERNAL;
case AVIERR_BADFLAGS: return BADFLAGS;
case AVIERR_BADPARAM: return BADPARAM;
case AVIERR_BADSIZE: return BADSIZE;
case AVIERR_BADHANDLE: return BADHANDLE;
case AVIERR_FILEREAD: return FILEREAD;
case AVIERR_FILEWRITE: return FILEWRITE;
case AVIERR_FILEOPEN: return FILEOPEN;
case AVIERR_COMPRESSOR: return COMPRESSOR;
case AVIERR_NOCOMPRESSOR: return NOCOMPRESSOR;
case AVIERR_READONLY: return READONLY;
case AVIERR_NODATA: return NODATA;
case AVIERR_BUFFERTOOSMALL: return
