Fix NS_E_INVALID_VIDEO_HEIGHT 0XC00D1BC4 in Windows

When this error hits you

You're encoding a video—maybe with FFmpeg, HandBrake, or a custom script—and suddenly Windows Media Player or your streaming app throws NS_E_INVALID_VIDEO_HEIGHT (0XC00D1BC4). The message reads: "The video height setting is not valid." It's frustrating, especially when you've triple-checked the width and it's fine. I've seen this most often when someone specifies a height that's not compatible with the codec or container—like trying to encode H.264 with a height of 1081 instead of 1080. The video plays fine in some players but bombs in others.

Root cause – it's not the height you think

Here's the ugly truth: the error isn't always about the literal number being negative or zero. Windows Media Player and DirectShow filters enforce strict compatibility rules. Common triggers:

Height isn't divisible by 2 (or 16 for some codecs). Most codecs require even heights.
Container restrictions – e.g., ASF or WMV files have max height limits.
Height mismatched between a codec's profile and the actual stream metadata.
Corrupted header where the height field is malformed.

If you're encoding with FFmpeg, you'll sometimes get this silently while the output file plays elsewhere. The real fix is ensuring the height meets codec constraints.

Step-by-step fix

1. Check the height is an even number

Open your encoding command or tool. For FFmpeg, look at the -vf or -s parameters. Height must be divisible by 2. Use this FFmpeg filter to force even dimensions:

ffmpeg -i input.mp4 -vf "scale=iw:trunc(ih/2)*2" -c:v libx264 output.mp4

This keeps the width same and rounds height down to the nearest even number. HandBrake users: go to the Dimensions tab and set "Modulus" to 2.

2. Verify container compatibility

If you're targeting Windows Media format (WMV, ASF), the max height is 1088 pixels. Anything above that triggers this error. Stick to 1080 or 720 for safety. For MP4 with H.264, you're fine up to 2160p, but still keep height even.

3. Use mediainfo to spot mismatches

Download MediaInfo (it's free). Open your corrupt file and look for a mismatch between the Height in the video track and the Display aspect ratio height. I've seen files where the encoded height says 1080 but the container header says 1081. That discrepancy triggers 0XC00D1BC4. If you find it, re-encode with -vf "setdar=16/9" to sync them.

4. Re-encode with correct parameters

The nuclear option: re-encode the video using a clean command. Here's a safe bet for H.264 in an MP4 container:

ffmpeg -i input.avi -s 1920x1080 -c:v libx264 -crf 23 -pix_fmt yuv420p output.mp4

I always include -pix_fmt yuv420p because older DirectShow filters hate non-standard pixel formats. This alone has fixed the error for me half a dozen times.

5. Check for corrupted headers

If the file plays fine in VLC but not in Windows Media Player, the header might be corrupt. Use FFmpeg to copy the streams and rewrite the header:

ffmpeg -i input.mp4 -c copy -map 0 output.mp4

This re-muxes without re-encoding, often cleaning up bad metadata. If that fails, remux into a different container (MKV to MP4) and then back.

What to check if it still fails

If none of that works, suspect the source file itself. Try playing the original video in a different app that gives more info (like MPC-HC or VLC). If it plays fine, the problem is the player or codec filter. In Windows, run dshowchecker to see which DirectShow filters are registered—sometimes a bad third-party codec pack (like old K-Lite) breaks height parsing. Uninstall any suspect codec packs and reinstall the latest LAV Filters. I've seen this error vanish after that step alone.

One more thing: if you're using Windows 10 or 11, make sure Media Feature Pack is installed if you're on an N edition. Missing that can cause strange codec errors including this one.