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: ${src}

What it means

Thrown inside useWindowedAudioData() when mediabunny reports the source uses absolute UNIX-epoch timestamps (audioTrack.isRelativeToUnixEpoch() === true, line 143-148). Remotion schedules audio on a timeline relative to composition frame 0; epoch-anchored timestamps (common in some RTMP/production captures and SCTE-35 marked streams) cannot be mapped onto that timeline deterministically, so they are rejected. The src is included in the message.

Source

Thrown at packages/media-utils/src/use-windowed-audio-data.ts:144

			try {
				const durationInSeconds = await input.computeDuration();

				const audioTrack = await input.getPrimaryAudioTrack();

				if (!audioTrack) {
					throw new Error('No audio track found');
				}

				if (await audioTrack.isLive()) {
					throw new Error(
						'Live streams are not currently supported by Remotion. Sorry! Source: ' +
							src,
					);
				}

				if (await audioTrack.isRelativeToUnixEpoch()) {
					throw new Error(
						'Streams with UNIX timestamps are not currently supported by Remotion. Sorry! Source: ' +
							src,
					);
				}

				const canDecode = await audioTrack.canDecode();

				if (!canDecode) {
					throw new Error('Audio track cannot be decoded');
				}

				if (channelIndex >= audioTrack.numberOfChannels || channelIndex < 0) {
					throw new Error(
						`Invalid channel index ${channelIndex} for audio with ${audioTrack.numberOfChannels} channels`,
					);
				}

				const numberOfChannels = await audioTrack.getNumberOfChannels();

View on GitHub (pinned to 78fe4bb3fd)

Solutions

Re-mux the asset so PTS is zero-based: ffmpeg -i in.ts -c copy -avoid_negative_ts make_zero out.mp4.
Re-encode from the original with a normal timeline (ffmpeg -i in.ts -c:a aac -c:v libx264 out.mp4).
Source a clean export from your NLE/editor instead of the raw capture.
If you need epoch timestamps for live-event replay, preprocess the stream offline before handing it to Remotion.

Example fix

// before (broadcast capture with UNIX PTS -> rejected)
useWindowedAudioData({src: staticFile('capture.ts'), ...});

// after (zero-base the timeline first)
// ffmpeg -i capture.ts -c copy -avoid_negative_ts make_zero capture-clean.mp4
useWindowedAudioData({src: staticFile('capture-clean.mp4'), ...});

Defensive patterns

Strategy: validation

Validate before calling

// Pre-process the asset so PTS is zero-based before handing it to Remotion
import {execSync} from 'child_process';

function ensureZeroBasedTimestamps(inputFile: string, outputFile: string) {
  execSync(`ffmpeg -y -i ${inputFile} -c copy -avoid_negative_ts make_zero ${outputFile}`);
}

// Or detect before rendering:
async function usesUnixEpochTimestamps(src: string): Promise<boolean> {
  const {Input} = await import('mediabunny');
  const input = new Input({source: src});
  try {
    const track = await input.getPrimaryAudioTrack();
    return track ? await track.isRelativeToUnixEpoch() : false;
  } finally {
    input.dispose();
  }
}

Type guard

// (Same shape as usesUnixEpochTimestamps above; returns boolean)

Try / catch

// Forwarded to cancelRender(); wrap an ErrorBoundary and fall back to a re-muxed asset:
// <ErrorBoundary fallback={<Waveform src={staticFile('clean.mp4')} ... />}>
//   <WindowedWaveform src={rawCapture} ... />
// </ErrorBoundary>

Prevention

Avoid feeding raw broadcast/ingestion captures directly to Remotion.
Re-mux with -avoid_negative_ts make_zero or re-encode to ensure a zero-based timeline.
Prefer NLE/editor exports over field-captured transport streams.
Probe new asset sources once and cache the 'is epoch-based' flag to avoid re-rendering surprises.

When it happens

Trigger: Loading RTMP captures, certain MPEG-TS streams with PCR/PTS anchored to wall-clock, SCTE-35 timestamped broadcast captures, or production recorder outputs that write absolute timestamps rather than zero-based PTS.

Common situations: Re-using broadcast ingestion media inside a Remotion composition; pulling a transport stream recorded by a live switcher; mixing media from NLE exports (zero-based) with field-captured media (epoch-based).

Related errors

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