Post subject: AVI capturing problems with PCSX-RR
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Hi there. I'm trying to record Dooty's Abe's Oddysee run. At first, everything worked fine and I was able to record the entire run in a few hours' time. Then I realized I had to redo the encode because setting the max FPS to 200 doesn't work very well (it was actually a recommendation from the official guide, but the FMVs were messed up and playing way too fast). So I deleted the files and then went back to try again. I reset the size to 368x240 and 1:1 to get a better image (previously I had tried with 640x480 at 1:1 to be on the safe side, so that I could crop it later), and tried again. However, then suddenly I couldn't record anymore. I don't know why. PCSX just sits there doing nothing while taking up 99% CPU time. It seems to record some blank frames but only a few and very slowly. I went back and changed the settings to 640x480 and 200 FPS but it didn't help. And yes, if I just play back the movie file in PCSX without recording, it works fine. I'm using P.E.Op.S. Soft Driver 1.4, the SCPH1001.bin BIOS and default plugins for everything else. Here's the log from kkapture (ends due to me closing PCSX after a while):
main: initializing...
main: all main components initialized.
main: reading parameter block...
main: initialization done
video: DirectDrawCreate successful
main: video encoder initialized.
video: width/height not divisible by 4, aligning down (1920x1075)
video: capturing at 1920x1072
sound: emulating DirectSound
sound: buffer created
sound: buffer created
sound: play
sound: play
video: capturing at 640x512
avi_vfw: opened video stream at 60.000 fps (6000/100)
avi_vfw: opened audio stream at 44100 hz, 2 channels, 16 bits
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=1)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=2)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=3)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=4)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=5)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=6)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=7)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=8)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=9)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=10)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=11)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=12)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=13)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=14)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=15)
sound: app is hammering dsound GetCurrentPosition, advancing time (frame=16)
main: shutting down...
main: hook thread exiting
timing: 0.18 frames per second on average
avi_vfw: stopped recording
avi_vfw: avifile shutdown complete
main: everything ok, closing log.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Ah, I get it now. The reason why using 200FPS is recommended is because it works, but only with the TAS Soft Graphics Plugin. It doesn't work with P.E.Op.S. Soft Driver (it needs to be used in this case to avoid major graphics glitches). It's simply not possible to set a framerate limit. I guess, since there are so few actual FMVs in this game (only the intro and ending if I'm right, since everything else can be skipped and will be only one frame regardless) I can just record those with the TAS Soft Driver plugin, and then record everything else with P.E.Op.S. since it seems to work for all non-FMV data.
Publisher
Joined: 4/23/2009
Posts: 1283
Couple of suggestions on fixing the FMV. 1. As you already suggested, record the FMV parts with TAS GPU, and everything else with P. E. Op. S. and then splice them together. 2. Try to fix the FMV issue. That is, we probably need to talk on IRC since there is a list of things to test. For example, check to see the GPU reported FPS while recording with .kkapture. 3. Try to use Eternal SPU instead as the sync, which will almost guarantee all the sound is correct. There is the problem of desyncing, so it really depends on if you want to learn how to do this and how bad the desyncing is.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11274
Location: RU
Before we try encoding the new Oddworld run, I ask you guys to discuss the very resync workflow, hopefully we come up with an easier way to handle Eternal SPU capturing. PCSX resync workflow
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11274
Location: RU
On topic. These cutscenes are in fact about 15 fps, and .kkapture speeds them up to 60, ignoring the waits. After all, I dumped the lossless Intro and 3 versions of Ending (any%, 100% and max casualties) at 60 fps, using P.E.Op.S. Soft Driver 1.4 (Abe's Games Fix enabled) and Eternal SPU 1.4. Here they are, for future generations: http://code.google.com/p/feos-tas/downloads/detail?name=Intro%2BAny.7z http://code.google.com/p/feos-tas/downloads/detail?name=100%2BMaxCas.7z
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.