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
- Re-mux with ffmpeg to rebuild correct box sizes: `ffmpeg -i in.mp4 -c copy -movflags faststart out.mp4`.
- Inspect the failing file with `mp4dump` or `ffprobe -show_format` to find the malformed box.
- If you control the parser feed, double-check that contentLength passed to getIsoBaseMediaChildren matches the real byte count.
- 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
- Treat 'read too many bytes' as definitive corruption and discard the asset.
- Verify your readerInterface returns exactly the requested byte range.
- Re-mux user uploads with ffmpeg as a normalization step.
- Capture the size/read/offset values from the error for bug reports.
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
- Expected remaining bytes to be 0, got ${remaining}
- expected 0 bytes ${bytesRemaining}
- Expected box size of ${bytesRemaining}, got ${boxSize}
- Expected stsz box in trak box
- Expected stco box in trak box
AI-assisted analysis of remotion-dev/remotion@78fe4bb3fd (2026-08-12).
Data as JSON: /api/errors/6dc0ca533b2830ed.
Report an issue: GitHub.