remotion-dev/remotion · warning · Error

Expected type indicator to be 0

Error message

Expected type indicator to be 0

What it means

Thrown in parseIlstBox() after reading the ilst data atom's type-indicator byte. The QuickTime/iTunes spec requires the type indicator to be 0 for the well-known-type encoding this parser expects; any other value is rejected because the subsequent wellKnownType (getUint24) would be misaligned/meaningless.

Source

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

			// "----" atom in m4a files
			// iTunes adds it for .m4a files
			// not very interesting data, so we don't parse them
			if (index === '----') {
				iterator.discard(metadataSize - 8);
				continue;
			}

			iterator.discard(metadataSize - 8);
			continue;
		}

		const innerSize = iterator.getUint32();
		const type = iterator.getAtom();
		const typeIndicator = iterator.getUint8();

		if (typeIndicator !== 0) {
			throw new Error('Expected type indicator to be 0');
		}

		const wellKnownType = iterator.getUint24();
		iterator.discard(4);
		const value = parseFromWellKnownType(
			wellKnownType,
			iterator,
			innerSize - 16,
		);
		entries.push({index, type, wellKnownType, value});
	}

	box.discardRest();

	return {
		type: 'ilst-box',
		boxSize: size,
		offset,

View on GitHub (pinned to 78fe4bb3fd)

Solutions

1. Strip and rebuild metadata: ffmpeg -i in.m4a -map_metadata -1 -c copy out.m4a.
2. Re-tag with a compliant tool (Kid3/mp3tag) if you need metadata.
3. Re-mux the whole file: ffmpeg -i in.file -c copy out.mp4.
4. Migrate to @remotion/mediabunny (parseMedia is deprecated).

Example fix

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

// after
try {
  const r = await parseMedia({src, reader: nodeReader});
} catch (err) {
  if (err instanceof Error && /Expected type indicator to be 0/.test(err.message)) {
    // ilst encoding not supported; strip metadata and re-mux
  } else throw err;
}

// Validate ffprobe reads the tags cleanly before parsing:
//   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; }
}

// The ilst type-indicator byte is deep binary metadata; not caller-type-guardable.
// => typeGuard: null

try {
  const {metadata} = await parseMedia({src, reader: nodeReader});
} catch (err) {
  if (err instanceof Error && /Expected type indicator to be 0/.test(err.message)) {
    // ilst uses an unsupported encoding; strip metadata and re-mux
  } else {
    throw err;
  }
}

When it happens

Trigger: parseMedia({src}) on a file whose ilst data atom has a type indicator byte != 0 — i.e. a metadata atom using a different (UTF-8/variant) encoding or a corrupted indicator byte. The parser only handles the 'well-known type' (indicator 0) encoding.

Common situations: M4A/MOV files with non-Apple-style metadata encodings, or corrupt/hand-edited ilst atoms where the indicator byte is wrong.

Related errors

• Weird size for number ${size}
• 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/4bb8e88178656628. Report an issue: GitHub.