How do I optimise the remotion player?

[gajraj-gan]

Hi,

I am trying to optimise the remotion player, i have bunch of transitionSeries.Sequence and transitionSeries.Transition, in form of Sequence -> Transition -> Sequence -> Transition and so on.....the thing the components inside my Sequence are getting heavy, I have noticed all the sequence are rendered at once and they are behind each other altho only one is visible at a time.

When I play the player, the components using useCurrentFrame start re rendering, I thought they were bound to the nearest sequence and others should not start re rendering ? Is this obvious behavior or am I missing something?

[Akkikens]

Biggest wins, roughly in order of impact:

1. Memoize everything — the Player re-renders your component tree every frame (30–60x/sec). Wrap inputProps in useMemo, wrap child components in React.memo, and hoist any expensive computation out of the render path.
2. Precompute per-frame math — anything expensive that depends on frame number (physics, layout math) can be computed once into a lookup table keyed by frame instead of recalculated live.
3. Use <Video> in the Player, <OffthreadVideo> only for renders — OffthreadVideo's frame-accurate extraction is for encoding; in the interactive Player, plain <Video> is much cheaper.
4. Animate only transform and opacity — properties that trigger layout/paint (width, top, box-shadow, filters) are what usually tank Player FPS.
5. prefetch() heavy assets before playback starts so the first play-through doesn't stutter on network fetches.

Profiling tip: React DevTools' profiler on the playing Player will show you exactly which component is re-rendering expensively per frame — it's usually one or two offenders, not everything.

[halilertekin]

The "memoize everything" recommendation above is correct, but the question underneath it is more specific: when a Scene is not currently visible, does the Player still trigger a React re-render of it? Answer: the Player re-renders the whole component tree every tick, but React.memo (or a stable inputProps reference) is what prevents a Scene from re-doing its work.

A Scene that reads useCurrentFrame() will be marked as needing an update each tick, but React will only re-render it if one of its props changes identity between renders. I verified this with a small repro using react@19, react-dom@19, @remotion/player@4.0.534 and remotion@4.0.534, driven through vitest in happy-dom:

import { render, act } from "@testing-library/react";
import { createContext, useContext, useMemo, useState, memo } from "react";

const FrameContext = createContext<{ current: number } | null>(null);
function useCurrentFrame() {
  const ctx = useContext(FrameContext);
  if (!ctx) throw new Error("FrameContext missing");
  return ctx.current;
}

const renderCounts = new Map<string, number>();
const bump = (label: string) =>
  renderCounts.set(label, (renderCounts.get(label) ?? 0) + 1);

const Scene = memo(function Scene({ label }: { label: string }) {
  bump(label);
  const frame = useCurrentFrame();
  return <div data-testid={`scene-${label}`}>{label}:{frame}</div>;
});

function StackMemoised({ scenes }: { scenes: string[] }) {
  const list = useMemo(() => scenes, [scenes]);
  return (
    <>
      {list.map((label) => (
        <div key={label}><Scene label={label} /></div>
      ))}
    </>
  );
}

test("memoised parent: 5 forced re-renders do not cause Scenes to re-render", () => {
  const StableParent = () => {
    const [, force] = useState(0);
    (StableParent as any)._advance = () => force((n) => n + 1);
    const scenes = useMemo(() => ["A", "B", "C"], []);
    return <StackMemoised scenes={scenes} />;
  };
  render(<FrameContext.Provider value={{ current: 0 }}><StableParent /></FrameContext.Provider>);
  const before = Object.fromEntries(renderCounts);
  for (let i = 0; i < 5; i++) act(() => { (StableParent as any)._advance(); });
  const after = Object.fromEntries(renderCounts);
  expect(after.A).toBe(before.A);
  expect(after.B).toBe(before.B);
  expect(after.C).toBe(before.C);
});

That test passes. The next one is the failure mode people actually hit, where the Scene takes a non-primitive prop:

const SceneWithPayload = memo(function SceneWithPayload({
  label, payload
}: { label: string; payload: { tag: string } }) {
  bump(label);
  return <div data-testid={`scene-${label}`}>{label}:{payload.tag}</div>;
});

function StackWithInlinePayload({ scenes }: { scenes: string[] }) {
  return (
    <>
      {scenes.map((label) => (
        <SceneWithPayload label={label} payload={{ tag: label }} key={label} />
      ))}
    </>
  );
}

Forced parent re-renders create a new payload object on every render. React.memo compares prop identity, the new object wins, and the Scene re-renders. Same pattern happens in Remotion when you write <Sequence style={{...}} /> or <MyScene transform={computeMatrix()} /> without useMemo.

So the practical checklist is:

1. Wrap the Scene component in React.memo (or React.forwardRef(memo(...)) if it needs a ref).
2. Wrap every non-primitive prop in useMemo at the level that creates it. The Player re-renders the root, so the value needs to be referentially stable inside the root or its descendants.
3. If the Scene subscribes to useCurrentFrame(), the re-render is unavoidable for the currently-visible Scene — that one is supposed to re-render. Memo is for the siblings, not for the active one.
4. useVideoConfig() returns a stable object across the composition lifetime, so you do not need to memoise that one.
5. If the Scene is genuinely heavy and you cannot avoid re-renders, split it: keep a memoised outer shell that reads useCurrentFrame, and do the expensive work in a child that you can bail out of with useMemo([frame]) or a precomputed lookup table.

I ran the two tests on remotion@4.0.534 / react@19.0.0 in happy-dom@15.11.6. The repro deliberately does not use the real Player because happy-dom does not drive the video clock, so the assertion is about React re-render counts rather than actual frame playback — but the same memo contract is what makes the Player behave correctly in the browser.

If you post the offending component I can probably point at the prop that is missing a useMemo. In my experience the usual suspects are inline style objects, fresh arrays in Sequence.from/durationInFrames math, and callbacks that capture loop variables.