What causes ""${name}" must be >= 1" in remotion-dev/remotion?

Set startBlockSize/endBlockSize to >= 1 (use 1 for 'no pixelation').

remotion-dev/remotion · error · TypeError

"${name}" must be >= 1

Error message

"${name}" must be >= 1

What it means

Thrown by validateBlockSize() in the linear-progressive-pixelate effect when startBlockSize or endBlockSize (after applying the default of 1/40) is less than 1. Block size is the pixelation cell size and must be a positive integer-or-number >= 1, so 0 or negative values are rejected at setup.

Source

Thrown at packages/effects/src/linear-progressive-pixelate/index.ts:110

});

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: LinearProgressivePixelateParams): void => {
	assertEffectParamsObject(params, 'Linear progressive pixelate');
	assertOptionalUvCoordinate(params.start, 'start');
	assertOptionalUvCoordinate(params.end, 'end');
	assertOptionalFiniteNumber(params.startBlockSize, 'startBlockSize');
	assertOptionalFiniteNumber(params.endBlockSize, 'endBlockSize');
	validateBlockSize(
		params.startBlockSize ?? DEFAULT_START_BLOCK_SIZE,
		'startBlockSize',
	);
	validateBlockSize(
		params.endBlockSize ?? DEFAULT_END_BLOCK_SIZE,
		'endBlockSize',
	);
};

View on GitHub (pinned to 78fe4bb3fd)

Solutions

Set startBlockSize/endBlockSize to >= 1 (use 1 for 'no pixelation').
When animating, clamp the value: Math.max(1, interpolate({ input, range, output: [...] })).
Pass `undefined` (or omit) to use the defaults rather than 0.
If you need a smooth 'pixelate in' transition, animate from 1 upward, never from 0.

Example fix

// before
linearProgressivePixelate({ endBlockSize: interpolate({ input: frame, range: [0, 30], range: [0, 40] }) });

// after — clamp so the value never drops below 1
const size = Math.max(1, interpolate({ input: frame, range: [0, 30], output: [1, 40], extrapolateLeft: 'clamp', extrapolateRight: 'clamp' }));
linearProgressivePixelate({ endBlockSize: size });

Defensive patterns

Strategy: validation

Validate before calling

import {interpolate} from 'remotion';

// Clamp any animated block size so the effect never sees a value < 1.
const safeBlockSize = (v: number) => Math.max(1, v);

const endBlockSize = safeBlockSize(
  interpolate({input: frame, range: [0, 30], output: [1, 40], extrapolateLeft: 'clamp', extrapolateRight: 'clamp'})
);
linearProgressivePixelate({ endBlockSize });

Type guard

const isValidBlockSize = (v: unknown): v is number =>
  typeof v === 'number' && Number.isFinite(v) && v >= 1;

Prevention

Always set startBlockSize/endBlockSize to >= 1; use 1 for 'no pixelation'.
Clamp animated block sizes with Math.max(1, ...) and interpolate's clamp extrapolation.
Omit the field to accept the default rather than passing 0.
Animate pixelate transitions from 1 upward, never from 0.

When it happens

Trigger: Calling linearProgressivePixelate({ startBlockSize: 0 }) or with a negative value, or animating endBlockSize with interpolate and letting it cross below 1. Because the default is substituted before validation, even passing `undefined` is safe — only an explicit <1 number triggers it.

Common situations: Animators driving block size to 0 at the start of a transition; passing a fractional value < 1 thinking it means 'sub-pixel'; copy-pasting a value from a different effect whose minimum is 0; off-by-one in interpolate's `extrapolateLeft/Right` clamping.

Related errors

AI-assisted analysis of remotion-dev/remotion@78fe4bb3fd (2026-08-12). Data as JSON: /api/errors/0a26781e9b6bd805. Report an issue: GitHub.