| Previous | Next |
| NS_E_VIDEODRIVER_UNSTABLE | NS_E_VIDSOURCECOMPRESSION |
NS_E_VIDCAPSTARTFAILED
Where the Encoder produces this result
0xC00D1B69 (NS_E_VIDCAPSTARTFAILED) identifies transition of the configured video capture graph into streaming state. The important diagnostic boundary is the Encoder object that validates this state; a later “cannot start encoding” dialog can hide that more precise origin.
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 vidcapstartfailed checkpoint.
What has already succeeded
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. In a representative vidcapstartfailed case, all filters connect, but the driver rejects the transition from paused to running. The result observation should be tested at the producing object instead of being treated as a general codec or operating-system failure.
State snapshot to capture
| Field | What to preserve |
|---|---|
| Decisive values | graph state-change HRESULT, negotiated media type, device-control state and first capture callback |
| 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 vidcapstartfailed boundary |
How to read the next observation
| Observation | How to interpret it |
|---|---|
| Observation that supports it | The decisive evidence is graph state-change HRESULT, negotiated media type, device-control state and first capture callback. It confirms transition of the configured video capture graph into streaming state in the same object generation. |
| Observation that points to an earlier failure | The recorded values satisfy the vidcapstartfailed 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 (transition of the configured video capture graph into streaming state), but a codec, archive or broadcast sink then fails in a subsequent stage. |
| Verification after correction | Apply this isolated change: verify the negotiated native format and start the capture device without optional transforms. The original vidcapstartfailed 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 transition of the configured video capture graph into streaming state. In the representative case where all filters connect, but the driver rejects the transition from paused to running, keep the first failing call and its object identity so a later wrapper cannot replace the vidcapstartfailed evidence.
A controlled diagnostic sequence
- Record
0xC00D1B69, it, the Encoder version and the exact API call or property access that returned it. - Export the current
.wmeor.prxconfiguration, then capture graph state-change HRESULT, negotiated media type, device-control state and first capture callback. - 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: verify the negotiated native format and start the capture device without optional transforms.
- After the change, recreate the affected Encoder object rather than assuming the existing graph discarded its earlier vidcapstartfailed state.
Nearby HRESULTs that mean something else
| Result | Why it is a different boundary |
|---|---|
NS_E_VIDEODRIVER_UNSTABLE | driver state after an unrecoverable capture failure makes further graph use unsafe |
NS_E_VIDSOURCECOMPRESSION | agreement on output compression or color depth from the video source |
NS_E_VIDEODEVICE_UNEXPECTED | video device initialization after enumeration where the driver returns an unclassified failure |
Corrective action at the right layer
The focused correction is to verify the negotiated native format and start the capture device without optional transforms. A retry is useful only after the recorded vidcapstartfailed precondition changes.
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.
Technical references
- 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.