VideoCommon: FrameDump fixes/cleanups.

[jordan-woyak]

Fixed calculation of PTS values.
This should fix: https://bugs.dolphin-emu.org/issues/12228
Warnings are issued on dropped/skipped frames.

Filename of dumped video now includes the GameID and timestamp like our screenshots.
e.g. "G9SE8P_2020-10-22_11-51-30_0.avi"

Dumping previously restarted on resolution change.
It now also restarts on VI refresh-rate change and savestate load.
Note these restarts maintain the original timestamp to help with file organization/splicing.

Eliminated static variables and general cleanup in FrameDump.
Variable renames and minor cleanup of related code in RenderBase.

[ghost]

@vadosnaprimer
@thecoreyburton
Make a test with this and tell us what do you think, it happened to get merged rather quick. However this is not the whole thing, but it's the kinds of stuff I had on my mind as well, namely the filename creation format.
I'll update the progress here #8121 as usual.

[vadosnaprimer]

Maybe it fixes something, but I can't notice any improvements since #8347 (comment) and #8347 (comment) Due to this, I can't test if segmented AV desync is still there.

Filename logic looks good since it won't overwrite the previous dump now (and filename base remains the same across all segments), tho with audio it still will.

[ghost]

Yeah, but it wasn't expected anyway, I was just wondering even tho TAS stuff more special, but this is nonetheless a step in the right direction, eventually, and it's long overdue, but I still have a couple of months of other stuff I have to finish, I'd be back at this right about now, if I wouldn't start a new PC build.

Although I don't exactly understand why you can't test? Surely you didn't figure it all out in less than an hour?
I didn't had a chance to actually figure out what the PTS code changes were, I'm going to take a deeper look later, but perhaps OP can explain.

[vadosnaprimer]

I mean all the initially duplicate frames at frame 0 are missing from the dump, so there's still huge initial AV desync (most apparent with Resident Evil 4), which is why I can't check if it still desyncs further with every new segment dumped (it was desyncing with segmented dumping before frame 0 was broken).

[ghost]

Yar, I wasn't as active/focused during those times when the frame duplication and AV desync PR was going around, I forgot some of it a bit too, so I can't speak specifically right now, just that this PR I think wasn't even meaning to fix any of that, it started as a basic code cleanup with some stuff added. I think you should discuss the details of that overall issue in the #8121 ticket.

[JosJuice]

@altimumdelta #8121 (or any other PR for that matter) is not appropriate to use as a centralized ticket for everything related to frame dumping. If you want something like that, the issue tracker would be much better place, or perhaps the forums. And even then, it is better to file a separate report on the issue tracker for each issue rather than trying to have some kind of frame dumping megaissue, so that it's possible to keep track of what has been fixed and what hasn't.

[ghost]

@JosJuice Right about now is when I started thinking the same thing, you're right, although it would be quite a chore to fill out all these issues into the bug tracker one by one, there has to be like 30 of them, give or take, IMO. I do intend to update that PR with a proper branch eventually, just have to rebase and start over, however yes, I agree, it can't go on forever in terms of size and scope, so the main thing it's meant to be about is the update to the FFmpeg API calls.