Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
inavojo wrote:
This is what I am attempting to do. Please note that I am not looking to start my own tool - assisted speedruns. I am looking to replicate the aforementioned effect for my Let's Plays. They will be uploaded onto YouTube.
From this point, please take into consideration the following:
- I am attempting to encode an .avi recording from FCEUX (version 2.2.1).
- I am looking to encode this video to 1080p HD, if possible (720p, if not).
- I am using the built - in .avi recording feature of the FCEUX emulator.
- I have modified FCEUX as specifically recommended by the Encoding Guide (this includes using the Lagarith Lossless Codec, and its own appropriate configurations).
- I am using x264 (64 - bit) with VirtualDub (64 - bit).
To get maximal quality on Youtube, you should use point scaling by even factor so that width is greater than 1920 or height is greater than 1080.
For NES, which is 256x224, the smallest factor that works is 6 (1536x1344). However, due to how x264 works, using 8 (2048x1796) results in smaller filesize.
Also, lowering the CRF value produces better quality at expense of larger file size.
Regarding audio. Use Vorbis at high quality settings (at least 7) or uncompressed PCM. Beware that Youtube has had bugs in handling FLAC (specifically, parts of audio would go missing).
And if you want good quality, stay away from normal video editors. Those do who knows what to the video (and resaving the video after editing can lose a lot of quality).
... Of course "quality" here is relative. You can't get very good quality on Youtube. And also perennial problem is that youtube supports maximum of 30fps, and many games have effects that have frequencies above 15Hz and thus are not representable without higher framerate (by Nyquist sampling theorem).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Frame advance is very useful. But it requires an extra key, and some 3-key combinations don't work on keyboard ("blocking").
If one hits those, the ways to work around it are:
- Change the key bindings so one doesn't need to input something that doesn't work.
- Use a gamepad. Those are pretty much immune to blocking.
- Use TAS input plugin or something.
As for lag, watching the lag counter should tell if there are lag frames.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Warepire wrote:
If a moderator could edit my opening post to say that the data gathering is completed it would be much appreciated, I don't have the rights to edit it anymore...
Okay, done.
Also, looks like the data is in pretty standard format, aside from I18N of axis/button names (and sometimes varying button count)... Good thing, isn't it?
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Omnigamer wrote:
My main question from this is: is this the expected behavior for a STY in 8-bit mode? Does it always store 16 bits regardless of the processor mode?
AFAIK, it stores 8 bits if:
- In emulation mode (E flag is set) or
- mode with 8-bit index registers (X flag set).
If in native mode (E flag is clear) with 16-bit indices (X flag is clear), it stores 16 bits.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Cosmic wrote:
Oh thanks for bringing that up, DTK ?
Disk TracK player. Kinda like CD Digital Audio.
Cosmic wrote:
So nobody can have a stable and "complete" version of RE running to read the inputs for now ?
It just means that further hacking of Dolphin would be required to successfully encode the run (not that big deal, considering that substantial hacking is already needed to encode any run).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Just as a reminder:
* The current dolphin video dump in stock builds is utter garbage. You will get massive A/V desync.
* This game uses DTK, so even the current hacked builds can't dump the music.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
the_randomizer wrote:
Huh, I wonder why there are sync issues, too bad there was never a 1.52 for re-recording.
There is snes9x-rr 1.52. Maybe it has some issues that make it unsuitable for most stuff, don't know as I have never used it.
AFAICT, 1.53 rerecording version doesn't exist (yes, the mainline has rerecording, but lacks many tools).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Spikestuff wrote:
Encoders: override_screenshot (NO)
Can you explain it from:
"Screenshots normally must be smaller than 45000 bytes and match the *normal resolution(s) for a system; with this permission those checks are ignored."
Because editing_moviefiles says:
"Movie files include the video file torrent, any mirror/streaming links, and the screenshot."
If you don't have override_screenshot, then any screenshot you add must be at most 45,000 bytes in size, and must have resolution among approved ones for the system (e.g. 320x240 or 384x216 for GC).
See Wiki: EncoderGuidelines for full list of platforms and the screenshot resolutions allowed for each.
If you have override_screenshot, then you can add screenshot of any size and resolution.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
feos wrote:
Would we be aiming for reducing its size then, since for now I only apply slight compression to it to save on encoding time, as it is only a stream?
Seeing how light the settings are, differences to settings I use for one random primary:
Motion estimation: umh-24 vs. umh-64
subme: 10 vs 11.
Threads: 3 vs 2.
Lookahead_threads: N/A vs 1.
Keyint: 600 vs. 250.
rc_lookahead: 60 vs 250.
So in summary, those settings don't look that light... Hmm... Need to test effects (time / filesize) for subme (10 and 11) and rc-lookahead[1].
[1] Some documentation I have read says that high rc-lookahead has very little effect (unless in 1-pass bitrate) and can actually be harmful.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
feos wrote:
Reading this thread I realize that we can not stop making 8-bit encodes for now. As for switching from one to another as a primary, I don't see how the either way is better because it would only change the order in the publication module.
I think the idea was to drop current primary and make new primary to be identical to current 10bit444. So one less encode class to do.
Then if compatibility encode is needed, the 512kb cound be used for that purpose. Additionally, 512kb is MP4 and is CFR, which should make it even more compatible.
Of course, that doesn't help with crap players like QuickTime. Even 512kb looks hilariously broken.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
creaothceann wrote:
I think you can combine several video, audio and subtitle files into one MKV file that has one video, audio and subtitle stream.
Yes, but for single audio stream, encoding it in parts does not work properly (it does work for video but not audio).
So for variable-quality audio track, you need audio encoder with support for that (decoders are no problem for thiscase).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
True wrote:
but what is the intent?
Knowing what kind of bitrates to use when encoding.
Even if no program supports it presently, writing an encoder with supports for zones-like (variable bitrate target) behaviour wouldn't be too hard...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
CoolKirby wrote:
Why is this being published to the Vault?
Most probably: There was a site bug (now fixed) that caused movies to incorrectly default to Vault (instead of defaulting to N/A) and the judge didn't remember to change the value...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Names wrote:
How do I make the window bigger?
rr1: Configure -> Configure Emulator ... -> Scaling
rr2: Configure -> Settings -> Video...
From there one can control horizontal and vertical scale factors, scaling algorithm and screen rotation.
This can also be used to make the screen smaller. Useful if core wants to output at huge resolution...
mklip2001 wrote:
* enabling turbo mode for playback
1) Speed -> Turbo
2) Bind Speed -> Turbo hold / Turbo toggle hotkeys.
The turbo hold turboes when held, turbo toggle toggles between turbo and normal.
mklip2001 wrote:
* hiding all the diagnostic info on the right side of the program during playback
Configure -> Show status planel.
mklip2001 wrote:
* changing the default directories for storing ROMs and movie files
rr1: Configure -> Configure Emulator ... -> Advanced
rr2: Configure -> Settings -> Advanced...
The various Path settings there.
