remotion-dev/remotion · warning · Error

Weird size for number ${size}

Error message

Weird size for number ${size}

What it means

Thrown in the ilst (iTunes metadata) parser for well-known type 21 (signed integer). The value's byte size is not one of {1,2,3,4,8}, so no matching signed integer reader exists. The parser refuses to guess the integer width and aborts.

Source

Thrown at packages/media-parser/src/containers/iso-base-media/meta/ilst.ts:59

		}

		if (size === 2) {
			return {type: 'number', value: iterator.getInt16()};
		}

		if (size === 3) {
			return {type: 'number', value: iterator.getInt24()};
		}

		if (size === 4) {
			return {type: 'number', value: iterator.getInt32()};
		}

		if (size === 8) {
			return {type: 'number', value: Number(iterator.getInt64())};
		}

		throw new Error(`Weird size for number ${size}`);
	}

	if (wellKnownType === 22) {
		if (size === 1) {
			return {type: 'number', value: iterator.getUint8()};
		}

		if (size === 2) {
			return {type: 'number', value: iterator.getUint16()};
		}

		if (size === 3) {
			return {type: 'number', value: iterator.getUint24()};
		}

		if (size === 4) {
			return {type: 'number', value: iterator.getUint32()};
		}

View on GitHub (pinned to 78fe4bb3fd)

Solutions

1. Strip/rebuild iTunes metadata: ffmpeg -i in.m4a -map_metadata -1 -c copy out.m4a, then re-tag with a compliant tool.
2. Re-mux: ffmpeg -i in.m4a -c copy out.m4a.
3. Use a tag editor (Kid3/mp3tag) to repair or remove the offending tag, then parse.
4. Migrate to @remotion/mediabunny (parseMedia is deprecated).

Example fix

// before
const {metadata} = await parseMedia({src: taggedM4a, reader: nodeReader});

// after
try {
  const {metadata} = await parseMedia({src: taggedM4a, reader: nodeReader});
} catch (err) {
  if (err instanceof Error && /Weird size for number/.test(err.message)) {
    // ilst metadata atom corrupt — strip metadata and re-mux
    // ffmpeg -i taggedM4a -map_metadata -1 -c copy out.m4a
  } else throw err;
}

// iTunes metadata is non-essential; pre-check by re-muxing without metadata
// only if you know you don't need it. Quick validation:
//   ffprobe -v error -show_entries format_tags -of json in.m4a
import {execFileSync} from 'node:child_process';
function metadataParses(file: string): boolean {
  try {
    execFileSync('ffprobe', ['-v','error','-show_entries','format_tags','-of','json', file], {encoding:'utf8', stdio:'pipe'});
    return true;
  } catch { return false; }
}

// ilst values are deep binary metadata; not type-guardable from the caller.
// => typeGuard: null

try {
  const {metadata} = await parseMedia({src, reader: nodeReader});
} catch (err) {
  if (err instanceof Error && /Weird size for number/.test(err.message)) {
    // type-21 signed-integer ilst entry corrupt; strip metadata and re-mux
  } else {
    throw err;
  }
}

When it happens

Trigger: parseMedia({src}) on an MP4/M4A/MOV whose ilst atom contains a type-21 (signed integer) metadata value with a non-standard size (not 1/2/3/4/8 bytes). Usually a corrupt or hand-edited metadata atom.

Common situations: M4A files with damaged iTunes tags; files whose metadata was rewritten by a buggy tagger; non-Apple muxers emitting malformed ilst numbers.

Related errors

• Expected type indicator to be 0
• Invalid ICC profile size
• Invalid ICC profile signature
• Could not find number of channels
• Could not find sample rate

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