| Previous | Next |
| NS_E_INVALIDCALL_WHILE_ARCHIVAL_RUNNING | NS_E_PLUGIN_CLSID_INVALID |
NS_E_INVALIDPACKETSIZE
Diagnostic meaning beyond the standard text
For NS_E_INVALIDPACKETSIZE (0xC00D1B75), the actionable event is validation of the configured maximum packet size for encoded output. Keep the result producing boundary attached to the original Encoder callback or COM call.
Why the session can reach this point
The Encoder can expose an HTTP broadcast and can push to Windows Media Services in a session that returns this result. Packet sizing, publishing-point data and announcement generation are output-distribution concerns, separate from source capture and codec selection at the invalidpacketsize checkpoint.
A stream can encode correctly to a file yet fail distribution because the broadcast sink or announcement metadata cannot represent the selected profile in a session that returns this result. One concrete way to reach the condition is that a configuration parser treats an empty field as zero or a byte count as kilobytes. The result test should therefore preserve the object generation and numeric settings, not just a screenshot of the final dialog.
Trace fields with diagnostic value
| Field | What to preserve |
|---|---|
| Decisive values | numeric packet-size value, transport mode, profile bitrate and API that supplied the value |
| Producing object | output protocol, port, server and publishing point, maximum packet size, profile bitrate mode, generated.nsc/.asx paths, archive state and first distribution HRESULT |
| Session correlation | the same source-group generation, audience index, object identity and callback sequence that produced this result |
| Lower-level evidence | the first COM, driver, file-system or codec HRESULT observed before the Encoder mapped the condition to this result |
| Controlled comparison | a known-good session that changes only the setting named in the invalidpacketsize boundary |
Decision matrix
| Observation | How to interpret it |
|---|---|
| Observation that supports it | The decisive evidence is numeric packet-size value, transport mode, profile bitrate and API that supplied the value. It confirms validation of the configured maximum packet size for encoded output in the same object generation. |
| Observation that points to an earlier failure | The recorded values satisfy the invalidpacketsize rule, but a source, driver, COM activation or file operation returns a different HRESULT first. |
| Observation that points to a later failure | The Encoder passes this boundary (validation of the configured maximum packet size for encoded output), but a codec, archive or broadcast sink then fails in a subsequent stage. |
| Verification after correction | Apply this isolated change: use a packet size in the range accepted by the selected output transport. The original invalidpacketsize call should then advance past the same checkpoint. |
The operational impact of it is limited to the broadcast and packet-output setup transition that owns validation of the configured maximum packet size for encoded output. In the representative case where a configuration parser treats an empty field as zero or a byte count as kilobytes, keep the first failing call and its object identity so a later wrapper cannot replace the invalidpacketsize evidence.
Decision path
- Record
0xC00D1B75, it, the Encoder version and the exact API call or property access that returned it. - Export the current
.wmeor.prxconfiguration, then capture numeric packet-size value, transport mode, profile bitrate and API that supplied the value. - verify the broadcast and packet-output setup precondition without changing the source, profile and output sink at the same time.
- Run one controlled comparison in which only this condition changes: use a packet size in the range accepted by the selected output transport.
- After the change, recreate the affected Encoder object rather than assuming the existing graph discarded its earlier invalidpacketsize state.
Codes with similar symptoms but different owners
| Result | Why it is a different boundary |
|---|---|
NS_E_CANNOT_GENERATE_BROADCAST_INFO_FOR_QUALITYVBR | announcement or stream-format generation cannot represent quality-based VBR output before encoding |
Safe recovery
Resolve the producing condition by ensuring that you use a packet size in the range accepted by the selected output transport. Then rebuild only the portion of the Encoder graph affected by it and verify the original call.
Do not change the source and codec while testing a distribution-only failure; first prove that the same profile writes a local file and preserve the output configuration in a session that returns it.
Source material
- WMEncoder.Broadcast.
- Generating an announcement file.
- Generating multicast information.
- WMEncoder.File and archive output.
Looking for a different code? Search another status or error code.