| Previous | Next |
| NS_E_VIDSOURCESIZE | NS_E_VIDCAPCREATEWINDOW |
NS_E_ICMQUERYFORMAT
How to interpret the code in a real encoding session
0xC00D1B6C is named NS_E_ICMQUERYFORMAT. Its practical scope is querying a Video for Windows compressor for an acceptable output format, which belongs to video capture and compressor negotiation rather than to every part of Windows Media playback or Windows itself.
Mechanism and point of failure
A live video source passes through device opening, capture-format negotiation, optional clipping and preview-window setup before an encoder codec accepts the frames in a session that returns this result. Width, height, pixel format and driver state belong to this boundary at the icmqueryformat checkpoint.
Seeing a device in enumeration or obtaining a preview frame does not establish that the requested capture format can be delivered continuously to the encoder in a session that returns this result. A typical reproduction is: the selected compressor cannot emit the requested bit depth and dimensions. This makes the first result from the Encoder more valuable than a later generic message.
Reproduction matrix
| Field | What to preserve |
|---|---|
| Decisive values | compressor FOURCC, input/output BITMAPINFOHEADER values and ICCompressQuery result |
| Producing object | device moniker, driver version, requested and native width/height, frame rate, BITMAPINFOHEADER compression and bit depth, preview state, source-plug-in result and first driver error |
| Session correlation | the same source-group generation, audience index, object identity and callback sequence that produced this result |
| Lower-level evidence | the first COM, driver, file-system or codec HRESULT observed before the Encoder mapped the condition to this result |
| Controlled comparison | a known-good session that changes only the setting named in the icmqueryformat boundary |
Evidence matrix
| Observation | How to interpret it |
|---|---|
| Observation that supports it | The decisive evidence is compressor FOURCC, input/output BITMAPINFOHEADER values and ICCompressQuery result. It confirms querying a Video for Windows compressor for an acceptable output format in the same object generation. |
| Observation that points to an earlier failure | The recorded values satisfy the icmqueryformat rule, but a source, driver, COM activation or file operation returns a different HRESULT first. |
| Observation that points to a later failure | The Encoder passes this boundary (querying a Video for Windows compressor for an acceptable output format), but a codec, archive or broadcast sink then fails in a subsequent stage. |
| Verification after correction | Apply this isolated change: choose an output format the compressor reports as supported or use a different trusted codec. The original icmqueryformat call should then advance past the same checkpoint. |
The operational impact of it is limited to the video capture and compressor negotiation transition that owns querying a Video for Windows compressor for an acceptable output format. In the representative case where the selected compressor cannot emit the requested bit depth and dimensions, keep the first failing call and its object identity so a later wrapper cannot replace the icmqueryformat evidence.
Minimal experiment
- Record
0xC00D1B6C, it, the Encoder version and the exact API call or property access that returned it. - Export the current
.wmeor.prxconfiguration, then capture compressor FOURCC, input/output BITMAPINFOHEADER values and ICCompressQuery result. - verify the video capture and compressor negotiation precondition without changing the source, profile and output sink at the same time.
- Run one controlled comparison in which only this condition changes: choose an output format the compressor reports as supported or use a different trusted codec.
- After the change, recreate the affected Encoder object rather than assuming the existing graph discarded its earlier icmqueryformat state.
Do not collapse these results together
| Result | Why it is a different boundary |
|---|---|
NS_E_VIDSOURCESIZE | negotiation of live capture width and height with the source device |
NS_E_VIDCAPCREATEWINDOW | creation of the hidden or visible capture window required by the legacy capture path |
NS_E_VIDSOURCECOMPRESSION | agreement on output compression or color depth from the video source |
What to change—and what to leave alone
Change the smallest responsible precondition: choose an output format the compressor reports as supported or use a different trusted codec. While retesting it, keep all unrelated source, audience and output values fixed until the same call is repeated.
Do not keep retrying an unstable capture driver in the same process after preserving the first error; close the graph and test one known-native format in a fresh process in a session that returns it.
Authoritative documentation
- IWMEncVideoSource2.Width and live capture sizing.
- BITMAPINFOHEADER structure.
- ICCompressQuery video-compressor format check.
- Retrieving the configured encoder input.
Looking for a different code? Search another status or error code.