Editor, Emulator Coder, Experienced Forum User, 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
Editor, Emulator Coder, Experienced Forum User, 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.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
ThatGugaWhoPlay wrote:
The 3D Games are upscaled to 1920x1440 or are captured directly in 1920x1440?
There are different opinions on this. For PSX, the currently used emulator (PSXjin), only supports native capture. For N64, you can capture at higher resolutions; some people like it, some people don't. For GC/Wii, there are so few accepted runs that there's no established precedent.
Editor, Emulator Coder, Experienced Forum User, 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
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
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.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I think it's really better to use some sort of quality-based rate control. Exact sizes don't matter, and quality-based control picks up on differences between sources and blending methods.
I'm not familiar with your encoding software so I can't say how best to control it in this respect.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
"For stream", what do you mean?
If youtube, the encode you send it isn't actually streamed; its read and transcoded by them. Their end sets all the streaming parameters. So CBR serves no useful purpose there. You should use VBR with no VBV/HRD limitations.
If _512kb, then yes, the encode is streamed, so technically speaking, you'll gain a bit of speed in seeking to areas that haven't been downloaded yet by setting some reasonable VBV parameters. But this will hurt quality, and I'm not aware of any major complaints about _512kb encodes without VBV limits. Better to leave it off.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
This is an encode of 415M with input display softsubbed onto it (44MB).
http://www.mediafire.com/?epwp69ju01blahl
The softsub track is set to default on, but could easily be set to default off so that the encode would remain vanilla except for people who wanted the subs on.
The input display is not "beautiful" at all. If I develop this further, I'd switch to ASS as it gives you a lot of control over the display that SRT does not.
The filesize difference is negligible: 44646KB vs 44544KB without.
Is this something people are interested in?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Ferret Warlord wrote:
That's a known issue in VBA. Certain frames around loading spots will be held abnormally long. The opening of Daikatana has a frame that lasts at least a second.
Interesting that it's able to maintain audio sync through that. Out of curiosity, is this a recent regression? I don't have any examples handy, but I know in the past when I've obsoleted some old GBA encodes, I was unable to get my replacement encode and the obsolete encode to line up exactly timing-wise.
Ferret Warlord wrote:
Also, the timing of some emulators isn't exactly 60 fps. FCEUX, from my understanding, is a touch faster than that.
The GBA itself is something like 59.7fps, but I guess that's not how VBA treats it.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
jlun2 wrote:
Well, the movie must have input added at the end. Since you can just download the input file, why not check if that certain input is winthin the file, or added later?
Nevermind, I see what you mean. Youtube's timer is glitched up.
Are you so sure it's youtube?
I'm in the process of re-encoding 415M right now. The indicated VBM length in frames is 65215, or 18:06.90 if we assume each frame is exactly 1/60th of a second (and the first frame is at time 0). 18:06.90 is what the site displays for movie length.
But the avi dump from VBA-RR v23.5 svn421 has input stop at frame #65581 at time 18:13.017 (again assuming each frame is exactly 1/60th of a second, as that's what the AVI file that is dumped claims)
Viewing the output files in various viewers, including youtube and JWplayer, gives an end time of approximately 18:15 (expected with +2s from the logo insertion). I'm pretty sure my encodes are frame accurate to the dump and that the various players are all interpreting them correctly.
It seems like the discrepancy here is that the movie file has 65215 frames but the dump by VBA stops at 65581, which I cannot explain directly. Time to look through that source code I guess..
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.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Warp wrote:
We should start TASing PSP games. Those are all 16:9... :P
Are the current-generation consoles the first ones to support 16:9 TVs and monitors (and hence such resolutions)?
No. Both Wii and PS2 support widescreen to some extent, and probably others as well.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
For youtube, it's one of the many options used to fix flicker pattern problems. That sort of thing needs to be handled on a case by case basis; there's no one best blend/decimate.
For all others, encodes should be kept at native framerate.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
"Vanilla" Youtube encode. It's not full HD process (only goes up to 720p) because there are unresolved issues there (if anyone knows how to get hour+ movies to get 1080p and original transcodes, I'm listening). I'm going to upload the translation srt to it later.
http://www.youtube.com/watch?v=KUnxKAaF47w
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Aktan wrote:
natt wrote:
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
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
A few potential screenshots
http://www.mediafire.com/?bj3o1d7qsvmd7f1
I have the lossless still on my HDD at the moment, so if anyone has any particular screen shot in mind, I can produce the top quality version.
I didn't do a youtube because every attempt I've made to make a ~1hr or longer youtube in HD has failed to process.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Aktan wrote:
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?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
creaothceann wrote:
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).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
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.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
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
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
creaothceann wrote:
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...
