Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with dumping video and audio #10632

Closed
InfamousKnight opened this issue Feb 20, 2018 · 5 comments · Fixed by #12069
Closed

Issues with dumping video and audio #10632

InfamousKnight opened this issue Feb 20, 2018 · 5 comments · Fixed by #12069

Comments

@InfamousKnight
Copy link

What happens?
Some games work well and others act differently.

For instance: midnight club la remix works like a charm

And then other games that work odd: burnout legends, it won’t record video until an event begins I.e. race. Audio is recorded just fine

Star Wars battlefront ii: there seems to be some hiccups in the video. The audio still syncs with video, so there’s some hicccups there too

Final fantasy iv the complete collection acts strange too. When you load a save state, it doesn’t seem to renew the video part(from what I remember)

@FlatOutPS2
Copy link

I recently had a similar issue with Burnout Legends. The dumping didn't work at 30 FPS, but after I applied the 60 FPS patch it did work. After trying another 30 FPS game I noticed the same issue, while a native 60 FPS game was fine. It could be a coincidence, but it definitely suggests that lower framerates cause dumping issues.

@InfamousKnight
Copy link
Author

60 frames per second patch fixed burnout legends? How is that done?

@LunaMoo
Copy link
Collaborator

LunaMoo commented May 27, 2019

So basically to sum this issue up, doesn't matter what framerate game runs, video records with the hardcoded 60000/1001 causing various weird stuff if the game doesn't actually feed those frames.

@unknownbrackets
Copy link
Collaborator

Hm. Thing is, the PSP doesn't actually have the ability to display at less than 59.97 FPS. It will simply display whatever is in VRAM at the display address every frame, no matter what speed the game renders at.

Of course, if the user selects "skip buffer effects" we won't emulate double buffering in games, and might have a broken frame. But if they don't, GPU_DBG_FRAMEBUF_DISPLAY should in theory only select the same framebuffer that the PSP hardware would display.

It sounds like this means there's a bug in that, i.e. it's sometimes using the latched framebuf?

-[Unknown]

@LunaMoo
Copy link
Collaborator

LunaMoo commented Jun 3, 2019

GPU_DBG_FRAMEBUF_DISPLAY via it's description is the current display target, which doesn't equal to the displayed screen, so maybe it's not exactly a bug.

I fixed the video recording by using output buffer and I think we still should at least have an option to record display with post process shaders, but as far as I tested now using render buffer also solves this issue, one downside - video will be in as huge resolution as the user selects and that becomes really slow really quickly.
But at last it works better in software rendering and doesn't have the issue the output buffer had when recording that Darkstalkers game. I think I'll change my pull request to solve it via render buffer, but provide an option to record output buffer.

Edit: blah, render buffer has some problems as well, in MGS:PW recorded width was 512 at x1 res, resulting in extra stuff being recorded outside of what user should see. Would be enough to crop the video later in some editing software, but it's bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants