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

What it means

Thrown by MediaPlayer in @remotion/media when the resolved video track reports timestamps relative to the Unix epoch. Remotion assumes media starts at time zero and seeks by offset; Unix-epoch-anchored streams (common in some broadcast/RTMP captures) break that assumption, so decoding is rejected. Fires at media-player.ts:316 during the video track decode path.

Source

Thrown at packages/media/src/media-player.ts:316

				videoTrack,
				audioTracks,
				audioStreamIndex: this.audioStreamIndex,
			});

			if (!videoTrack && !audioTrack) {
				return {type: 'no-tracks'};
			}

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

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

				const canDecode = await videoTrack.canDecode();

				if (!canDecode) {
					if (videoTrack.codec === 'prores') {
						return {type: 'cannot-decode-prores'};
					}

					return {type: 'cannot-decode'};
				}

				if (this.isDisposalError()) {
					return {type: 'disposed'};
				}

View on GitHub (pinned to 78fe4bb3fd)

Solutions

Re-mux or transcode the source so timestamps start at zero (e.g. ffmpeg -fflags +genpts -avoid_negative_ts make_zero).
Use ffmpeg to normalize: ffmpeg -i input.ts -use_wallclock_as_timestamps 0 -copyts -reset_timestamps 1 out.mp4.
Source a clean MP4/WebM instead of a raw broadcast capture.

Example fix

# before: raw TS capture fed directly
remotion render --props='{"src":"capture.ts"}'

# after: normalize timestamps first
ffmpeg -i capture.ts -fflags +genpts -avoid_negative_ts make_zero out.mp4
remotion render --props='{"src":"out.mp4"}'

Defensive patterns

Strategy: validation

Validate before calling

null

Try / catch

// Pre-process the file rather than catching at runtime:
// ffmpeg -fflags +genpts -avoid_negative_ts make_zero
// No robust runtime fallback exists.

Prevention

Normalize timestamps of any broadcast/TS source with ffmpeg before ingestion.
Reject raw transport-stream uploads at the input boundary.
Prefer MP4/WebM sources with zero-based PTS.

When it happens

Trigger: A media source whose container embeds absolute Unix-epoch timestamps (e.g. certain MPEG-TS captures from RTMP/ATSC streams). The track's isRelativeToUnixEpoch() promise resolves true.

Common situations: Feeding Remotion a raw transport stream recorded from a live broadcast, or an HLS segment captured with wall-clock timestamps. Common when ingesting unprocessed broadcast or IPTV captures.

Related errors

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