| Previous | Next |
| MF_E_RT_TOO_MANY_CLASSES | MF_E_NO_BITPUMP |
MF_E_RT_WOULDBLOCK
MF_E_RT_WOULDBLOCK means a Media Foundation real-time operation cannot proceed because another thread currently owns the required object. The useful distinction is that the operation would block; this is not a permanent unsupported-operation result.
Find the owner and the blocking edge
- Capture thread IDs, callback entry/exit times, the work-queue ID, and the object on which the failing operation is attempted.
- Look for synchronous waits, lock inversion, or callbacks that hold component locks while calling into another Media Foundation object.
- Avoid sleeping and retrying in a tight loop on an RT work-queue thread. That consumes the same scheduling capacity the pipeline needs to make progress.
Media Foundation's work-queue guidance explicitly favors platform work queues for pipeline components and warns about priority inversion when high-priority processing waits on lower-priority worker threads. Multithreaded queues also do not serialize work items automatically. When this HRESULT appears intermittently under load, preserve queue and lock timing so the competing owner can be identified instead of treating it as random playback failure.
Microsoft: threading and work-queue recommendations · Microsoft: IMFRealTimeClient and priority inversion · Microsoft: work queue identifiers
Looking for a different code? Search another status or error code.