-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Keep separate track of ffmpeg pos and decode pos #7635
Conversation
FFmpeg buffers, so forcing the pos only makes FFmpeg read in garbage because it doesn't know that you seeked in the bytestream on it.
Great,fixes #7633 |
Urakata Hakuouki lose BGM,before was fine. |
Seems like there is a problem with atrac3 stereo/mono audio (low level) |
Since in this case we're tricking it into reading the same buffer area.
Okay, right, overriding the seek position is intentional for low level. Should work now. Does Urakata Hakuouki also use low level audio, or what does it use? -[Unknown] |
Yes,Urakata Hakuouki works now. |
Fixes the bgm in #6963 ,This is very old issue. |
Fixes silent bgm in Capcom Classics Collection Remixed |
So this PR basically fixes all the audio problems in games? Is there any game that will stil have audio problems after this PR? |
Surely there are other games which have audio problems, many of the sceAtrac functions still behave incorrectly. This just fixes a number of issues. Progress is good. -[Unknown] |
Ah, this makes sense, good call! |
Keep separate track of ffmpeg pos and decode pos
The radio in GTA did not work sometime. |
Hmm, did it always work before? Does it still give invalid data sometimes? I thought it did that before too. -[Unknown] |
It seems always works before,not just the radio,the title bgm also got the following error sometimes.What invalid data? I don't see it.
|
bebbb1b7 is FFmpeg's code for "invalid data". It means the bytes in the atrac3 stream are wrong. For example, it could mean we're telling the game to write data to the wrong place or anything. Somehow it's constructing a bad atrac3 stream. -[Unknown] |
I see. |
Does it happen if you save a state after resetting, quit PPSSPP, start again and load that state? Or also not then, and still requires the reset? -[Unknown] |
save a state after resetting,quit or not quit,it got the error after loading the state. |
Neat, let's compare the savestates. In Common/ChunkFile.cpp, find this line: bool compress = true; And make it: bool compress = false; Then make both savestates again. This just makes it easier to compare them, since you'll be looking at raw data. Then you can compare them. Here's a program to compare two binary files: Every section has a marker and the name near it, so the difference should be between two markers, which will tell us what data it is. Really, a savestate before and after a reset should be identical EXCEPT for the rtc timestamp. Or if you just want to upload the two savestates I can compare them, just thought you might be interested in trying it. -[Unknown] |
ULJM05297_1.01_2 is before resetting ULJM05297_1.01_3 is after resetting savestate download |
Hmm, it just says it can't scan for viruses and won't let me download. You're looking for the red sections, and the text around the red sections. If you pass one, you can just hit q to start over. -[Unknown] |
Hmm, that looks like PSP ram, I'm not sure why it's affected by reset. Does turning off jit and replacements affect it at all? -[Unknown] |
Turning off jit and replacements is not affected. |
FFmpeg buffers, so forcing the pos only makes FFmpeg read in garbage because it doesn't know that you seeked in the bytestream on it.
The code before was basically overwriting the seek pos after FFmpeg read it, and so when FFmpeg tried to continue reading, it ended up reading in a different place than it was aware of. The old method of force seeking all the time (which causes early packets to get scrambled or something, so isn't good) "worked around" this problem because it made FFmpeg resend the seek position each time.
This might fix problems of bad data that existed before, when FFmpeg didn't decide to send the seek pos or otherwise got confused by its seek position getting mistreated.
Fixes #7633 and Grand Theft Auto.
-[Unknown]