Researching framedumping issues, expectation and potential solutions

[Zexaron]

Not that most issues aren't known to many people, I think it's helpful to write things down and document it incase someone gets interested or the previous maintainers come back, they may have an easier job when we have it all laid out here. 
I'm also relatively new to this code I need to do some prepwork of how this is set up.

First a few links to the existing stuff which may or may not be useful to varying degrees:

• Really old guide thread: https://forums.dolphin-emu.org/Thread-frame-dumping-a-how-to-guide?highlight=framedump 
• Dev1: https://forums.dolphin-emu.org/Thread-enable-dual-core-dump-frames-disaster?highlight=framedump
• Dev2: https://forums.dolphin-emu.org/Thread-getting-visual-output-real-time?highlight=framedump
• .... There's more stuff buy most likely obsolete.
  

The discussion started emerging in a recent thread over in the general section, and I thought that be transferred here, because it was also somewhat offtopic.

https://forums.dolphin-emu.org/Thread-frame-dumping-can-we-have-the-codec-selection-option-back-please?pid=471778



List of facts: (updated periodically - feedback welcome)

• FFmpeg that is included is a custom build configured to a specific feature set by to the person who introduced FFmpeg to Dolphin, it's not the full ffmpeg you normally get from Zeranoe. Not all the custom user options in the ini config would work, that should explain if anyone's seeing settings being "ignored", they don't exist.
• In order to update the existing FFmpeg version while replicating the existing feature set, one needs to set up a FFmpeg build environment and configure it properly and also figure out what exactly is the existing feature set is (I did not manage to find that info as of now). FFmpeg can be updated right now, it's a 5 minute job, but you would be adding +50 megs to the total size of Dolphin's release. https://stackoverflow.com/questions/11701635/use-ffmpeg-in-visual-studio
  
  
  

Analysis and forward thinking:

• Updating the existing version alone, without any changes to the framedumping code will probably not yield many improvements I suspect.
• Improving framedumping might need a different set of ffmpeg features and not some of the existing ones, so it's probably not worthwhile trying to figure out and replicate the existing set exactly. It's probably easier to use the full feature set during development, then downsize.
• Options for container could be limited to the ones which work well and are the most stable, the configurations could be changed to switch-type ones where all the possible options are known to the user ahead of time.
• Another option is to keep the full linking through libs which are provided by Zeranoe, and create a ffmpeg downloader which would only get the full DLLs for those people who would use framedumping this would make it easier to maintain and not necessairly locked to a specific version, the preferred tested version would be used.
  

Directly Relevant Code Files:

• master/Source/Core/VideoCommon/AVIDump.cpp
• master/Source/Core/VideoCommon/RenderBase.cpp
  

[mstreurman]

(05-31-2018, 12:29 PM)Zexaron Wrote: Not that most issues aren't known to many people, I think it's helpful to write things down and document it incase someone gets interested or the previous maintainers come back, they may have an easier job when we have it all laid out here. 
I'm also relatively new to this code I need to do some prepwork of how this is set up.

First a few links to the existing stuff which may or may not be useful to varying degrees:

• Really old guide thread: https://forums.dolphin-emu.org/Thread-frame-dumping-a-how-to-guide?highlight=framedump 
• Dev1: https://forums.dolphin-emu.org/Thread-enable-dual-core-dump-frames-disaster?highlight=framedump
• Dev2: https://forums.dolphin-emu.org/Thread-getting-visual-output-real-time?highlight=framedump
• .... There's more stuff buy most likely obsolete.
  

The discussion started emerging in a recent thread over in the general section, and I thought that be transferred here, because it was also somewhat offtopic.

https://forums.dolphin-emu.org/Thread-frame-dumping-can-we-have-the-codec-selection-option-back-please?pid=471778



List of facts: (updated periodically - feedback welcome)

• FFmpeg that is included is a custom build configured to a specific feature set by to the person who introduced FFmpeg to Dolphin, it's not the full ffmpeg you normally get from Zeranoe. Not all the custom user options in the ini config would work, that should explain if anyone's seeing settings being "ignored", they don't exist.
• In order to update the existing FFmpeg version while replicating the existing feature set, one needs to set up a FFmpeg build environment and configure it properly and also figure out what exactly is the existing feature set is (I did not manage to find that info as of now). FFmpeg can be updated right now, it's a 5 minute job, but you would be adding +50 megs to the total size of Dolphin's release. https://stackoverflow.com/questions/11701635/use-ffmpeg-in-visual-studio
  
  
  

Analysis and forward thinking:

• Updating the existing version alone, without any changes to the framedumping code will probably not yield many improvements I suspect.
• Improving framedumping might need a different set of ffmpeg features and not some of the existing ones, so it's probably not worthwhile trying to figure out and replicate the existing set exactly. It's probably easier to use the full feature set during development, then downsize.
• Options for container could be limited to the ones which work well and are the most stable, the configurations could be changed to switch-type ones where all the possible options are known to the user ahead of time.
  

So you literally gave someone false hope that YOU would fix the issue, when all you are doing is creating a thread in the Developers sub-forum and hope someone else gets interested in this or that the previous maintainers come back... Shame on you.

[Zexaron]

Sorry, I didn't sign any documents, thank you very much. As for your demotivational attempts, or whatever they are, I can guaratee you they won't have any effect.

[Shonumi]

@mstreurman - fwiw, at least getting information, goals, and priorities set around an a specific issue is more than most people are willing to do. We get way too many people casually passing by and saying "XYZ is broke plz fix k?" and expect magic to happen. If someone cares about an issue, really nothing wrong with collecting data/discussion points even if the OP can't solve the issue themselves.

[JosJuice]

(06-01-2018, 01:07 AM)Shonumi Wrote: If someone cares about an issue, really nothing wrong with collecting data/discussion points even if the OP can't solve the issue themselves.

Sure, if that "someone" doesn't happen to be someone who is known to waste the time of developers and come with dubious claims of how things work and what should be done.

[Helios]

Shonumi, Zexaron has a significant reputation of just making a lot of distracting noise that isn't helpful to anything.

That said, not sure why mstreurman is chomping at the bit to get involved in this thread.

[Zexaron]

(06-01-2018, 01:35 AM)Helios Wrote: Shonumi, Zexaron has a significant reputation of just making a lot of distracting noise that isn't helpful to anything.

Which was only that one unlucky period under crazy circumstances and influences half out of my control to do much about it at the time, but technically it would have been possible to avoid, either way it's something I heavily regret and ultimately blame myself. What Helios is referring to happened almost a year ago. Much has changed since. That first impression is now unfortunately lingering over a lot of normal newbie things I say and do, that any other unfamiliar person does to varying degrees in the beginning. So I get, in my opinion, an exaggerated treatment on everything I do, since that event. Because of no prior track record and combined with the unfamiliarity of key systems (git/github/project) added to the bad first impression and created a strong perception in some people's minds that will be difficult if not impossible to fully heal/reverse.

That said, I did try to apologize in the past and will do it again, since it came to this. While things may be more or less true what I'm being accused of in terms of that event a year ago, I can assure you any of that was and anything after was and is not my willing purpose. I was using and being familiar with the project as a normal user for many years before without issues. When I wanted to contribute something I have picked the worst time and conditions and was heavily underestimating the learning curve required to understand the systems needed to contribute. Infact since not being involved for a few months I have reflected back and I genuinely feel bad about causing the interference that slowed down development for a few weeks after that, or so it seemed. I would like to again apologize to everyone involved in that particular PR or two I think, including the the two up here, and especially to Stenzek who got caught up in the crossfire the most I think, while I had many interesting and enjoyable debates for weeks prior. Now I feel like I need to do something to make it up for that, what better way than just some good code.

What is happening since, that no matter how much I indicate that everything I say isn't a strong position/opinion nor I'm trying to force fed it at all by making bold PRs, but only trying give just one out of many other choices to consider to whoever cares, these statements get taken so seriously and the reaction to them is, IMO, exaggerated, and the cause of drama is then put on me. A simple disagreement note/indication would have been enough, even though I never demanded any response.

Ontop, I was not always able to (and sometimes still not) write coherent posts like this and write statements in the perfect english sense, as english isn't my native language, but also for completely dolphin-git-github-code-VS-unrelated reasons which are such a big story I just don't want to get into right now, or else this would have been a wall of text. Even if I would explain it in full, I doubt it would change much with the people who were involved with that event closely at the time in a significant way, because it's again my own problem, they would probably be exhausted from just reading it.

As for framedumping, I am willing to try it myself, I can't make that announcement of a working demo yet, until I actually figure out if I am able to do it. I feel this approach is more appropriate, to not make a promise, rather than draw up hype and fail to deliver. This is a healthier approach to the previous one Helios was referring to, less rush, less stress, everyone will be happier. That's what I thought open-source suppose to be, because you don't get paid with money, you should make sure to get "paid" with enjoyment. I would get enjoyment out of a rookie-like idea of "just merging something", it was a trap, some are unlucky and fall into it in the beginning.

[Zexaron]

Currently, when resizing the render window, framedumping immediately restarts recording to a new file, this keeps happening as the cursor is being dragged, creating a lot of invalid files (too short) in between, I would consider this buggy behavior.

Does anyone disagree this should be fixed to only register a resize when the mouse button is released? If I wouldn't figure out how to do that, I would make a small delay workaround temporairly.

[Jack Frost]

Resolution changes make it a new file; I don't think you can "just" delay in any place and make it work that way.

[JonnyH]

avi (and many other container formats) don't support changing resolution well. And even if the container did, many players fail to support such things properly. If we want it to work on *all* devices, the lowest-common-denominator is to create a new file for every different resolution.

It's a weird enough use case that it isn't likely to be a high priority fix either.