Update FPS to roughly match the actual 3DS rate

[xperia64]

Fixes #4169, #5265, and presumably #4527. Probably other games too.
All fixed with HLE audio only for now; LLE appears to have other bugs.
This doesn't appear to affect/break my other desync fix in #5266

Since the beginning of Citra, the screen refresh rate had a placeholder value of 60Hz. The 3DS screen refresh rate is fairly well known to be roughly 59.83Hz. This is a large enough difference that heavily affects rhythm games.

TODO List for this [WIP] PR:

• Measure the actual hardware frame interval in ARM11 cycles and place that here OR figure out the math behind it: https://github.com/citra-emu/citra/blob/master/src/core/hw/gpu.cpp#L34
• Update https://github.com/citra-emu/citra/blob/master/src/core/hw/gpu.h#L22 to be a function of that interval, and all other places the screen refresh rate matters
• Fix FFmpeg video dumping; It used a hardcoded 60FPS and I'm having trouble making it output 59.83 correctly
• Investigate the impact of this change on things like TAS movies, savestates, etc.
• Verify everything is still fixed after making all of the above changes.

---

This change is 

[ghost]

movies work

[B3n30]

you should probably also update cheats.cpp L17 (and maybe remove the magic number completely)

[oddMLan]

With this pull request there's no more desynching in Ryhthm Heaving Megamix, but there's still some significant input lag. I have to hit the beat slightly early to get it register. Disabling Audio Timestretch helps a little, but it is not enough.

Is there a way to customize the samples length in cubeb? I feel reducing the sample size would help here.

[xperia64]

With this pull request there's no more desynching in Ryhthm Heaving Megamix, but there's still some significant input lag. I have to hit the beat slightly early to get it register. Disabling Audio Timestretch helps a little, but it is not enough.

Is there a way to customize the samples length in cubeb? I feel reducing the sample size would help here.

Is this on Windows or Linux? On Linux I just found the latency fairly high over all, might just be a Linux-specific thing. On Windows, there was a bug that potentially caused the music to be delayed by 1024 samples from the rest of the game and produced a burst of static at the beginning, which is fixed by #5404

[oddMLan]

Is this on Windows or Linux

Windows 10 build 1809. Either way buffer size should be customizable by the user imo.

[xperia64]

Regarding ffmpeg, the problem I thought I saw with it wasn't actually a problem. Despite what ffprobe says on the command line (usually 59.94FPS), the overall averaged framerate is correct. The desync shift I heard when starting recording after booting the game may have been due to the ffmpeg time base not matching 100% or something.

I have updated the ffmpeg numerator and denominator to the obvious solution: frame_ticks and BASE_CLOCK_RATE_ARM11, and the recordings seem to work fine.

As noted in the comments this results in a rather strange timebase of 280071/16756991. Some codecs support this, while others do not. It is technically "correct" as it is now after updating the time base, so to fix the other codecs, resampling the video would be required.

[xperia64]

I have tested most of the video codecs prompted by Citra with the new timebase, and the results are as follows:

Works with the new timebase:

• ffv1
• msjpeg
• msmpeg4
• libvpx
• libvpx-vp9
• libx264
• libx265
• h264_qsv
• mpeg2_qsv
• nvenc
• nvenc_hevc

Breaks with the new timebase:

• mpeg1
• mpeg2
• mpeg4
• libxvid (captures, but the framerate seems wrong)
• libtheora (potentially previously broken)
• mjpeg_qsv (potentially previously broken)

Untested or previously broken:

• All vaapi codecs (no hardware context)
• hevc_qsv (tries to load a nonexistent software plugin on Windows, needs to be told to use a hardware plugin somehow?)
• h264_amf (I don't have an AMD setup at the moment)
• hevc_amf (...)