Post subject: Re: fps and dump time
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
antd wrote:
creaothceann wrote:
Some more stats:
My total dump time differs from your data sheet. I used total frames divided by dump time in seconds to get the fps. So for no capture I did 6801/9.13 = 745. It took 9.13 seconds for no capture.
natt wrote:
Why do you say (lossy?) next to x264. It should be fully lossless just like the others as long as it's being used in RGB mode with no errant colorspace conversions.
Perhaps he didn't know what settings I used. Yeah I used full lossless as you did. ZMBV crashes for me too.
Seems to be a disagreement on whether it's 6801 or 8601 frames
Post subject: Re: fps and dump time
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
natt wrote:
Why do you say (lossy?) next to x264. It should be fully lossless just like the others as long as it's being used in RGB mode with no errant colorspace conversions.
Yeah, wasn't sure what settings antd was using.
antd wrote:
My total dump time differs from your data sheet. I used total frames divided by dump time in seconds to get the fps. So for no capture I did 6801/9.13 = 745. It took 9.13 seconds for no capture.
I'll need to re-order the sheet then, but the values shouldn't change much. The frame count is from the tasvideos page.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Oh! 6801 and 8601 look the same. I must've typoed my calculations :P So yeah, my FPS is incorrect. To get the correct total dump time just divide 6801 by my incorrect fps!
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
So that would be these?
Joined: 3/18/2006
Posts: 971
Location: Great Britain
creaothceann wrote:
So that would be these?
yep, thanks
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
OK, updated the above link with this version. Btw. not that it matters much but... The "uncompressed" data rate might be the max. write speed of the drive you're using (the SSD?). With a virtual RAM drive it might be possible to go even higher, although it looks like the emulator is also at its limit. :)
Post subject: multithread nes
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Hmm, the drive has hit over 300MB/s sequential before. Too bad the emulator can't utilise all 8 cores :P
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I figured out the cause of the bug I was talking about before which causes Camstudio and MLC to lose their settings in some cases. Both codecs use an antiquated API which writes ini files to the windows directory. In Vista\7, this is emulated by the "VirtualStore" feature. For some reason it doesn't work right in this case, but considering the API in use was obsoleted in 1995, I can hardly blame Microsoft for that one. If you're technically inclined, the issue can be worked around by setting up a registry ini redirection as outlined here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms725501.aspx Of course, it doesn't change the fact that MLC is as slow as balls; but it's the best solution for emulators that have buggy 2GB split code. I've created a VFW "codec" that pipes the uncompressed data to the process of your choice, which can then compress it externally. Unlike most things I do, this actually seems to work rather well. Unfortunately, I have nothing to use with it yet: it's apparently quite difficult to properly import lossless RGB x264 into avisynth. FFMS2 gets the colors wrong, and DirectShowSource + LAV filters has seeking problems.
Lex
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Where is this awesome vfw tool? :o
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Didn't think anyone would want it :) http://www.mediafire.com/?b075brb37alpyw5 For the technically experienced only. Any feedback or bug-report is welcome.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Does this help with the Avisynth problem?
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Nope =/ DirectShowSource, any codec: seek inaccuracies AviSource, x264vfw: colors are swapped (can be undone, no biggie), and first few frames of video are trash (not a bframe related problem because bframes=0) AviSource, ffdshow-tryouts: Colors are off a bit (bad PC->TV conversion?) FFMS2: Looks the same as ffdshow-tryouts ffmpeg commandline is fine (it passes MD5 check and everything), but you lose a lot of convenience processing like that
Player (66)
Joined: 4/21/2011
Posts: 232
Fake it with side by side "YV8" for red green and blue?
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Here's a possible fix for my problem: http://forum.doom9.org/showthread.php?p=1559483#post1559483 I don't have time right now to send it through its paces though. And of course it shouldn't be used in a lossless scenario until it's been MD5 verified and whatnots.