NS_E_MULTIPLE_FILE_BITRATES (0XC00D1BD0) Fix: Mixed Bitrates in ASF

When This Error Shows Up

You're building a Windows Media metafile playlist (ASX or WAX), or you're using Windows Media Encoder to merge multiple ASF files into one stream. The encoder or player hits the wall with NS_E_MULTIPLE_FILE_BITRATES (0XC00D1BD0), and the message reads "All bit rates must have the same file transfer bit rate." This happens most often when you've grabbed files from different sources — maybe one was ripped from a DVD at 2 Mbps, another from a web download at 1.5 Mbps, and a third from a camcorder at 4 Mbps.

What's Actually Happening Here

The error is a hard check inside the Windows Media ASF (Advanced Systems Format) multiplexer. ASF files carry metadata blocks that describe the bitrate of each stream. When you ask the encoder or player to treat a group of files as a single logical stream — like in a server-side playlist — it reads those bitrate headers. If any file's bitrate doesn't match the first file's bitrate, the operation aborts. This is by design: the ASF container doesn't support variable bitrate switching mid-stream the way MP4 or WebM can. The reason is historical — ASF was built for unicast streaming where the server sends a single bitrate to the client. Mixing bitrates would break the server's bandwidth allocation logic.

The Fix: Re-encode to a Common Bitrate

You can't trick the encoder by just changing a file extension or editing metadata. The bitrate is baked into the compressed audio/video data. Here's the only reliable path:

1. Identify the offending files. Run this command on each ASF file to see its bitrate:
   ffprobe -v error -select_streams v:0 -show_entries stream=bit_rate -of default=noprint_wrappers=1:nokey=1 file.asf
   Do the same for audio streams: replace v:0 with a:0. Write down every bitrate.
2. Pick a target bitrate. Choose the bitrate that matches the majority of your files, or pick a value that works for your distribution target. For internet streaming, 1500 kbps (1.5 Mbps) is a safe middle ground. For local playback, you can go up to 8 Mbps without issues.
3. Re-encode all files to that bitrate. Use FFmpeg with the Windows Media Video 9 (WMV3) codec. Example command for a target of 1500 kbps video and 128 kbps audio:
   ffmpeg -i input.asf -c:v wmv2 -b:v 1500k -c:a wmav2 -b:a 128k -ar 44100 output.asf
   Replace wmv2 with wmv3 if your source is VC-1 encoded (check with ffprobe). The key flags are -b:v (video bitrate) and -b:a (audio bitrate).
4. Verify consistency. After re-encoding, run the bitrate check from step 1 on the output files. All video streams should show the same bit_rate. Same for audio.
5. Rebuild your playlist or encoder job. Point to the new files. The error should be gone.

If It Still Fails

If the error persists after re-encoding, check these things:

• Mixed codecs. Two files might have the same bitrate but different codecs (e.g., one WMV3, another WMV2). The encoder will still reject them. Re-encode everything with the same -c:v and -c:a values.
• Variable vs constant bitrate. ASF expects constant bitrate (CBR) for server-side playlists. FFmpeg's wmv2 encoder defaults to CBR when you pass -b:v. If you used a CRF or VBR method, switch to explicit -b:v.
• Frame rate mismatch. Unlikely, but if you mixed 25 fps and 30 fps files, some encoders will choke. Re-encode with -r 25 to force uniform frame rate.
• Corrupted index. Old ASF files sometimes have broken index tables. Run ffmpeg -i broken.asf -c copy -fflags +genpts fixed.asf to rebuild the index.

If none of that works, switch your container to MP4 with H.264/AAC. It's 2025 and ASF is a dead format for good reason. But if you're stuck in a legacy workflow, the re-encode route is your only option.