So you're streaming a video with Windows Media Services or Expression Encoder, and it dies with NS_E_TITLE_BITRATE (0xC00D00D5). The message reads something like "The source file exceeds the per title maximum bitrate." What's actually happening here is that the encoder or the server has a hard ceiling on how much data per second it'll accept for a single title — and your source blew past it.
The real question is which side set the cap. Nine times out of ten it's the publishing point on the server, not the file. Figure that out first, because the fix is different depending on which one you're allowed to change.
Cause 1: The publishing point's per-title bitrate cap is too low
A Windows Media Services publishing point has a default maximum bitrate. On a fresh install of WMS 2008 on Server 2008 R2, the default is often around 2000 Kbps (2 Mbps). Stream a 1080p H.264 file that's running at 6 Mbps and the title gets rejected the moment the server tries to accept it. This is the most common trigger — someone encodes a modern file, drops it into an old WMS setup, and immediately hits 0xC00D00D5.
You can fix this two ways. Either lower the source bitrate (covers that below), or raise the cap on the publishing point.
In the WMS MMC snap-in:
- Expand the server, then Publishing Points.
- Right-click your point and hit Properties.
- Go to the General tab.
- Under Maximum clients you'll find Maximum bit rate — set it to something that comfortably fits your source. If your file runs at 6 Mbps, set the cap to 8000 Kbps.
- Apply, then restart the publishing point.
From the command line on the WMS box, the same setting is exposed through wmsadmin:
set wms "<Publishing Point>" /MaximumBitrate:8000000
Note those are bits per second, not kilobits. Passing 8000 instead of 8000000 silently caps you at 8 Kbps and nothing will ever stream. The reason is that the property is stored in bps internally, and the MMC converts for display.
Cause 2: The source file's own bitrate is higher than the title allows
Sometimes the cap isn't the problem — your source really is too fat. A Blu-ray rip re-encoded at 40 Mbps, or a ProRes export from Premiere that someone forgot to transcode, will trip every bitrate limit in the chain. Windows Media Services, Expression Encoder, and Azure Media Services all enforce per-title bitrate ceilings, and they don't care that your file is "just a test."
Check the actual bitrate of the file before you assume anything. With ffprobe:
ffprobe -v error -show_entries format=bit_rate -of default=nw=1 yourfile.mp4
That gives you the container bitrate. For the video stream alone:
ffprobe -v error -select_streams v:0 -show_entries stream=bit_rate -of default=nw=1 yourfile.mp4
The reason I mention the container bitrate is that muxing overhead and multiple audio tracks can push you over even when the video stream alone looks fine. If container bitrate is 6.5 Mbps and the cap is 6 Mbps, you get the error even though the video track reads 5.8 Mbps.
To re-encode down to something sane without wrecking quality, use a two-pass x264 encode:
ffmpeg -i input.mp4 -c:v libx264 -b:v 4500k -preset slow -pass 1 -an -f mp4 NUL
ffmpeg -i input.mp4 -c:v libx264 -b:v 4500k -preset slow -pass 2 -c:a aac -b:a 128k output.mp4
On Linux or macOS, replace NUL with /dev/null. Two-pass costs you extra encode time but hits the target bitrate far more accurately than one-pass CBR. That accuracy is exactly what keeps you under the cap.
Cause 3: Expression Encoder profile bitrate exceeds the server's declared maximum
Expression Encoder 4 has its own per-title bitrate setting baked into the encoding profile, and it has to be less than or equal to whatever the target publishing point advertises. If you're pushing to a WMS server whose maximum is 3 Mbps, and your profile is set to 5 Mbps, you'll hit 0xC00D00D5 in the job log even before the file ever reaches the wire.
Open the encoding profile in Expression Encoder:
- In the Encode tab, click the Preset dropdown next to your source.
- Select Custom, or duplicate an existing preset.
- Under Video, check the Bitrate field. Set it to match or sit just under the server's cap.
- If you're using IIS Smooth Streaming or adaptive presets, expand the preset list and inspect every bitrate tier. One stray 8 Mbps tier in an otherwise 2 Mbps ladder will trigger the error.
A useful sanity check: the profile's highest bitrate tier must be ≤ the publishing point maximum. Not the average, not the target — the highest. WMS checks the peak.
If you're pushing to Azure Media Services instead of on-prem WMS, the same rule applies. The legacy Media Services v2 API enforced per-title bitrate against the streaming unit tier. v3 doesn't use this error code, but the underlying constraint — encoding profile bitrate must fit the output limits — is the same idea.
Quick reference
| Symptom | Likely cause | Fix |
|---|---|---|
| Fresh WMS install, modern 1080p source | Default publishing point cap (~2 Mbps) too low | Raise Maximum bit rate on the publishing point General tab, or via wmsadmin |
| Error starts immediately on job start | Source file bitrate higher than title limit | Re-encode with two-pass x264 to a target bitrate under the cap |
| Error only with certain encoder presets | Expression Encoder profile bitrate tier exceeds server max | Lower every bitrate tier in the profile so the highest one sits under the cap |
| Container bitrate higher than video stream bitrate | Audio tracks or muxing overhead pushing total over | Re-mux with a single AAC track, or trim to fit |
The one thing to remember: this error is never about codec, resolution, or container. It's purely a bits-per-second ceiling somewhere in the pipeline, and there are only three places that ceiling lives — the publishing point, the source file, or the encoder profile. Check them in that order and you'll have it fixed in ten minutes.