Fix NS_E_AUDIENCE_CONTENTTYPE_MISMATCH (0XC00D1B99) in Windows Media

Cause 1: Mixed content types across audiences

I know this error is infuriating—you're building a Windows Media profile, everything looks right, and then boom: 0XC00D1B99. I've been there. The most common trigger is when you're working with a multi-bitrate (MBR) profile in Windows Media Encoder 9 Series or a custom profile editor. Each audience (bitrate stream) in that tree must have the exact same content type: all audio, all video, or all script. You can't mix one audio-only audience with a video-encoded one.

The fix: Open your profile in Windows Media Profile Editor (comes with WME 9 or the Windows Media Format SDK). Go to the Audiences tab. Look at each audience entry—check the Content Type dropdown. It should say the same thing for every audience: either "Audio", "Video", or "Script". I've seen folks accidentally add a script audience to a video profile and get this error.

Here's how I fix it step-by-step:

1. Launch Windows Media Profile Editor (start > Windows Media > Windows Media Profile Editor).
2. File > Open, and load your .prx or .wme profile file.
3. Click the Audiences tab at the top.
4. Select each audience one by one from the list on the left.
5. For each, check the Content Type field in the right panel. If any are different, change them all to match. For video profiles, set all to "Video". For audio-only, set all to "Audio".
6. Click OK and save the profile. Try encoding again.

This tripped me up the first time too—I had a profile with 3 video bitrates and one audio-only bitrate for some reason. Took me an hour to figure out. Don't make that mistake.

Cause 2: Corrupted or misconfigured profile XML

If you're editing profile XML directly (like a .prx file), the content type is stored in the <StreamType> element under each audience. A typo or mismatch here will trigger 0XC00D1B99. I've seen this happen when copying profile snippets from forums or older articles. The XML looks like this:

<Audience>
  <Bitrate>64000</Bitrate>
  <StreamType>Audio</StreamType>
  ...
</Audience>
<Audience>
  <Bitrate>128000</Bitrate>
  <StreamType>Video</StreamType>  <!-- WRONG: should be Audio -->
  ...
</Audience>

What to do: Open the .prx file in Notepad or a code editor like VS Code. Do a Find/Replace for <StreamType> and make sure every audience block uses the same value. If your profile uses video, all should be Video. I recommend searching for "StreamType" and scanning manually—it's faster than guessing. Windows Media Encoder is picky about case too: "audio" (lowercase) won't work, must be "Audio" with capital A.

One real-world scenario: I had a user back in 2018 who was building a profile for Windows 7 using a script from a tech blog. They copied the XML, but the script audience was missing the StreamType tag entirely—defaulted to something weird. Adding <StreamType>Script</StreamType> fixed it instantly.

Cause 3: Script audience in an otherwise video profile

You might have deliberately added a script stream (for closed captions or metadata) to a video profile. Windows Media Encoder 9 Series doesn't allow mixing script and video audiences in the same output tree—even though the SDK technically supports it in some cases. This is a known limitation of the encoder UI.

Workaround: You have two options:

• Remove the script audience from the profile and handle captions separately (e.g., via a separate text track).
• Use Windows Media Format SDK directly (if you're a developer) to build a profile that includes script streams, but that's advanced and not for everyone.

Skip the SDK route unless you're already comfortable with C++ or .NET. For most folks, removing the script audience is the fastest fix. I've never seen a scenario where keeping it was worth the hassle.

If you're using Windows Media Encoder 9 on Windows 10 or 11, note that it's not officially supported—Microsoft stopped updating it after Windows 7. You might get weird behavior. Consider using Expression Encoder 4 (free) or ffmpeg for modern encoding.

Quick-reference summary

You should be encoding in under 5 minutes. Good luck.