remotion-dev/remotion · error · Error

Streams with UNIX timestamps are not currently supported by…

Error message

Streams with UNIX timestamps are not currently supported by Remotion. Sorry! Source: ${typeof src === 'string' ? src : `audio track ${src.id}`}

What it means

After excluding live streams, loadWaveformPeaks rejects audio tracks whose timestamps are relative to the UNIX epoch (isRelativeToUnixEpoch()). Such streams cannot be mapped onto the timeline's expected time base, so the function throws with the offending source identified in the message.

Solutions

Re-encode/remux the audio so timestamps are media-relative (e.g. ffmpeg -i in.ts -c copy -muxer-relative out.ts or re-encode to MP4).
Convert the asset to a standard format like MP3/WAV/M4A before loading.
Check the source container — replace formats that embed epoch-based timestamps.
If programmatic, strip or remap the epoch timestamp track before passing the source.

Example fix

// before
loadWaveformPeaks('capture-2024-01-01.ts');
// after (remux with relative timestamps first)
// ffmpeg -i capture-2024-01-01.ts -c copy -fflags +genpts -muxer-relative capture-fixed.ts
loadWaveformPeaks('capture-fixed.ts');

Defensive patterns

Strategy: try-catch

Validate before calling

if (await audioTrack.isRelativeToUnixEpoch()) {
  throw new Error('Epoch-timestamped track needs remuxing first');
}

Try / catch

try {
  await loadWaveformPeaks(src);
} catch (e) {
  if (e.message.includes('UNIX timestamps')) {
    src = await remuxWithRelativeTimestamps(src); // e.g. via ffmpeg
    return loadWaveformPeaks(src);
  }
  throw e;
}

Prevention

Convert broadcast/TS captures to MP4/MP3 with relative timestamps before ingest.
Run ffprobe to inspect stream time bases for suspicious start times.
Prefer standard audio containers for all composition assets.
Catch this error and auto-remux in ingestion pipelines.

When it happens

Trigger: Loading waveform peaks from an audio source whose track reports isRelativeToUnixEpoch() === true — e.g. certain broadcast/binary formats with absolute epoch timestamps rather than media-relative timestamps.

Common situations: Ingesting capture/broadcast recordings (e.g. some MPEG-TS captures) or sensor recordings where audio sample timestamps are wall-clock epoch values.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of remotion-dev/remotion@b2f4e34732 (2026-09-09). Data as JSON: /api/errors/45f0d5b4f0a81993. Report an issue: GitHub.

Appendix: source

Thrown at packages/timeline-utils/src/audio-waveform/load-waveform-peaks.ts:79

			? new Input({formats: ALL_FORMATS, source: new UrlSource(src)})
			: null;

	try {
		const audioTrack =
			typeof src === 'string' ? await input!.getPrimaryAudioTrack() : src;
		if (!audioTrack) {
			return {peaks: new Float32Array(0), averageVolume: null};
		}

		if (await audioTrack.isLive()) {
			throw new Error(
				'Live streams are not currently supported by Remotion. Sorry! Source: ' +
					(typeof src === 'string' ? src : `audio track ${src.id}`),
			);
		}

		if (await audioTrack.isRelativeToUnixEpoch()) {
			throw new Error(
				'Streams with UNIX timestamps are not currently supported by Remotion. Sorry! Source: ' +
					(typeof src === 'string' ? src : `audio track ${src.id}`),
			);
		}

		const audioSampleRate = await audioTrack.getSampleRate();
		const durationInSeconds =
			(await audioTrack.getDurationFromMetadata({skipLiveWait: true})) ??
			(await audioTrack.computeDuration({skipLiveWait: true}));
		const totalPeaks = Math.ceil(durationInSeconds * waveformSampleRate);
		const samplesPerPeak = Math.max(
			1,
			Math.floor(audioSampleRate / waveformSampleRate),
		);

		const sink = new AudioSampleSink(audioTrack);
		const processor = createWaveformPeakProcessor({
			totalPeaks,

View on GitHub (pinned to b2f4e34732)