Skip to content

renderFrames only collects audio from the first tab, so short clips can be missing with concurrency > 1 #20

Open

Description

@elwizard33

After rendering, renderFrames reads window.__RENDIV_AUDIO_SOURCES__ from pages[0] only. Each tab has its own window, and an <Audio> only registers in the tab that rendered a frame where it was mounted. So if a clip only mounts on frames that other tabs rendered, it isn't collected and silently drops out of the mix.

Since every tab pulls frames from the same queue, each one ends up rendering roughly every Nth frame (N = concurrency). In practice that means it mostly hits clips whose <Sequence> is shorter than the concurrency. Longer clips almost always get mounted in the first tab at some point too.

Repro:

const TwoTabs = () => (
  <>
    <Fill style={{ background: '#123' }} />
    <Sequence from={0} durationInFrames={1}><Audio src={staticFile('a.mp3')} /></Sequence>
    <Sequence from={1} durationInFrames={1}><Audio src={staticFile('b.mp3')} /></Sequence>
  </>
);
// <Composition id="TwoTabs" component={TwoTabs} durationInFrames={2} fps={30} width={320} height={180} />

With renderFrames({ ..., concurrency: 2 }), tab 1 renders frame 0 and tab 2 renders frame 1. On master (6d6aca2) the returned audioSources only has a.mp3.

Reading the map from every page and merging by key fixes it. The keys are already content-based, so duplicates collapse on their own. That's in #27.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions