Session Note 057
This note catches the Workshop up from Session Note 056 through the July 9 Remotion Experiments lane work, the first two rendered Remotion iterations, Christopher's confusion about hosting and practical use, and the decision to pause Remotion expansion until there is a stronger use case.
Current lesson: Remotion is useful as a repeatable coded-template engine, but GitHub Pages is only the gallery. Do not build a hosted Remotion app before the production need is real.
1. What Was Built
Christopher asked to create a Remotion Experiments lane modeled after Kron Evolution.
OpenClaw created the Remotion concept page, Markdown companion, ledger page, ledger Markdown companion, structured metadata, and an isolated remotion/ project inside the Workshop repo. The Projects page now links to both the concept page and the ledger.
2. Iteration 1 Proved A Single-Artifact Render
Iteration 1, From Mark To Motion, used Kron Evolution Iteration 20 as the source artifact.
assets/video/remotion/from-mark-to-motion.mp4
assets/images/remotion/from-mark-to-motion-poster.jpg
The video is a 20-second vertical MP4 rendered through Remotion at 1080x1920, 30 fps, and 600 frames. This proved that Remotion was not only a browser mockup. The actual remotion/ project could render a real MP4 from a coded React composition.
3. The Renderer Became Data-Driven
Christopher then approved the next maturity step. OpenClaw moved the renderer from a hardcoded composition into a data-driven manifest pattern:
remotion/src/data/iterations.json
remotion/src/data/iterations.ts
remotion/scripts/render-iteration.mjs
The important change:
Before: one hardcoded Remotion video.
After: one reusable Remotion template driven by an iteration data record.
4. Iteration 2 Proved A Multi-Image Sequence
Christopher then asked for Iteration 2 using a few existing Kron Evolution images.
Iteration 2, Signal Sequence, used Kron Evolution images 16 through 20 and added sourceImages support to the Remotion data model.
assets/video/remotion/signal-sequence.mp4
assets/images/remotion/signal-sequence-poster.jpg
The video is a 20-second vertical MP4 with slow motion and crossfades between five Kron images. The ledger studio preview was also updated to fade through the same five images, but that browser preview remains a lightweight static-page approximation, not the Remotion renderer.
5. GitHub Pages Lag Caused Confusion
After Iteration 2 was committed and pushed, Christopher could not see it on the live ledger. The cause was GitHub Pages serving an older build while a Pages run stayed queued. OpenClaw manually triggered a fresh Pages rebuild. The correct commit deployed successfully, and the live ledger, MP4, and poster were verified.
If a Workshop commit is pushed but the live site does not show it, check GitHub Pages build state before assuming the files are wrong.
6. The Practical Hosting Model
- GitHub Pages: the public shelf. It can show concept pages, ledgers, previews, MP4s, posters, and metadata. It cannot run the heavy Remotion render because it is static.
remotion/: the production engine. It contains the React components, iteration data, render helper, and local commands.- Local execution or CI: where videos actually render. Today OpenClaw renders locally and commits the output. Later, GitHub Actions could render from JSON records if the lane proves valuable enough.
- The ledger studio preview: only a lightweight browser preview. It is not the full Remotion Studio and not the renderer.
7. Remotion vs FFmpeg
FFmpeg is better for one-off videos, trimming, resizing, compression, simple overlays, concatenation, fast utility work, and low overhead when the layout is simple.
Remotion is better for repeatable video formats, designed 20-30 second Shorts, consistent layout and timing, captions, intro/outro patterns, batch production, and programmatic control over text, images, colors, zoom curves, durations, frame timing, and audio behavior.
Remotion for designed templates.
FFmpeg for quick assembly and finishing work.
8. Decision: Pause Remotion Expansion
Christopher decided to put the Remotion lane on hold until he understands it better and there is a clearer use case. OpenClaw agreed. The lane has been validated, but it should not become another infrastructure project.
- Do not build a standalone hosted Remotion app yet.
- Do not add server-side rendering from the public page yet.
- Do not automate Remotion renders through GitHub Actions yet unless Christopher explicitly asks.
- Keep the existing proof, ledger, MP4s, and documentation available for reference.
- Reopen Remotion when there is a concrete template-production use case, such as a batch of similar 9:16 YouTube Shorts.
9. Current State
- Remotion Experiments has two iterations.
- Iteration 1 proved a single-image Remotion render.
- Iteration 2 proved a multi-image sequence render.
- The renderer is data-driven through
remotion/src/data/iterations.json. - GitHub Pages hosts the rendered MP4s and public pages, but does not render videos.
- The Remotion concept page now says the lane is validated but paused.
- README now captures the Remotion/FFmpeg distinction and the pause decision for fresh boot context.
- Projects now describes Remotion as validated but paused, not the next active lane.
- No cron job was changed. No public post was made.
10. Carry Forward
The most useful next experiment, if Remotion is reopened, would be a direct comparison: give OpenClaw the same short-video brief twice, produce one version with the current FFmpeg-style workflow, produce one version with a Remotion template, then compare token cost, wall time, editability, visual consistency, render reliability, and how easy it is to make the next similar video.
Until then, Kron Evolution remains the active experimental center, and Remotion remains a paused proof lane.