remotion-dev/remotion · error · Error

read too many bytes - size: ${size}, read: ${iterator.counte

Error message

read too many bytes - size: ${size}, read: ${iterator.counter.getOffset() - initial}. initial offset: ${initial}

What it means

Thrown by getIsoBaseMediaChildren after the child-parsing loop when iterator.counter.getOffset() exceeds the parent box's declared size (size + initial offset). This means one of the child box parsers consumed more bytes than the parent said it should contain — a structural inconsistency. The error message includes the declared size, the bytes actually consumed, and the entry offset to aid diagnosis.

Source

Thrown at packages/media-parser/src/containers/iso-base-media/get-children.ts:39

	const initial = iterator.counter.getOffset();

	while (iterator.counter.getOffset() < size + initial) {
		const parsed = await processBox({
			iterator,
			logLevel,
			onlyIfMoovAtomExpected,
			onlyIfMdatAtomExpected: null,
			contentLength,
		});
		if (parsed.type !== 'box') {
			throw new Error('Expected box');
		}

		boxes.push(parsed.box);
	}

	if (iterator.counter.getOffset() > size + initial) {
		throw new Error(
			`read too many bytes - size: ${size}, read: ${iterator.counter.getOffset() - initial}. initial offset: ${initial}`,
		);
	}

	return boxes;
};

View on GitHub (pinned to 78fe4bb3fd)

Solutions

  1. Re-mux with ffmpeg to rebuild correct box sizes: `ffmpeg -i in.mp4 -c copy -movflags faststart out.mp4`.
  2. Inspect the failing file with `mp4dump` or `ffprobe -show_format` to find the malformed box.
  3. If you control the parser feed, double-check that contentLength passed to getIsoBaseMediaChildren matches the real byte count.
  4. Report a media-parser issue including the size/read/offset values from the error message.

Example fix

// before
const boxes = await getIsoBaseMediaChildren({ size, iterator, logLevel, onlyIfMoovAtomExpected, contentLength });

// after
try {
  const boxes = await getIsoBaseMediaChildren({ size, iterator, logLevel, onlyIfMoovAtomExpected, contentLength });
} catch (err) {
  if (/read too many bytes/.test(String(err?.message))) {
    throw new Error('MP4 box size header is inconsistent with its contents. The file is corrupt; re-mux it with ffmpeg.');
  }
  throw err;
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Use mp4dump or ffprobe to detect inconsistent box sizes before deep parsing
import {execFileSync} from 'node:child_process';
function boxSizesAreConsistent(file: string): boolean {
  try {
    execFileSync('mp4dump', [file], {encoding: 'utf8'});
    return true;
  } catch { return false; }
}

Try / catch

try {
  const boxes = await getIsoBaseMediaChildren({ size, iterator, logLevel, onlyIfMoovAtomExpected, contentLength });
} catch (err) {
  if (/read too many bytes/.test(String(err?.message))) {
    throw new Error('MP4 box sizes are internally inconsistent. The file is corrupt; re-mux it.');
  }
  throw err;
}

Prevention

When it happens

Trigger: A child box reports a size that, when consumed, overshoots the parent's declared size. Causes: corrupt size fields in either parent or child, a parser that over-reads a sub-box, a 64-bit vs 32-bit size confusion (largesize), or a buffer that contains bytes from the next sibling parsed as part of the current child.

Common situations: Files edited/hex-patched incorrectly. Muxers with off-by-one or alignment bugs. Streams where a content-length mismatch causes the parser to over-consume. Version regressions in the media-parser box readers.

Related errors


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