Again: You can choose how fast you want to encode with the "preset" setting.
Never used any Vegas in my life.
VLC should be able to play anything you create without problems, but I don't really know; I don't use it. No idea about MP and QT.
I use the k-lite codec pack which automates the installation of MPCHC and lav filters, among others. It has a lot of options, so maybe KCP is better for you.
h.264 is the video coding format, x264 is a program that creates videos encoded in h.264. It's a command-line program, so you open a console window in the directory where your source files are and write something like
x264 input.avi -o output.mkv --crf 20 --preset fast --tune animation
This would encode "input.avi" into "output.mkv" with a "constant rate factor" quality setting, a "fast" speed setting, and tuned for animation.
x264vfw is the x264 frontend for programs that use the (relatively old) Video for Windows codec interface. It exposes the most important encoding settings of the program in GUI form, but not all.
As you can see above you can choose a speed preset, which selects a trade-off between quality, encoding speed and file size.
With a fixed bitrate (i.e. file size), faster presets will result in worse quality (and vice versa).
With a fixed quality, faster presets will result in larger files (and vice versa).
x264 is in constant development, and usually the fastest encoder when comparing other encoders with similar workloads.
I don't like some aspects in this video...
"The faster it renders, the less compression it's going to use, but it should always come out around the same quality" - This is only true for fixed quality mode - which he doesn't use.
Zero latency is for encoding video on-the-fly, for example a webcam stream that has to go in realtime over the internet; it shouldn't be used for encoding files because it basically uses a faster preset.
Single-pass bitrate is designed for strict file size or data transfer limits. Today we have DSL, USB sticks and terabyte HDDs, so it's usually better to encode at a set quality, of which CRF is the best.
The AVI file format isn't really designed for h.264 content; it's often better to use MKV.
The easiest way to reduce recording load is to reduce the screen resolution.
This might also be an issue with the codecs. If you use one designed for strong compression, it'll use too much CPU time and the actual game slows down. If you use one designed for very light compression, it'll produce large files that might interfere with the game's disk activity or might even max out the computer's hard drive.
Recording a 1280x720 screen at 30fps without any compression at all takes ~80MB/s. Double that for 60fps so you'd need an SSD for that, but a one hour recording would already fill a 256GB drive. So practically speaking you have to use video compression.
There are some options you can select when using x264vfw, e.g. preset=veryfast. There are also fast codecs designed for screen recording, e.g. ZMBV (only with 32-bit colors) and the Camstudio codec.
The most professional solution is a separate PC dedicated to video recording, i.e. with a capture card.
I don't know much about LUA, but you could probably write one function for reading memory and one for writing memory. In these functions you use the actual emulator-specific command for getting/setting the value.
Sounds more like a configuration problem (installed software, settings, etc.) than a hardware problem, unless you have your CPU drastically overclocked...
Maybe this can be fixed by the developers?
More lag in games?
How so? I imagine you need only WRAM most of the time, which is the same as WRAM addresses in other emulators - just subtract 7E0000.
While encoding #4852: julius_x's SNES Yuu Yuu Hakusho (J) "Story Mode any%" in 34:53.05 I noticed that interlaced SNES screens seem to be broken... The game creates 5 files:
#1: 256x224 pixels, 60.0985 fps, framecount=64
#2: 512x448 pixels, 60.0985 fps, framecount=222 (download)
#3: 256x224 pixels, 60.0985 fps, framecount=83202
#4: 512x448 pixels, 60.0985 fps, framecount=6
#5: 256x224 pixels, 60.0985 fps, framecount=~77248 (depends on user)
#2 slowed down looks like this:
Each couple of frames contains the relevant data, but it has to be extracted:
Language: Avisynth
a = SelectEven.SeparateFields.SelectEven # get 1st frame, get even-numbered lines (field)
b = SelectOdd .SeparateFields.SelectEven # get 2nd frame, get even-numbered lines (field)
Interleave(a, b).Weave # interleave fields into full frames
Interleave(last, last) # show each restored frame twice to get 60 fps (compatibility with the rest of the movie)
Result:
Other examples, before (left) and after (right):
Radical Psycho Machine Racing (USA) aka RPM Racing (01020304)
World Class Service Super Nintendo Tester (USA) (0102)
The only problem with these is that for some of them, variables a and b in the Interleave call have to be reversed. Probably depends on which frame the interlaced mode was activated - even or odd.
I can't speak for other consoles, but the SNES's framerate in progressive mode is faster than 60 Hz, so changing it to 60 would benefit in the cases where the monitor runs at <= 60 Hz, even without further correction (e.g. in case of YT videos). If the user has something like ReClock then the video and audio quality wouldn't be affected unless the audio is configured to be resampled (instead of just its sample rate value being adjusted), but this resampling generally shouldn't produce any audible differences.
madvr has a "smooth motion" setting, but I've never used it. It might adjust the video/audio playback rates or create blended frames.