| Previous | Next |
| NS_E_INVALID_INTERLACEMODE | NS_E_INVALID_NONSQUAREPIXEL_COMPAT |
NS_E_INVALID_INTERLACE_COMPAT
How to interpret the code in a real encoding session
0xC00D1BDC is named NS_E_INVALID_INTERLACE_COMPAT. Its practical scope is interlace preservation conflicts with the Player 7.1 compatibility target, which belongs to legacy player compatibility rules rather than to every part of Windows Media playback or Windows itself.
Mechanism and point of failure
Windows Media Encoder profiles can be checked for compatibility with older Windows Media Player generations in a session that returns this result. VBR, multiple audiences, audio/video format variation, interlace and non-square pixels can move a profile beyond the version 7.1 compatibility envelope.
The profile may be valid for Windows Media 9 or later and still be intentionally rejected when an older compatibility target is required in a session that returns this result. A typical reproduction is: an interlaced Windows Media 9 profile is marked for 7.1 clients. This makes the first result from the Encoder more valuable than a later generic message.
Reproduction matrix
| Field | What to preserve |
|---|---|
| Decisive values | DetectCompatibility result and interlace mode |
| Producing object | DetectCompatibility result, target player generation, audience count, VBR mode, codec and format per audience, frame size, interlace flag and non-square-pixel flag |
| 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 invalid interlace compat boundary |
Evidence matrix
| Observation | How to interpret it |
|---|---|
| Observation that supports it | The decisive evidence is DetectCompatibility result and interlace mode. It confirms interlace preservation conflicts with the Player 7.1 compatibility target in the same object generation. |
| Observation that points to an earlier failure | The recorded values satisfy the invalid interlace compat 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 (interlace preservation conflicts with the Player 7.1 compatibility target), but a codec, archive or broadcast sink then fails in a subsequent stage. |
| Verification after correction | Apply this isolated change: disable interlace preservation or raise the required player version. The original invalid interlace compat call should then advance past the same checkpoint. |
The operational impact of it is limited to the legacy player compatibility rules transition that owns interlace preservation conflicts with the Player 7.1 compatibility target. In the representative case where an interlaced Windows Media 9 profile is marked for 7.1 clients, keep the first failing call and its object identity so a later wrapper cannot replace the invalid interlace compat evidence.
Minimal experiment
- Record
0xC00D1BDC, it, the Encoder version and the exact API call or property access that returned it. - Export the current
.wmeor.prxconfiguration, then capture DetectCompatibility result and interlace mode. - verify the legacy player compatibility rules precondition without changing the source, profile and output sink at the same time.
- Run one controlled comparison in which only this condition changes: disable interlace preservation or raise the required player version.
- After the change, recreate the affected Encoder object rather than assuming the existing graph discarded its earlier invalid interlace compat state.
Do not collapse these results together
| Result | Why it is a different boundary |
|---|---|
NS_E_MULTIPLE_VIDEO_SIZES | audiences use different frame sizes while Player 7.1 compatibility is requested |
NS_E_INVALID_NONSQUAREPIXEL_COMPAT | non-square-pixel output conflicts with the Player 7.1 compatibility target |
NS_E_MULTIPLE_AUDIO_FORMATS | audiences use different audio formats while legacy Player 7.1 compatibility is requested |
What to change—and what to leave alone
Change the smallest responsible precondition: disable interlace preservation or raise the required player version. While retesting it, keep all unrelated source, audience and output values fixed until the same call is repeated.
Do not describe a compatibility result as codec corruption; first decide whether support for the older player is a real requirement in a session that returns it.
Why interlace compatibility is a separate decision
Interlace preservation is not simply another bitrate option. It changes how fields are represented in the encoded video and therefore affects the decoder and renderer capabilities assumed by the profile. Record whether the input is actually interlaced, the field order, the output dimensions, and the profile flag used to maintain interlacing. A progressive source with an inherited interlace flag is a profile-authoring defect; a genuinely interlaced source may instead require a newer playback baseline.
Use IWMEncProfile2.DetectCompatibility after changing only the interlace setting. If the profile becomes compatible while codec, bitrate, audience count and frame size remain unchanged, the result is specifically about the legacy compatibility target. If validation still fails with interlace preservation disabled, keep the later HRESULT separate because it belongs to another profile field.
Authoritative documentation
- Detecting profile compatibility.
- IWMEncProfile2.VBRMode.
- Selecting a video codec for an audience.
- Adding an audience to an encoder profile.
Looking for a different code? Search another status or error code.