I have forgotten about the drop frames in YT @ 30 FPS via Masterjun's test. Still, N64 is a somewhat variable frame rate console. Since N64 natively runs at 60 VI/s (I think), keeping it at 60 FPS would be the best bet to make sure all the variable frame rate fits one way or another. I understand that some frames may drop at the 30 FPS lower res, but honestly I'm not a fan of losing quality (force a frame rate in a variable frame rate console) in the higher quality just for lower quality. Again, even though it seems like 99.999999...% of the run is 30 FPS, there may be some parts lower or higher FPS. Basically it averages at 30 FPS.
So normally you would run 2 passes with ExactDedup and then send the timecodes to x264. But in this case you do this instead:
1. Change the AVS:
Language: avisynth
# Comment out original ExactDedup
# ExactDedup(...
#Add AssumeFPS
AssumeFPS(60)
#Add another ExactDedup (both passes) that stores to different files than the original one
ExactDedup(...
2. Create the two new ExactDedup related files (dedup info and timecodes file)
3. Encode to x264 with this new temp timecodes file as well as using the new dedup info file in the AVS
4. Remake the MKV using the timecodes file of the original ExactDedup to get the right times
I should clarify the workaround to the x264 problem. It isn't just using AssumeFPS(60) and not use the timecodes file in x264. It's more like you add AssumeFPS(60), generate a new timecodes file just for x264, and then use that timecodes file with x264. Since the new timecodes file is with the base of 60 FPS instead of 60000/1001, the automatic generation from x264 would not go as crazy number as you see with the problem. Then when you create the MKV, use the original timecodes file, not the one generated with AssumeFPS(60) just for x264.
Okay, I took a look at it. I only found a workaround. Add this to the AVS:
Language: avisynth
AssumeFPS(60, 1)
The fact you changed the framerate slightly for x264.exe doesn't matter because the timecodes file will be used for the real times when you use mkvmerge.exe
Edit: Oops, yea this was the better solution. I brainfarted.
I'm having a bit of difficulty with a video dump, specifically the 10bit MKV encode (the other two worked just fine). When I get to encoding the video, the following error comes up:
Feos said it's likely something to do with Bizhawk's N64 dumping as this is for the Banjo-Kazooie run recently submitted and to ask in IRC. I spoke to Spikestuff who encounted the same problem a while back with a run he encoded which was solved by RGamma. Unfortunately I can't stick around in IRC any longer, so can anyone here offer any insight or solution to the issue?
It's not to do with the dumping but the framerate (I guess you can blame that on the dumping). The fix is to use a FPS that's close enough to it. Right now, how I did that, I forgot, lol. I'll update this in a sec after I remember.
Edit: Use the --timebase param and set it to 100/ 254118000
If it's for YouTube, it would be better to resize to 3584x2688 since color resolution is 1/4 brightness resolution on YouTube (colorspace YUV4:2:0) in which resizing in multiple of non even numbers is not recommended.
Okay, I took a look at it. I only found a workaround. Add this to the AVS:
Language: avisynth
AssumeFPS(60, 1)
The fact you changed the framerate slightly for x264.exe doesn't matter because the timecodes file will be used for the real times when you use mkvmerge.exe
That just means the section where it's getting the auto timecode is not where you cut it.
Edit:
Mind posting the timecode file somewhere and the x264 line used?
Honestly I wouldn't recommend compressing to MP3 to then be recompressed to AAC on YT... WAV while big (for it's time) is small compared to the video, really...
I agree with Warepire. It's not a good idea to put H.264 in AVI as AVI does not support B-Frames natively. Only time where I would think it is somewhat okay is when you are encoding to lossless H.264 where B-Frames don't exist. It work, doesn't mean much as YT probably just hacked in the support (or FFMPEG).
FCEUX dumps at the correct real NES framerate (I think). YouTube should have no problems with it honestly, if it does, something else is wrong. We all use something called AviSynth to do what you do in VDub, then use the command line x264 which is updated and has (a LOT) more options. Honestly H.264 in AVI is an hack and shouldn't be used unless B-Frames are turned off, which would be true if you are using lossless mode.
Edit: My guess is YouTube doesn't like AVI too much. If you encode to MKV, it should support the weird FPS better.
I have an idea for a time improvement.
it may be faster to collect one coin then to collect zero coins if you area already going into subspace.
if you collect a coin, the slots spin immediately and accept input, allowing you to stop in a loser well before starting fanfare ends. i tested this part with arpid fire an drel time play.
the question is which is longer. the detour to collect one coin from subspace or the wait at slots?
Mind doing the work of simplifying it for me to compare easier? =p
Edit: Never mind, I figured it out.
Edit 2: I've compared, and yep, the older way is better. I forgot there are resolutions that would be perfect for 4:3.
Let's take your common NES/SNES resolution of 256x224. Regular 8x in each direction would give you 2048x1792. Keeping vertical resolution would give me a resolution of 2389.333333333333x1792 aspect ratio corrected. Since YUV 4:2:0 in AviSynth requires the resolution be divisible by 4, the closest resolution would be 2388x1792. Going by what I said, with Luma being resized twice, you would first resize the RGB to 1/4 of 2388x1792, which is 1194x896:
Usually aspect ratio corrected encodes were small resolution anyway, so still using point upscaling to an HD size with correct aspect ratio shouldn't look too bad. The only part you need to be careful on is dealing with Luma and Chroma upscale making sure they line up with Chroma being 1/4th the resolution. To do that, I think you would need to point upsacle Luma twice. Once to both Luma and Chroma to a resolution 1/4th your target final resolution, then another upscale on Luma only to the target resolution.