@remotion/media: Buffer audio based on duration

[JonnyBurger]

Summary

• base audio startup buffering on queued duration instead of chunk count
• prevent large PCM chunks from deadlocking against the two-second scheduling horizon
• document the regression with a direct issue link
• add a manager-level PCM regression test that unblocks before six chunks or EOF

Closes #9394

Tests

• bunx vitest src/test/audio-iterator.test.ts --browser --run (10 tests)
• bun run build
• bun run stylecheck
• verified the attached Live Photo plays in local Remotion Studio

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
bugs	Ready	Preview, Comment	Jul 22, 2026 10:50am
remotion	Ready	Preview, Comment	Jul 22, 2026 10:50am

[pullfrog]

✅ No new issues found.

Reviewed changes — Replaced the audio startup buffering heuristic in @remotion/media from a fixed chunk count to a duration-based threshold, so files with large PCM chunks (e.g. Live Photos) no longer deadlock waiting for six chunks before playback unblocks.

• Switched onScheduled from receiving timelineTimestamp to accumulating sourceDurationInSeconds.
• Added MINIMUM_AUDIO_BUFFERING_TIME_SECONDS / hasEnoughAudioToStartPlayback and an idempotent unblockPlayback helper.
• Updated the audio iterator manager test harness to parameterize the source URL and count unblock calls.
• Added a PCM regression test using /junk.wav that verifies playback unblocks after ~0.14s / three chunks rather than waiting for six chunks or EOF.

  ^{｜ View workflow run ｜ Using Kimi K2 (free via Pullfrog for OSS) (Claude Opus not used — the program covers this model; add its provider key to run your pick) ｜ 𝕏}