The missing semaphore in sceMpeg

[hrydgard]

I've (and anyone who's been looking a lot at logs) must have noticed that a lot of the time when playing video using sceMpeg, games try to access a non-existent semaphore object. Example from Wipeout Pulse:

47:12:140 Main thread  I[ME]: HLE\sceMpeg.cpp:573 00000000=sceMpegCreate(08d08c30, 096d7100, 00010000, 08d08bb0, 00000200, 00000000, 00000000)
47:12:141 Main thread  I[ME]: HLE\sceMpeg.cpp:703 1=sceMpegRegistStream(08d08c30, 00000000, 00000000)
47:12:141 Main thread  I[ME]: HLE\sceMpeg.cpp:703 2=sceMpegRegistStream(08d08c30, 00000001, 00000000)
47:12:142 Main thread  I[SCEKERNEL]: HLE\sceKernelThread.cpp:2019 564=sceKernelCreateThread(readThread, 08914754, 00000041, 32768, 00000000, 00000000)
47:12:143 Main thread  I[SCEKERNEL]: HLE\sceKernelThread.cpp:2019 565=sceKernelCreateThread(soundThread, 08914ab4, 0000003c, 16384, 00000000, 00000000)
47:12:148 Main thread  I[ME]: HLE\sceMpeg.cpp:370 Stream offset: 2048, Stream size: 0x578000
47:12:148 Main thread  I[ME]: HLE\sceMpeg.cpp:371 First timestamp: 90000, Last timestamp: 3693600
47:12:149 Main thread  I[ME]: HLE\sceMpeg.cpp:370 Stream offset: 2048, Stream size: 0x578000
47:12:149 Main thread  I[ME]: HLE\sceMpeg.cpp:371 First timestamp: 90000, Last timestamp: 3693600
47:12:149 Main thread  E[SCEKERNEL]: HLE\sceKernelSemaphore.cpp:373 SCE_KERNEL_ERROR_UNKNOWN_SEMID=sceKernelWaitSema(0, 1, 00000000)
47:12:150 Main thread  E[SCEKERNEL]: HLE\sceKernelSemaphore.cpp:273 SCE_KERNEL_ERROR_UNKNOWN_SEMID=sceKernelSignalSema(0, 1): bad sema id
4

And later:

47:12:534 Main thread  E[SCEKERNEL]: HLE\sceKernelSemaphore.cpp:373 SCE_KERNEL_ERROR_UNKNOWN_SEMID=sceKernelWaitSema(0, 1, 00000000)
47:12:534 Main thread  E[SCEKERNEL]: HLE\sceKernelSemaphore.cpp:273 SCE_KERNEL_ERROR_UNKNOWN_SEMID=sceKernelSignalSema(0, 1): bad sema id
4

I think the only reasonable explanation is that sceMpegCreate or a related call actually creates a semaphore for us, and returns a handle to it in memory somewhere. Since we don't do that, the ID becomes 0 and that's what it tries to access.

This is presumably used to synchronize video decoding with rendering. Not implementing this correctly doesn't seem to have too many bad consequences, probably because we effectively instantly finish decoding each frame from the game's point of view, but it could affect all kinds of things like subtitles (which we have a few games that have problems with) or other things, so probably worth fixing at some point.

EDIT: Actually, there's a likely candidate in the semaID field of the SceMpegRingBuffer struct. The question is exactly when to create it, and when to signal it.