help quicky produce instagram reels and youtube shorts
94
96%
Does it follow best practices?
Impact
87%
2.12xAverage score across 3 eval scenarios
Passed
No findings from the security scan
Two renderers accept the same plan/cut_plan.json and produce the same kind of
file, so they can be compared on identical input.
render_reel.py | render_moviepy.py | |
|---|---|---|
| Engine | ffmpeg — per-segment cuts, concat demuxer, one mux | MoviePy — in-memory clip graph, single write |
| Dependency | ffmpeg only | pip install moviepy |
| Speed | fast | slower — roughly 5x on a short 1080 preview |
| Grading | ffmpeg filter chain | the same chain, applied as a second pass |
render_reel.py is the default. Only reach for MoviePy when the user asks
to compare, or when a plan needs per-clip compositing that the flat concat
model cannot express.
Same plan, same grade, same resolution — change only the script:
python3 scripts/render_reel.py plan/cut_plan.json --preview --grade rapha --out preview/ab_ffmpeg.mp4
python3 scripts/render_moviepy.py plan/cut_plan.json --preview --grade rapha --out preview/ab_moviepy.mp4render_moviepy.py prints its wall-clock time so the two are directly
comparable. Grading is not reimplemented — MoviePy handles cut, concat, and
audio, then the identical GRADES chain from render_reel.py runs as a second
ffmpeg pass. That keeps the assembly engine as the only variable.
Which engine to use is a user-facing choice, not an implementation detail: it changes render time and, slightly, the audio mix. Offer the comparison rather than silently swapping engines mid-project.
compose recomputes the timeline.--resolution..tessl-plugin
evals
skills
reel-builder
assets
remotion-cards
references
scripts