Dolphin, the GameCube and Wii emulator - Forums

Full Version: Researching framedumping issues, expectation and potential solutions
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
(06-01-2018, 06:46 AM)Jack Frost Wrote: [ -> ]Resolution changes make it a new file; I don't think you can "just" delay in any place and make it work that way.

Hmm, putting a thread sleep just before line 461 when it's suppose to start again didn't do what I thought it would, weird behavior resulted.

(06-01-2018, 07:25 AM)JonnyH Wrote: [ -> ]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.

Oh that, that would be a bad idea to try to attempt yes. But this is while you drag mouse which keeps changing the window, it makes a string of new framedump videos with a few frames in lenght, until you stop dragging, it's video 9 or more, depending on how long it takes you to adjust the window, I tried to delay the restart command it so you would restart after the user let go of the window, like 3 or 5 seconds, but I didn't made it to work yet. This probably isn't a problem with switch to fullscreen and out, becuase it's just one change, but didn't confirm that yet.

So yes it's proper that it does a new video file, but not so many of broken ones in between.
(06-01-2018, 01:13 AM)JosJuice Wrote: [ -> ]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.

(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.

Yeah, I'm aware of all the drama recently. I'm just saying that this thread (at least the first post) is in and of itself relatively harmless and not actively pestering anyone. It's just trying to act as a repository of info on an issue. Whether the rest of this thread remains productive, well, we'll see...
What is the stance on framedumping while recording a TAS movie at the same time, is it a strong goal?

I myself can only really make things for Windows anyway. I've had Linux Mint off/on many times and still do, but that experienced that I could promise anything right now.

What about FFmpeg version, I would target 4.0 minimum for all OS if I could get away with it, but at least to get stuff like this avoided. Should an upgrade be developed more standard and hope it works on most OS or more developer-OS-specific from the get go in the sense that what for example I know best (windows) potentially leaving some things unimplemented in other OS. So it's a question what do you guys prefer, to make it work on one platform really good but other's pending support, or try to do all at once. Maybe I'm complicating things too much again but oh well.

Thinking ahead, I understand right now probably not half of the linux distros moved to 4.0 yet, and probably don't plan to until next major releases, unrelatedly however, Handbrake did took the just for example.

I got some suggestions that GPU accelerated codecs could be tried in order to offload the processing off the CPU, but it doesn't make sense how some kind of lossless or very small compression would make slowdowns that were reported (probably more specific cases)
For HWAccell a 4.0 ffmpeg would definitely be a good idea.
(06-02-2018, 09:52 AM)Zexaron Wrote: [ -> ]What is the stance on framedumping while recording a TAS movie at the same time, is it a strong goal?

Frame dumping while playing back a TAS movie is a very strong goal. Frame dumping when recording a TAS movie isn't very important, though as long as the user isn't using savestates, I don't see why this should be harder to support.
I thought it would be first good to update ffmpeg to 4.0 full version. In the beginning I've took upon myself to assume that shipping the extra 50 Megabytes for everyone won't be acceptable, so I got into the making it optional route, which is what took most of the time. It would require only those who want to dump frames to manually download FFmpeg shared DLLs separately. However I thought that wouldn't be good enough for best UX so I started out with an integrated FFmpeg auto-download-installer to remedy the biggest possible blocker of this change.

Unfortunately it looks like doing a downloader isn't that easy as I thought, it might take me quite some time myself, and dealing with non-admin stuff, even if I took a look at the auto-updater code, it's quite different.

Instead, I added a detailed instructions when Framedumping wouldn't be able to be enabled because of the missing DLLs, but it also acts as a vital check to prevent the crash, at the end I was also thinking about hyperlink but it I just had to chose one thing of clipboard copy for now, the whole warning message has gone over like at least 30 variations and this isn't the only worded one I had in mind.

If an integrated dl-installer is a must for this, this thing would probably need to sit for months or more as I can't guarantee doing the integrated download-installer myself.

https://github.com/dolphin-emu/dolphin/pull/7110

Here's some more reasons why I took this approach:

It's just not possible to predict ahead what exactly is the feature set once the improvements are finished, it's a no-brainer that any improvement would be started from the full feature set and only then possibly lowering the footprint by removing unnecessary features, if integration would still be deisrable method, but the fullly featured build could be temporairly made available pretty much right now so that at least some could use other codecs of their liking. Any changes of the framedumping code, codecs, formats, won't affect the ffmpeg it self, so the users won't need to redownload anything, except if a higher version is required.

Secondly, this is only Windows, other OSes aren't affected by this change, and they already had to figure out FFmpeg on their own. Thirdly, framedumping isn't exactly something that the majority of users heavily rely on, right? The ones that want it would surely not have a problem installing a few DLLs seprately right.

Fourthly, this doesn't have to be a permanent change, after framedumping improvements (which ever codec/format or two would become default) and several codecs that make sense or are requested are identified, then someone could do their won custom build of FFmpeg with a custom feature set that would lower the size footprint and may be acceptable to add in as per standard, however I can't predict what the size would then be, then it's another dillema if it would really be that much lower to warrant all the extra effort, because you'd end up with more than 5 codecs give or take.

(05-30-2018, 07:33 PM)fintogive Wrote: [ -> ]The avi container is fine.  i honestly dont care as long as i can use any codec preferably lagarith lossless codec at 4k resolutions.

Thank you for looking in to this btw!  much appreciated!

Unfortunately lagarith is not supported by FFmpeg as an encoder, only decoder. No high chances special support would be added, AFAIK it's unmaintained since 2011 and may not even work on Win10.
Since framedumping ffmpeg video is separate from dumping audio ... probably because of technical limitation, would trying to combine it be worthwhile ?

Combining it with an external program might not be the big deal but what about A/V sync, has that been an issue ? Would it be correct for a few minutes then out of sync after a while ?

-------------

Now I figured out it the video frame dumping is suppose to combine the images with fixed frame rate, it's not trying to make a VFR type video, as someone who wasn't familiar was speculating, that is good and means less work potentially.
Pages: 1 2