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.

Sign up for GitHub

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

Jump to bottom

Project Diva 2nd has corrupted keyframes in mpeg movies (again) #2705

Open
thedax opened this issue Jul 8, 2013 · 30 comments
Open

Project Diva 2nd has corrupted keyframes in mpeg movies (again) #2705

thedax opened this issue Jul 8, 2013 · 30 comments

Comments

@thedax
Copy link
Collaborator

thedax commented Jul 8, 2013 •
edited by unknownbrackets
Loading

A git bisect (from 0.8.1-1 to 0.8.1-430) claims 64a042d is responsible, but I'm sure we can find a way to make it play correctly if we test enough.

How it is currently (highlighted in red):
Screenshot

What it should look like:
Screenshot

Project Diva 2nd - JP 1.00
@unknownbrackets
Copy link
Collaborator

Is this still happening, or has it improved?

-[Unknown]

@thedax
Copy link
Collaborator Author

thedax commented Nov 27, 2013

It's still happening.

Tested with daa9d27.

@thedax
Copy link
Collaborator Author

thedax commented Dec 5, 2013

I looked at this a bit closer, and the removal of this seems to be the culprit:

  if (ctx->avc.avcDecodeResult == 0) {

    // return PSP_ERROR_MPEG_NO_DATA at first call before mpegAvcDecode

    ctx->avc.avcDecodeResult = MPEG_AVC_DECODE_SUCCESS;

    return hleDelayResult(PSP_ERROR_MPEG_NO_DATA, "mpeg get avc", mpegDecodeErrorDelayMs);

  }

If I add it back in, no corrupted keyframes. If I remove it again, the corrupted keyframes return.

@hrydgard
Copy link
Owner

hrydgard commented Dec 5, 2013

Hm, I wonder why we removed that...

@thedax
Copy link
Collaborator Author

thedax commented Dec 5, 2013

According to the commit, it's "more correct". But is it truly?

64a042d

@dbz400 dbz400 mentioned this issue Jan 8, 2014
Merged
@dbz400
Copy link
Contributor

dbz400 commented Jan 8, 2014

@thedax , just wonder the above commit helps this game?

@thedax
Copy link
Collaborator Author

thedax commented Jan 8, 2014

It actually does, yeah.

@thedax
Copy link
Collaborator Author

thedax commented Jan 18, 2014

I'll close this for now, since that sketchy commit fixed it, but I'll reopen if it creeps back up.

@thedax thedax closed this as completed Jan 18, 2014
@thedax
Copy link
Collaborator Author

thedax commented Jun 9, 2014

This has crept back up. I don't know in what build it returned, though. I'll check a bit later.

Edit: It appeared sometime between 0.9.7 and the newest git builds. I'll bisect tomorrow.

@thedax thedax reopened this Jun 9, 2014
@thedax
Copy link
Collaborator Author

thedax commented Jun 9, 2014

Well, it's silly to bisect. I forgot that the "fix" was reverted with #5212, so of course it came back.

@daniel229
Copy link
Collaborator

Looks fine with default setting
15

@thedax
Copy link
Collaborator Author

thedax commented Jun 10, 2014

I'm not sure what my problem is then, it doesn't happen on the real PSP with either my translated or unpatched ISO, nor in ffmpeg's FFPlay. I'm also using default settings.

@solarmystic
Copy link
Contributor

I've to concur with daniel229's findings, I can't reproduce this issue either on my copy of Diva 2nd:-

capture

System specs:-
sysspec

Using the latest self-compiled git build since the buildbot is broken at the moment with default settings.

@thedax
Copy link
Collaborator Author

thedax commented Jun 10, 2014

I guess I have a slightly corrupted ISO in some way, then. I don't get how when FFPlay doesn't exhibit the issue, but whatever. Closing this.

@thedax thedax closed this as completed Jun 10, 2014
@thedax
Copy link
Collaborator Author

thedax commented Jun 10, 2014

Now I don't know what to think. I just used a fresh copy from PSN (eboot.pbp format) and I'm still getting this. :\

Surely it's unlikely that that is corrupted, too?

@thedax thedax reopened this Jun 10, 2014
@unknownbrackets
Copy link
Collaborator

Does io on thread affect it? Maybe it's different per region?

-[Unknown]

@thedax
Copy link
Collaborator Author

thedax commented Jun 10, 2014

The game is Japanese only, so it's not a region issue. I/O on thread has no effect.

@thedax
Copy link
Collaborator Author

thedax commented Jun 14, 2014

@daniel229: You have an NVidia GPU, right? What driver are you using, and what sort of Geforce did you have again? I forget.

@daniel229
Copy link
Collaborator

Yes,I have an nvidia card GTX 460v2,driver is 337.88
01

@unknownbrackets
Copy link
Collaborator

Well, corruption like that should have more to do with ffmpeg/io (e.g. not having a complete frame ready for ffmpeg) than with graphics, I would think. But maybe I'm wrong.

-[Unknown]

@thedax
Copy link
Collaborator Author

thedax commented Jun 15, 2014

I tried a few different drivers and they didn't make a difference, but I just wanted to rule out the possibility..

@thedax
Copy link
Collaborator Author

thedax commented Sep 17, 2015

This is still happening to me in the latest builds, and ffmpeg seems to have errors decoding the first few frames:

37:19:872 user_main    I[ME]: HLE\sceMpeg.cpp:423 sceMpegInit()
37:19:872 user_main    I[ME]: HLE\sceMpeg.cpp:530 093743c8=sceMpegCreate(08d1c350, 09374398, 65536, 08d1c354, 512, 0, 0)
37:19:873 user_main    I[ME]: HLE\sceMpeg.cpp:648 sceMpegRegistStream(08d1c350, 0, 0)
37:19:873 user_main    I[ME]: HLE\sceMpeg.cpp:648 sceMpegRegistStream(08d1c350, 1, 0)
37:19:873 user_main    I[KERNEL]: HLE\sceKernelThread.cpp:1946 409=sceKernelCreateThread(soundThread, 08a32980, 00000011, 2048, 00000000, 00000000)
37:19:873 user_main    I[KERNEL]: HLE\sceKernelThread.cpp:1946 411=sceKernelCreateThread(SofdecThread, 08a30394, 00000032, 8192, 00000000, 00000000)
37:19:873 user_main    I[KERNEL]: HLE\sceKernelThread.cpp:2017 0=sceKernelStartThread(409, 4, 08d1c5cc)
37:19:873 user_main    I[KERNEL]: HLE\sceKernelThread.cpp:2017 0=sceKernelStartThread(411, 4, 0bfff540)
37:19:887 SofdecThread I[ME]: HLE\sceMpeg.cpp:348 Stream offset: 2048, Stream size: 0x172E000
37:19:887 SofdecThread I[ME]: HLE\sceMpeg.cpp:349 First timestamp: 90000, Last timestamp: 8213115
37:19:887 SofdecThread I[ME]: HLE\sceMpeg.cpp:348 Stream offset: 2048, Stream size: 0x172E000
37:19:888 SofdecThread I[ME]: HLE\sceMpeg.cpp:349 First timestamp: 90000, Last timestamp: 8213115
37:19:888 SofdecThread I[ME]: HLE\sceMpeg.cpp:348 Stream offset: 2048, Stream size: 0x172E000
37:19:888 SofdecThread I[ME]: HLE\sceMpeg.cpp:349 First timestamp: 90000, Last timestamp: 8213115
37:19:899 SofdecThread I[ME]: HW\MediaEngine.cpp:87 FF: error while decoding MB 14 3, bytestream -11
37:19:908 SofdecThread I[ME]: HW\MediaEngine.cpp:87 FF: No accelerated colorspace conversion found from yuv420p to rgba.
37:19:916 SofdecThread I[ME]: HW\MediaEngine.cpp:87 FF: error while decoding MB 29 5, bytestream -34

It's still really weird that nobody else can repro this..no matter how many times I re-download this game from PSN, it still happens for me.

@thedax thedax closed this as completed Sep 17, 2015
@thedax thedax reopened this Sep 17, 2015
@hrydgard
Copy link
Owner

I don't think it's just you, I think most people just don't notice :P We clearly have a bug.

@thedax
Copy link
Collaborator Author

thedax commented Sep 17, 2015

Heh, probably. I thought I had it resolved a moment ago, but it was just a fluke..the second time I saw the video it had the corrupted frames, so who knows..

@tuankiet65
Copy link

It's still there in the latest commit (1.0.1-2686-g4bdde2a, built with latest FFmpeg and not the FFmpeg bundled with repo)

08:45:306 user_main    I[ME]: HLE/sceMpeg.cpp:423 sceMpegInit()
08:45:308 user_main    I[ME]: HLE/sceMpeg.cpp:530 09373bf0=sceMpegCreate(08d1c350, 09373bc0, 65536, 08d1c354, 512, 0, 0)
08:45:339 user_main    I[ME]: HLE/sceMpeg.cpp:648 sceMpegRegistStream(08d1c350, 0, 0)
08:45:340 user_main    I[ME]: HLE/sceMpeg.cpp:648 sceMpegRegistStream(08d1c350, 1, 0)
08:45:373 SofdecThread I[ME]: HLE/sceMpeg.cpp:348 Stream offset: 2048, Stream size: 0x172E000
08:45:373 SofdecThread I[ME]: HLE/sceMpeg.cpp:349 First timestamp: 90000, Last timestamp: 8213115
08:45:373 SofdecThread I[ME]: HLE/sceMpeg.cpp:348 Stream offset: 2048, Stream size: 0x172E000
08:45:373 SofdecThread I[ME]: HLE/sceMpeg.cpp:349 First timestamp: 90000, Last timestamp: 8213115
08:45:373 SofdecThread I[ME]: HLE/sceMpeg.cpp:348 Stream offset: 2048, Stream size: 0x172E000
08:45:373 SofdecThread I[ME]: HLE/sceMpeg.cpp:349 First timestamp: 90000, Last timestamp: 8213115
08:45:381 SofdecThread I[ME]: HW/MediaEngine.cpp:87 FF: error while decoding MB 14 3, bytestream -11

The bug is very subtle (no visual artifacts or alike) and can only be noticed when looking at the log.
System info:
screenshot from 2015-09-18 23-19-16
Video if needed: https://d.maxfile.ro/dhqettfamk.mkv

@tuankiet65
Copy link

Kind of weird, but I also got this problem when playing Project Diva Extend

36:30:312 user_main    I[ME]: HLE/sceMpeg.cpp:423 sceMpegInit()
36:30:412 user_main    I[ME]: HLE/sceMpeg.cpp:530 093d4458=sceMpegCreate(08d72d14, 093d4428, 65536, 08d72d18, 512, 0, 0)
36:30:446 user_main    I[ME]: HLE/sceMpeg.cpp:648 sceMpegRegistStream(08d72d14, 0, 0)
36:30:446 user_main    I[ME]: HLE/sceMpeg.cpp:648 sceMpegRegistStream(08d72d14, 1, 0)
36:30:446 user_main    I[KERNEL]: HLE/sceKernelThread.cpp:1946 419=sceKernelCreateThread(soundThread, 089d2ec0, 00000011, 2048, 00000000, 00000000)
36:30:446 user_main    I[KERNEL]: HLE/sceKernelThread.cpp:1946 421=sceKernelCreateThread(SofdecThread, 089d0c08, 00000032, 8192, 00000000, 00000000)
36:30:446 user_main    I[KERNEL]: HLE/sceKernelThread.cpp:2017 0=sceKernelStartThread(419, 4, 08d72f90)
36:30:446 user_main    I[KERNEL]: HLE/sceKernelThread.cpp:2017 0=sceKernelStartThread(421, 4, 0bfff570)
36:30:479 SofdecThread I[ME]: HLE/sceMpeg.cpp:348 Stream offset: 2048, Stream size: 0x1711000
36:30:479 SofdecThread I[ME]: HLE/sceMpeg.cpp:349 First timestamp: 90000, Last timestamp: 9648549
36:30:479 SofdecThread I[ME]: HLE/sceMpeg.cpp:348 Stream offset: 2048, Stream size: 0x1711000
36:30:479 SofdecThread I[ME]: HLE/sceMpeg.cpp:349 First timestamp: 90000, Last timestamp: 9648549
36:30:479 SofdecThread I[ME]: HLE/sceMpeg.cpp:348 Stream offset: 2048, Stream size: 0x1711000
36:30:479 SofdecThread I[ME]: HLE/sceMpeg.cpp:349 First timestamp: 90000, Last timestamp: 9648549
36:30:492 SofdecThread I[ME]: HW/MediaEngine.cpp:87 FF: error while decoding MB 27 7, bytestream -10
36:30:504 SofdecThread I[ME]: HW/MediaEngine.cpp:87 FF: error while decoding MB 8 9, bytestream -11

@thedax
Copy link
Collaborator Author

thedax commented Aug 19, 2016

This issue has seemingly been fixed; I compiled the latest commit and I can't reproduce this any longer, so I'll go ahead and close this again.

@thedax thedax closed this as completed Aug 19, 2016
@unknownbrackets
Copy link
Collaborator

Thanks for checking - probably fixed by #8867. I knew there was another one but couldn't remember which game it was (#5266 was also fixed.)

-[Unknown]

@thedax
Copy link
Collaborator Author

thedax commented Aug 20, 2016

No problem, thanks for fixing it.

@unknownbrackets
Copy link
Collaborator

unknownbrackets commented May 5, 2020 •
edited
Loading

Someone's reporting this is happening again, but only on Android. Exactly the same part of the video afaict.

-[Unknown]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@hrydgard @unknownbrackets @tuankiet65 @dbz400 @daniel229 @solarmystic @thedax