When encoding with VirtualDub and x264vfw you probably need to check that "VirtualDub Hack" checkbox. Also, if all you do is upload videos to YT (instead of also storing them), the whole process might be faster to reduce compressing strength if you have a fast internet upload connection.
Can you tell me more about this VirtualDub hack? I didn't check it because I don't know what it does exactly. I hovered my cursor over it and the explanation didn't make much sense to me either.
I don't know much about it, something to do with using VirtualDub + x264 + AVI files. I just have it enabled when encoding via VirtualDub, and disabled when not.
Gamer Maiden Sonia wrote:
creaothceann wrote:
EDIT: Also, always use the "Fast Recompress" option in VirtualDub's "Video" menu unless you use VirtualDub filters.
I use the resize filter to make my videos go full HD though, so I guess I can't use this fast recompress option.
It means that VirtualDub doesn't decode the input video stream but just passes it along to the selected encoder. VirtualDub operates only in RGB colorspace, so if you have a YUV/YV12 source it'd do the conversion which is inherently lossy and takes some CPU processing. With an RGB source there's no quality loss but you'd waste some time routing the data through VirtualDub's processing code.
These days I do all my editing in Avisynth and use VirtualDub only for encoding (if at all), so I just leave that setting on "Fast Recompress". VirtualDubMod allows me to permanently save that setting.
Gamer Maiden Sonia wrote:
Anyway, if I decide to go back to the x264 codec for whatever reason, I was wondering about something. I see there's a commandline window on x264 (as it's shown on the bottom of the second pic of my second post), but I'm bad with this stuff. Can I do what I do on virtualdub through that commandline window alone? I only really do two things on vdub. First I resize to full HD like this:
<img>http://i.imgur.com/rcRMeIN.png</img>
Then I fix the framerate like this:
<img>http://i.imgur.com/jDDcF8w.png</img>
fceux dumps at a weird 60.100 fps for some reason. If I don't fix it, then the audio will be out of sync and YouTube automatically rejects the video file because it doesn't know how to work with decimal values.
So... I was wondering: If possible, what argument values I'd need to write in order to resize to 5x and fix the framerate at the same time?
it'd probably make the .avi dumping process slower, but maybe it'd be worthy it if it means I'd not need to mess around with virtualdub anymore.
x264 is a command-line program: you open a command-line window (e.g. cmd.exe) and type e.g.
x264 --help
to get a bit of help text (there's other options that show more), and e.g.
x264 --crf 24 --preset fast input.avi -o output.mkv
to encode input.avi to output.mkv using Constant Rate Factor 24 at "fast" speed.
Since I'm using Avisynth I just write a simple text file like this:
Language: Avisynth
AVISource("input.avi")
i = 5
PointResize(Width * i, Height * i)
AssumeSampleRate(round(60.0 * FrameRateDenominator / FrameRateNumerator * AudioRate))
AssumeFPS(60)
Result: http://i.imgur.com/Z8dxpXb.png
This slows down the video to 60fps and changes the audio sample frequency accordingly so that both are in sync. Youtube doesn't support >60fps, so it would drop frames until it's <= 60.
(Normal NES, SNES, etc. video is faster than the standard NTSC rate (60.0/1.001 Hz) because they skip displaying one scanline to get progressive instead of interlaced video. Less lines == faster frame rate.)
This text file is saved e.g. as "00.avs" and encoded with VirtualDub + x264vfw (VirtualDub understands Avisynth scripts). I also use a LameMP3 plugin to compress the audio down to 192 kbits/s, because uploading uncompressed audio is just a waste of time imo.
(Note that you can also encode Avisynth scripts using the x264 command-line program, but then you'd have to compress the audio with other tools.)
Have you tested it with and without Zero Latency setting? Afaik it reduces the compression strength in favor for speed, although if you dump too much data per second your storage device (e.g. HDD) might not be able to keep up. Might not be an issue today though.
Gamer Maiden Sonia wrote:
Then I used the same configurations to encode with virtualdub. Except with Placebo as preset instead of Ultrafast. It takes forever to encode, but the final .avi size gets really small so it's worthy it.
When encoding with VirtualDub and x264vfw you probably need to check that "VirtualDub Hack" checkbox. Also, if all you do is upload videos to YT (instead of also storing them), the whole process might be faster to reduce compressing strength if you have a fast internet upload connection.
EDIT: Also, always use the "Fast Recompress" option in VirtualDub's "Video" menu unless you use VirtualDub filters.
Performance core is inaccurate compared to the real SNES, although accurate enough to emulate most games for personal enjoyment.
For TASing and speedrunning use the compatibility core.
I hope we don't need to burn it all down and rebuild just for speed reasons.
I had a look at the source after feos' post, and while I didn't find all these functions (macros?), I saw lots of "hack", "probably shouldn't do it but we do it anyway!" etc. comments. It doesn't really make for an impression of good and stable architecture.
- reading blocks of data: predict it's sequential and read ahead
- loops: predicting that the CPU jumps back to the beginning of the loop
- switches: remember the most-travelled path
while true do
table = joypad.get(1)
if table.Y then
if table.right then memory.writeword(0x7E0E8B, 3) memory.writeword(0x7E0E8D, 2000)
elseif table.left then memory.writeword(0x7E0E8B, -3) memory.writeword(0x7E0E8D, -2000) end
else
if table.right then memory.writeword(0x7E0E8B, 2)
elseif table.left then memory.writeword(0x7E0E8B, -2) end
end
emu.frameadvance()
end
