Skip to content

video_compose: cuts→scenes adapter for CinematicRenderer + dict profile#41

Open
chantskevin wants to merge 1 commit intocalesthio:mainfrom
chantskevin:fix/video-compose-llm-adapter
Open

video_compose: cuts→scenes adapter for CinematicRenderer + dict profile#41
chantskevin wants to merge 1 commit intocalesthio:mainfrom
chantskevin:fix/video-compose-llm-adapter

Conversation

@chantskevin
Copy link
Copy Markdown

Summary

Three small fixes to video_compose._remotion_render for LLM-driven callers:

  1. cuts → scenes adapter for CinematicRenderer — the agent emits a uniform
    edit_decisions.cuts[] shape across every renderer_family, but
    CinematicRenderer reads props.scenes[] with a different field layout.
    Without this, renderer_family=cinematic-trailer / documentary-montage
    silently renders 20–30s of pure black — scenes defaults to [] in
    Root.tsx, no error signal.

  2. File-URI rewrite applied to scenes[] too — companion to README video attachment upload #1; the
    existing loop only rewrote cuts[].source.

  3. Accept dict-form profile — schema documents profile as a string,
    but LLM callers frequently pass {"width": 1280, "height": 720, "fps": 30}.
    get_profile(name) then crashes with TypeError: unhashable type: 'dict'.
    Accept both: dict → extract width/height directly; string → existing
    lookup.

Notes

Remotion's Chromium still rejects file:/// URLs for local resources.
Fix #2 is a code-consistency fix; the broader "serve local files over HTTP"
story is unchanged by this patch.

All three fixes are additive; no behavior change for schema-compliant callers.

Test plan

  • Render with renderer_family="cinematic-trailer" and cuts[] — produces video (not black)
  • Render with profile={"width": 1280, "height": 720, "fps": 30} — does not crash
  • Render with profile="youtube_landscape" — existing behavior preserved

🤖 Generated with Claude Code

Three small fixes that matter for LLM-driven callers:

1. cuts → scenes adapter for CinematicRenderer
   The agent emits edit_decisions.cuts[] with a single consistent
   shape across every renderer_family. But the two Remotion compositions
   the tool targets read different props:
     - Explainer             reads props.cuts[]   {source, in_seconds, ...}
     - CinematicRenderer     reads props.scenes[] {src, kind:"video",
                                                   startSeconds,
                                                   durationSeconds, ...}
   When renderer_family=cinematic-trailer / documentary-montage and
   props.cuts[] is present without props.scenes[], _remotion_render
   now transforms cuts→scenes in place (cumulative startSeconds,
   durationSeconds = out-in, in_seconds→trimBeforeSeconds, optional
   tone/filter/fade hints preserved).
   Without this, Cinematic compositions render 20–30s of pure black
   video with no error signal — scenes[] just defaults to [].

2. File-URI rewrite applied to scenes[] too
   The existing loop that converts absolute paths to file:// URIs only
   ran against cuts[]. After the adapter fires, scene sources need the
   same treatment.

3. Accept dict-form profile as well as string name
   `profile` is documented as a string key from media_profiles.py
   (e.g. "youtube_landscape"), but LLM callers frequently pass
   {"width": 1280, "height": 720, "fps": 30}. get_profile(name) then
   raises TypeError: unhashable type: 'dict' with no caller recourse.
   Accept both: dict → extract width/height directly; string → the
   existing get_profile lookup path.

Note on the broader file-path limitation:
  Remotion's Chromium refuses `file:///` URLs for local-resource
  security ("Not allowed to load local resource"). Callers that pass
  absolute local paths still hit this — not regressed by this patch,
  just not solved. The long-term fix is serving local files over HTTP
  before invoking Remotion. In the meantime, callers with local files
  should front them with an HTTP server and pass the URL in cut.source.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@chantskevin chantskevin requested a review from calesthio as a code owner April 20, 2026 08:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant