What causes "Not enough data to get track number, should not happen" in remotion-dev/remotion?

Verify the source is a complete file: check file size / re-download / compare to a known-good copy.

remotion-dev/remotion · error · Error

Not enough data to get track number, should not happen

Error message

Not enough data to get track number, should not happen

What it means

Thrown at get-sample-from-block.ts:135 when `iterator.getVint()` returns null while reading the track-number Vint at the start of a Matroska Block/SimpleBlock payload. The message 'should not happen' reflects that a Block should always carry at least one track-number byte; reaching EOF means the Block element's declared size exceeded its actual data.

Source

Thrown at packages/media-parser/src/containers/webm/get-sample-from-block.ts:135

	avcState,
}: {
	ebml: BlockSegment | SimpleBlockSegment;
	webmState: WebmState;
	offset: number;
	structureState: StructureState;
	callbacks: CallbacksState;
	logLevel: MediaParserLogLevel;
	onVideoTrack: MediaParserOnVideoTrack | null;
	avcState: AvcState;
}): Promise<SampleResult> => {
	const iterator = getArrayBufferIterator({
		initialData: ebml.value,
		maxBytes: ebml.value.length,
		logLevel: 'error',
	});
	const trackNumber = iterator.getVint();
	if (trackNumber === null) {
		throw new Error('Not enough data to get track number, should not happen');
	}

	const timecodeRelativeToCluster = iterator.getInt16();

	const {keyframe} = parseBlockFlags(
		iterator,
		ebml.type === 'SimpleBlock'
			? matroskaElements.SimpleBlock
			: matroskaElements.Block,
	);

	const {codec, trackTimescale} = webmState.getTrackInfoByNumber(trackNumber);

	const clusterOffset = webmState.getTimestampOffsetForByteOffset(offset);

	const timescale = webmState.getTimescale();

	if (clusterOffset === undefined) {

View on GitHub (pinned to 78fe4bb3fd)

Solutions

Verify the source is a complete file: check file size / re-download / compare to a known-good copy.
If streaming, ensure the reader delivers the full Block payload before the parser consumes it; prefer a buffered File/Blob source.
Re-mux with ffmpeg to repair truncation: `ffmpeg -i broken.webm -c copy repaired.webm` (ffmpeg will skip incomplete blocks).
Catch the error and treat the asset as unreadable rather than crashing.

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-check: ensure the source is a complete, non-truncated file.
async function isComplete(src) {
  if (src instanceof File || src instanceof Blob) {
    return src.size > 0;
  }
  if (typeof src === 'string') {
    const res = await fetch(src, { method: 'HEAD' });
    return res.ok && Number(res.headers.get('content-length') ?? 0) > 0;
  }
  return true;
}

Try / catch

try {
  await parseMedia({ src, fields: { samples: true } });
} catch (err) {
  if (err instanceof Error && /should not happen/.test(err.message)) {
    // Block payload was truncated — file is incomplete or corrupt.
    console.warn('Truncated WebM block in', src, '— re-download or re-mux.');
    return null;
  }
  throw err;
}

Prevention

Prefer complete File/Blob sources over live network streams for WebM parsing.
Verify downloads completed fully (compare Content-Length to actual bytes).
Re-mux truncated files with ffmpeg before parsing: ffmpeg skips incomplete blocks.
For streaming sources, ensure the reader buffers entire Block payloads before yielding them.

When it happens

Trigger: Parsing a `Block` or `SimpleBlock` element whose `ebml.value` buffer is empty or shorter than a Vint (≥1 byte). Caused by truncated cluster data, a wrong element size in the EBML, or a partially flushed stream read.

Common situations: Streaming a WebM over an unreliable network where the connection drops mid-cluster; files truncated by an interrupted recording (screen recorders, live streams); incorrect Content-Length on a fetch response feeding the parser reader.

Related errors

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