remotion-dev/remotion · error · TypeError
"${name}" must be >= 1
Error message
"${name}" must be >= 1 What it means
The radialProgressivePixelate effect validates that numeric block-size parameters are at least 1. If a value less than 1 is supplied, the effect throws a TypeError because sub-pixel block sizes are physically meaningless and would produce undefined pixelation behavior.
Source
Thrown at packages/effects/src/radial-progressive-pixelate/index.ts:153
});
const assertOptionalUvCoordinate = (value: unknown, name: string): void => {
if (value === undefined) {
return;
}
if (
!Array.isArray(value) ||
value.length !== 2 ||
value.some((item) => typeof item !== 'number' || !Number.isFinite(item))
) {
throw new TypeError(`"${name}" must be a [number, number] tuple`);
}
};
const validateBlockSize = (value: number, name: string): void => {
if (value < 1) {
throw new TypeError(`"${name}" must be >= 1`);
}
};
const validateParams = (params: RadialProgressivePixelateParams): void => {
assertEffectParamsObject(params, 'Radial progressive pixelate');
assertOptionalUvCoordinate(params.center, 'center');
assertOptionalFiniteNumber(params.width, 'width');
assertOptionalFiniteNumber(params.height, 'height');
assertOptionalFiniteNumber(params.rotation, 'rotation');
validateNonNegative(params.width ?? DEFAULT_WIDTH, 'width');
validateNonNegative(params.height ?? DEFAULT_HEIGHT, 'height');
assertOptionalFiniteNumber(params.start, 'start');
validateUnitInterval(params.start ?? DEFAULT_START, 'start');
assertOptionalFiniteNumber(params.startBlockSize, 'startBlockSize');
assertOptionalFiniteNumber(params.endBlockSize, 'endBlockSize');
validateBlockSize(
params.startBlockSize ?? DEFAULT_START_BLOCK_SIZE,
'startBlockSize',View on GitHub (pinned to 78fe4bb3fd)
Solutions
- Pass a block size of 1 or greater (e.g. 8, 16, 32 for typical pixelation looks)
- Clamp computed values: blockSize: Math.max(1, computedBlockSize)
- If the parameter is optional, omit it entirely to use the default
- Validate with a unit test that your dynamic block-size formula never yields a value below 1
Example fix
// before
radialProgressivePixelate({ blockSize: 0 })
// after
radialProgressivePixelate({ blockSize: Math.max(1, Math.round(width / 100)) }) Defensive patterns
Strategy: validation
Validate before calling
const blockSize = Math.max(1, Math.round(width / 100));
if (blockSize < 1) throw new Error('blockSize must be >= 1');
radialProgressivePixelate({ blockSize }); Prevention
- Clamp computed block sizes with Math.max(1, value) before passing
- Use integer values; sub-1 values are meaningless for pixelation
- Unit-test dynamic block-size formulas across expected resolution ranges
When it happens
Trigger: Passing blockSize: 0, blockSize: 0.5, or blockSize: -4. The check fires after assertOptionalFiniteNumber confirms the value is a valid finite number, so this strictly catches the range violation.
Common situations: Accidentally passing 0 as a default/uninitialized value; computing block size from a ratio that rounds down to zero at small resolutions; negative values from a subtractive calculation.
Related errors
- "${name}" must be a [number, number] tuple
- "${name}" must be greater than 0, but got ${JSON.stringify(v
- inputRange must contain only numbers
- outputStyles must contain only objects
- Argument passed to "${api}" for param "${param}" is undefine
AI-assisted analysis of remotion-dev/remotion@78fe4bb3fd (2026-08-12).
Data as JSON: /api/errors/22d49b83343873e1.
Report an issue: GitHub.