In case anyone is interested; I dumped http://tasvideos.org/966M 3 times with 3 different lossless codecs. In all cases I then verified that the files matched exactly (using ffmpeg's MD5 output). I didn't explicitly measure dumping time; I didn't think of it until it was too late. So you only get approximate numbers for that.
For comparison, I also included x264 in RGB. You can't do this through VFW right now though, so I can't make any direct speed comparison.
Lagarith 1.3.27: 332MiB video size
settings: RGB mode, null frames on, threading on
Dump speed: ~300-400% GBA speed average
Decode speed (FFmpeg md5 output, avisynth avisource): 1865fps
Camstudio 1.4: 196MiB video size
settings: Slow (9), Gzip
Dump speed: ~120% GBA speed average
Decode speed (FFmpeg md5 output, avisynth avisource): 1868fps
MLC 1.1: 51.0MiB video size
settings: slowest, threaded
Dump speed: ~100% GBA speed average
Decode speed (FFmpeg md5 output, avisynth avisource): 500fps
x264 r2146: 58.6MiB video size
settings: --preset veryslow --qp 0
Dump speed: N/A (can't do in emulator directly)
Encode speed (command line): 537fps
Decode speed (FFmpeg md5 output, avisynth FFMS): 1031fps
Notes:
All tests done on a 2500k @4.0ghz
There's also MSU, ffdshow's FFV1 and ffdshow's DV (both in RGB mode).
You could also try compressing a video dump with ZMBV after using ConvertToRGB32.
ZMBV v0.1: 43.5MiB video size
settings: well, there's one slider, but it wouldn't remember its position
dump speed: N/A (only accepts RGB16 or RGB32 as input, and VBA only outputs RGB24 directly)
encode speed: (virtual dub): ~1600fps
decode speed: (FFmpeg md5 output, avisynth source): 2098fps
That's impressive.
ZMBV processes only screen areas that have changed since the last keyframe.
CamStudio and Lagarith always store entire keyframes.
I was more impressed that it achieved better compression than MLC (also a codec with P-frames) while being much, much faster.
It's too bad it doesn't take RGB24 input; I wonder if that's easy to fix...
I should mention Lagarith has the option of adding null frames, saving a ton of space when capturing with .kkapture and emulators like PCSX and Mupen where there are a ton of duplicate frames (50%-75% are dups).
UT Video Codec Suite 10.2.4: 688MiB video size
settings: divide count 4 (default), predict median, RGB mode
Dump speed: ~400-600% GBA speed average
Decode speed (FFmpeg md5 output, avisynth avisource): 1188fps
I'd like to emphasize that this is of course just one synthetic test with one video clip, but there's likely some truth to the trends.
If you'd like to reproduce these results: Dump 966M with a current version of VBA. Stop the avi dump when the frame counter reads 27000 exactly. You can analyze the output with ffmpeg like this:
ffmpeg -i foobar -f rawvideo -pix_fmt rgb24 md5:
The MD5sum should be 9bb67cd3c9cdeed889f9d754e6fc07ce
natt seems to have pretty powerful computer. Both Camstudio (9, GZip) and MLC slow my emulator down ~twice or more.
EDIT: CPU usage with MLC is insane, while it's not noticeable with CamStudio. You should add such info too I think.
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.
natt seems to have pretty powerful computer. Both Camstudio (9, GZip) and MLC slow my emulator down ~twice or more.
EDIT: CPU usage with MLC is insane, while it's not noticeable with CamStudio. You should add such info too I think.
As far as CPU usage goes, I couldn't add it after the fact as I didn't particularly measure it (oops!). What I will say though, is that every single one of these should be pegging a single core if you're dumping at unlimited speed. The ones that do multi-threading internal to the codec are the ones that would be going higher; I believe this includes MLC, lagarith, x264, and UT, but not Camstudio or ZMBV.
creaothceann wrote:
natt wrote:
It's too bad it doesn't take RGB24 input; I wonder if that's easy to fix...
Modifying the emulator is probably easier than getting the codec changed...
Well, apparently the bitstream format supports RGB24. Bisqwit sent over a zmbv codec that supports RGB24, and I have DOSbox's VFW wrapper. I should be able to hack together a working VFW dll out of it that supports RGB24. Judging by the tests so far, it looks like it would be a clear winner for VFW workflow.
Nice. :)
I wonder if there's a codec optimized for dumping - it should spend as few CPU cycles as possible to keep the output data rate just below the drive's write speed, leaving the rest of the CPU time to the emulator. (Or just create enough worker threads to leave one core for the emulator.)
Nice. :)
I wonder if there's a codec optimized for dumping - it should spend as few CPU cycles as possible to keep the output data rate just below the drive's write speed, leaving the rest of the CPU time to the emulator. (Or just create enough worker threads to leave one core for the emulator.)
Obviously such a tradeoff would need to be customizable on a per system basis, because there are different CPU and HDD speeds.
Also, it shouldn't be too hard for even a single threaded emulator to split out the dumping so that the calls to AVIStreamWrite() occur in a separate thread. Little synchronization overhead would be needed (only synchronize ~60 times a second), and you'd get two cores utilized even on a purely singlethreaded emulator and a purely singlethreaded codec.
I've encountered a bug that impacts these tests: Some emulators (not vba23.5 in my tests though), seem to be unable to correctly remember a codec's settings. I suspect it's improper handling of ICM_GETSTATE and ICM_SETSTATE, but I haven't investigated it thoroughly. From what I've seen, this means snes9x, gens, pcejin, and possibly others always compress with default codec settings. This hurts some of the codecs quite a bit (MLC defaults are much faster but much lower compression; Lagarith defaults are singlethreaded and no null-frames).
I've encountered a bug that impacts these tests: Some emulators (not vba23.5 in my tests though), seem to be unable to correctly remember a codec's settings. I suspect it's improper handling of ICM_GETSTATE and ICM_SETSTATE, but I haven't investigated it thoroughly. From what I've seen, this means snes9x, gens, pcejin, and possibly others always compress with default codec settings. This hurts some of the codecs quite a bit (MLC defaults are much faster but much lower compression; Lagarith defaults are singlethreaded and no null-frames).
That's a big find! That's not good if some defaults to colorspace other than RGB, which lucky none do (I think?). Still something isn't right as I know I get NULL frames from Snes9x (or at least I thought I did...).
That's a big find! That's not good if some defaults to colorspace other than RGB, which lucky none do (I think?). Still something isn't right as I know I get NULL frames from Snes9x (or at least I thought I did...).
Indeed. I almost wonder if I'm missing something, or it's a bug only I'm experiencing. Can anyone else confirm/refute this?
Start AVI dumping process in an emu that uses VFW. Get to the codec selection screen. Select Lagarith, Camstudio, or MLC. Hit the "Configure", button, change some settings, and hit "OK". Then hit "Configure" again. Do you see exactly what you just saw before, or have settings reverted?
Start AVI dumping process in an emu that uses VFW. Get to the codec selection screen. Select Lagarith, Camstudio, or MLC. Hit the "Configure", button, change some settings, and hit "OK". Then hit "Configure" again. Do you see exactly what you just saw before, or have settings reverted?
I just went to Snes9x and did that. The settings saved.
Start AVI dumping process in an emu that uses VFW. Get to the codec selection screen. Select Lagarith, Camstudio, or MLC. Hit the "Configure", button, change some settings, and hit "OK". Then hit "Configure" again. Do you see exactly what you just saw before, or have settings reverted?
I just went to Snes9x and did that. The settings saved.
On further inspection, it seems like it only happens with Camstudio and MLC (and possibly ZMBV, but I'm pretty sure its setting slider doesn't do anything at all). I looked at the source code of snes9x vs vba, AVI dumping section, for any differences.. didn't find anything of interest.
/shrug
ffmpeg's lagarith decoder doesn't support null frames. ffmpeg doesn't have an mlc decoder.
For all of these tests, when I say "FFmpeg md5 output, avisynth avisource", I mean that I used an avs file to feed the input to ffmpeg. Just make a one-line avs file with "AVISource (...)" in it and then feed that to ffmpeg. This decodes with the VFW codec itself and not ffmpeg, and matches what you'd be doing in practice for encoding anyway.
Thanks! That's a lot better data than mine. I'm working on getting zmbv working, but am having a weird crash problem...
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.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
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.
link
ZMBV would be nice to compare. :)
Uncompressed's write speed seems off...