NS_E_INVALID_VIDEO_HEIGHT_ALIGN 0XC00D1BCD Fix
Video height isn't aligned to a 2-pixel boundary. Almost always caused by bad encoding settings or corrupt file headers. Quick fix: re-encode with proper height.
Bad Encoding Settings (Most Common Cause)
This error almost always means your video file has a height that isn't divisible by 2. Windows Media Player and most DirectShow-based players are strict about this — the video height must be an even number. If you encoded at 721 pixels high instead of 720, you get 0XC00D1BCD.
I've seen this most often with poorly configured H.264 encoders, especially handbrake presets from 3-4 years ago, or ffmpeg commands missing the -vf scale filter. Someone cranks out a video at 854x481 instead of 854x480, and boom — that odd pixel kills playback.
Fix It with ffmpeg
Don't bother with the Windows Media Player troubleshooter — it never fixes this. The real fix is re-encoding the video with forced even dimensions. Use ffmpeg:
ffmpeg -i input.mp4 -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" -c:a copy output.mp4
This scales width and height down to the nearest even number while keeping aspect ratio. If you know the original dimensions were supposed to be 1280x720, just force it:
ffmpeg -i input.mp4 -vf "scale=1280:720" -c:a copy output.mp4
Test the output file. If it plays, you're done. If not, move to the next cause.
Corrupt File Header or Container
Sometimes the video stream itself is fine, but the container (MKV, MP4, AVI) has a corrupted header that reports the wrong height. I see this a lot with files downloaded from dodgy streaming grabbers or old Remux rips. The player reads a garbage value for height — like 719 — and immediately throws the alignment error.
Remux the File
Remuxing strips the old container and rebuilds a clean header. Use MKVToolNix (free) or ffmpeg with the -c copy flag:
ffmpeg -i corrupt_video.mkv -c copy -map 0 clean_video.mkv
This copies all streams without re-encoding. If the header was the problem, the new file will play. If it still errors out, the stream itself is borked — go to cause #3.
Encoder or Driver Bug with Specific Codecs
Older encoders — especially x264 builds from 2012-2015 — had a known bug where they'd write odd-height frames when using certain presets or tune settings. Also, some GPU-accelerated encoders (NVENC on old Kepler cards, QuickSync on Haswell) had alignment bugs that produced frames with odd heights even if you told them to encode at 720p.
If you get this error on a file you encoded yourself, check your encoder version and settings. Don't bother with 'auto' or 'default' alignment settings — they rarely work. Manually set height to an even number in your encoder. For x264, add --vf resize:width=1280,height=720. For NVENC, use -vf scale=1280:720 in ffmpeg.
If the file came from someone else and re-encoding doesn't fix it, the stream is likely corrupted beyond repair. Try playing it in VLC (which is more lenient with alignment). If VLC works, just use VLC or re-encode the stream from VLC's 'Convert/Save' function.
Quick-Reference Summary
| Cause | Symptom | Fix |
|---|---|---|
| Bad encoding settings | Video height is odd number | Re-encode with ffmpeg scale filter |
| Corrupt file header | Player reads wrong height | Remux with MKVToolNix or ffmpeg -c copy |
| Encoder/driver bug | Same file errors on multiple players | Re-encode with updated encoder or use VLC |
Start with the ffmpeg scale command — that fixes 80% of cases. If not, remux. If still not, check your encoder version or just use VLC. This error is annoying but always has a straightforward fix.
Was this solution helpful?