remotion-dev/remotion · error
Invalid channel count: ${bits.toString(2)}
Error message
Invalid channel count: ${bits.toString(2)} What it means
Thrown by getChannelCount() when the 4-bit channel-assignment field in a FLAC frame header does not match any handled value. The function maps 0b0000-0b0111 to 1-8 channels, 0b1000-0b1010 to stereo (left/right/side channel decorrelation), and 0b1011-0b1111 are treated leniently as stereo. Since every 4-bit value (0-15) is handled by a prior branch, this throw is effectively unreachable defensive code.
Source
Thrown at packages/media-parser/src/containers/flac/get-channel-count.ts:49
return 7;
}
if (bits === 0b0111) {
return 8;
}
if (bits === 0b1000 || bits === 0b1001 || bits === 0b1010) {
return 2;
}
// 0b1011..0b1111 are reserved per RFC 9639 §9.1.3 (Channels Bits).
// Some encoders/files in the wild may nonetheless use these values.
// Be lenient and treat them as stereo (2 channels) to keep parsing robust.
if (bits >= 0b1011 && bits <= 0b1111) {
return 2;
}
throw new Error(`Invalid channel count: ${bits.toString(2)}`);
};
View on GitHub (pinned to 78fe4bb3fd)
Solutions
- If you encounter this, report it as a bug to the Remotion team with the reproducing FLAC file.
- Update to the latest @remotion/media-parser version.
- Switch to Mediabunny (https://www.remotion.dev/docs/mediabunny/metadata).
Defensive patterns
Strategy: try-catch
Try / catch
try {
const result = await parseMedia({src, fields: {numberOfAudioChannels: true}});
} catch (e) {
if (e instanceof Error && e.message.startsWith('Invalid channel count:')) {
// This is effectively unreachable; if hit, report as internal bug
console.error('Internal parser error in FLAC channel count. Report this file to Remotion.');
} else {
throw e;
}
} Prevention
- Keep @remotion/media-parser updated to the latest version.
- If this error appears, report the file as a potential internal bug to Remotion.
- Migrate to Mediabunny as a more robust alternative.
When it happens
Trigger: Logically unreachable: all 16 possible 4-bit values (0b0000 through 0b1111) are handled. Would only fire if the iterator's getBits() returned a value outside [0, 15] due to an internal bug, or if branch logic were modified to create a gap.
Common situations: Should never occur in normal operation. If seen, it signals an internal bug in the bit-reading iterator or an unintended edit to the function's control flow.
Related errors
- Invalid block size
- Invalid sample rate mode: ${mode.toString(2)}
- Blocking bit should be set
- Streaminfo not found
- Sample rate not found
AI-assisted analysis of remotion-dev/remotion@78fe4bb3fd (2026-08-12).
Data as JSON: /api/errors/1d78db87a6e73426.
Report an issue: GitHub.