What causes "No bitrate info" in remotion-dev/remotion?

Re-encode the MP3 file with a standard encoder (LAME via ffmpeg) to produce a well-formed file.

remotion-dev/remotion · error · Error

No bitrate info

Error message

No bitrate info

What it means

Thrown by `parseMpegHeader` when, after parsing a frame, `state.mp3.getMp3BitrateInfo()` returns null/falsy. The bitrate info should have been set earlier in the flow (either as CBR via `setMp3BitrateInfo` or VBR via Xing); reaching this point with no bitrate info indicates an internal state inconsistency.

Source

Thrown at packages/media-parser/src/containers/mp3/parse-mpeg-header.ts:120

				timescale: WEBCODECS_TIMESCALE,
				trackMediaTimeOffsetInTrackTimescale: 0,
			},
			registerAudioSampleCallback: state.callbacks.registerAudioSampleCallback,
			tracks: state.callbacks.tracks,
			logLevel: state.logLevel,
			onAudioTrack: state.onAudioTrack,
		});
		state.callbacks.tracks.setIsDone(state.logLevel);

		state.mediaSection.addMediaSection({
			start: initialOffset,
			size: state.contentLength - initialOffset,
		});
	}

	const bitrateInfo = state.mp3.getMp3BitrateInfo();
	if (!bitrateInfo) {
		throw new Error('No bitrate info');
	}

	const sample =
		bitrateInfo.type === 'constant'
			? getAudioSampleFromCbr({
					bitrateInKbit,
					data,
					initialOffset,
					layer,
					sampleRate,
					samplesPerFrame,
					state,
				})
			: getAudioSampleFromVbr({
					data,
					info: bitrateInfo,
					mp3Info: state.mp3.getMp3Info(),
					position: initialOffset,

View on GitHub (pinned to 78fe4bb3fd)

Solutions

Re-encode the MP3 file with a standard encoder (LAME via ffmpeg) to produce a well-formed file.
If the file has an `Info` tag instead of `Xing`, re-encode to ensure proper header structure.
Report the file at remotion.dev/report as it may represent an unhandled edge case.
Wrap `parseMedia` in try-catch and fall back to a re-encoded version of the file.

Example fix

# re-encode to produce a clean MP3
ffmpeg -i input.mp3 -codec:a libmp3lame -b:a 192k output.mp3

Defensive patterns

Strategy: try-catch

Try / catch

try {
  await parseMedia({src, fields: {durationInSeconds: true}});
} catch (e) {
  if (e instanceof Error && e.message === 'No bitrate info') {
    console.error('Internal parser state error. The MP3 may have an unusual header structure.');
  }
  throw e;
}

Prevention

Re-encode unusual MP3 files with a standard encoder (LAME via ffmpeg).
Avoid MP3 files with Info tags if they cause parsing issues; use Xing or pure CBR.
Report files that trigger this at remotion.dev/report.
Validate files with ffprobe before parsing.

When it happens

Trigger: Reached in `parse-mpeg-header.ts:118-121` when `state.callbacks.tracks.getTracks().length` was non-zero (i.e., not the first frame) and the bitrate info was never set, or when the first-frame branch returned early (`Info` header detected at line 62-64) without setting bitrate info and then continued to line 118.

Common situations: An MP3 file with an `Info` (non-VBR CBR marker) header that causes the first-frame branch to return early at line 63, but the bitrate info was never populated, and subsequent frames reach the bitrate-info check. Internal logic bugs where `setMp3BitrateInfo` is skipped. Edge-case files that trigger unusual control flow.

Related errors

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