@remotion/renderer: Fix numberOfGifLoops being ignored on Lambda#6547
@remotion/renderer: Fix numberOfGifLoops being ignored on Lambda#6547JonnyBurger merged 2 commits intomainfrom
@remotion/renderer: Fix numberOfGifLoops being ignored on Lambda#6547Conversation
The muxVideoAndAudio step was re-muxing the GIF with -c:v copy without passing the -loop flag, causing FFmpeg's GIF muxer to use its default (infinite loop) and overriding the correct loop count. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@remotion/renderer: Fix numberOfGifLoops being ignored on Lambda
There was a problem hiding this comment.
Pull request overview
Fixes numberOfGifLoops being lost during Lambda chunk combination by preserving the GIF muxer -loop setting through the final muxVideoAndAudio step.
Changes:
- Add
numberOfGifLoopssupport tomuxVideoAndAudio()and pass it through frominternalCombineChunks(). - Ensure FFmpeg
-loopflag is applied during the final remux, not only during video stream combination.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| packages/renderer/src/mux-video-and-audio.ts | Adds numberOfGifLoops parameter and forwards it to FFmpeg as -loop. |
| packages/renderer/src/combine-chunks.ts | Forwards numberOfGifLoops into the muxing step when combining chunks. |
| numberOfGifLoops === null ? null : '-loop', | ||
| numberOfGifLoops === null | ||
| ? null | ||
| : convertNumberOfGifLoopsToFfmpegSyntax(numberOfGifLoops), |
There was a problem hiding this comment.
-loop is a GIF muxer option; adding it here whenever numberOfGifLoops !== null will make ffmpeg fail for non-GIF outputs if a caller passes numberOfGifLoops with e.g. codec: 'h264' (combineChunks is a public API and currently doesn’t validate this option). Consider gating these arguments to only be added when the output format is GIF (e.g. based on output extension / a passed-in codec, or by only passing non-null numberOfGifLoops from the caller when codec === 'gif').
| cancelSignal, | ||
| addFaststart: codecSupportsFastStart[codec], | ||
| metadata, | ||
| numberOfGifLoops, |
There was a problem hiding this comment.
numberOfGifLoops is forwarded to muxVideoAndAudio() unconditionally. Since combineChunks() is an exported API and does not currently validate numberOfGifLoops against codec, passing a non-null loop count for non-GIF codecs can now cause the mux step to fail (because muxVideoAndAudio will include -loop). Safer would be to pass codec === 'gif' ? numberOfGifLoops : null (or validate and throw a clearer error earlier).
| numberOfGifLoops, | |
| numberOfGifLoops: codec === 'gif' ? numberOfGifLoops : null, |
…ot GIF Also fix copy-paste error in validation message that said "everyNthFrame" instead of "numberOfGifLoops". Co-authored-by: Cursor <cursoragent@cursor.com>
Summary
numberOfGifLoopswas not being forwarded to themuxVideoAndAudiostep incombine-chunks.tscombineVideoStreamscorrectly applies the-loopflag, but thenmuxVideoAndAudiore-muxes with-c:v copywithout the-loopflag, causing FFmpeg's GIF muxer to default to infinite loopnumberOfGifLoopsparameter tomuxVideoAndAudio()so the-loopflag is preserved in the final outputTest plan
--number-of-gif-loops=0produced infinite-loop GIF--number-of-gif-loops=0now produces play-once GIF--number-of-gif-loops=3produces 3-loop GIFCloses #6512
🤖 Generated with Claude Code