Quote:
Originally Posted by madshi
(1) One thread callstack looks like this:
Code:
thread $df0:
75f9ee32 +5d GDI32.dll D3DKMTSignalSynchronizationObject
0923c642 +32 nvcuvid.dll cuvidMapVideoFrame
0922a8a0 +20 nvcuvid.dll cuvidParseVideoData
I think this is likely an LAV Video Decoder related thread, don't you agree? But somehow the callstack doesn't contain any LAV Video Decoder related callstack items. That makes me think that the PDB file somehow didn't work. |
Ah, i somehow missed that one. Thanks for looking
cuvidParseVideoData is a NVIDIA function i call, which in turn calls a callback function of LAV, in which i then call cuvidMapVideoFrame (which basically is the LockRect of CUVID)
This would indicate the decoder is still working just fine, and is not deadlocked somewhere (except if that function somehow hangs, but never seen that happen and wouldn't even know why/how). This is called directly from my decoder worker thread, and if that thread is working and processing a frame, then everything else is still running.
Quote:
Originally Posted by madshi
My interpretation of this is that the main thread is trying to react to a press on the ZP "stop" button, while the ZP DSP filter is busy receiving data. Both try to enter the same critical section at the same time while it might even already be in use by a 3rd thread. I think DSP is audio related, though?
|
I agree with your interpretation.
Both the main thread and some other thread try to enter the same critical section, but that also means something else has to hold that one right now.
But DSP is audio indeed, so its rather unlikely to be related to my latest changes (not knowing ZP itself, not ruling anything out)