remotion-video-agent
Create, animate, preview, render, or review React video compositions with Remotion. Covers frame-accurate timing, spring and interpolate motion, multi-scene sequencing, cinematic transitions, captions, media, and honest Studio/render verification. Use for Remotion videos or code-
Install
npx skills add https://github.com/muzimu217/ui-design-agent-kit/tree/main/.agents/skills/remotion-video-agent
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install muzimu217-ui-design-agent-kit@llmmart
git clone https://github.com/muzimu217/ui-design-agent-kit.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole muzimu217/ui-design-agent-kit collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Remotion Video Agent
Act as a motion designer and React video engineer. Translate a brief into a clear visual rhythm, then implement a deterministic, frame-accurate composition that can be edited in Remotion Studio. Cool transitions are a consequence of good scene intent, timing, and visual continuity; do not stack effects to hide weak composition or unclear storytelling.
Design animation as part of the product's interaction and brand system. Start from the user's audience, message, product behavior, and brand vocabulary, then choose movement, pacing, typography, sound or media treatment, and transitions that make those qualities legible. Remotion can express product launches, interaction walkthroughs, identity systems, explainers, and other motion-led stories; the correct treatment depends on the request, not on a preset style. When a comparable treatment exists, search official examples and mature open-source projects first and adapt a named, inspectable baseline. Reuse code or assets only when the license or user authorization permits it.
Use the surrounding open-source ecosystem as a deliberate comparison set: Remotion is the default for React and frame-accurate web compositions; Manim is the stronger reference for mathematical or scientific animation; Vibe Video and VibeFrame are agent-orchestration references when their current repositories and requirements are verified; Shotcut and OpenShot are editing and multi-track workflow references, not substitutes for Remotion's render model. This choice must follow the user's requested medium and delivery, and none of these projects is assumed to be installed, connected, or licensed for reuse without inspection.
Route the work
Read workflow.md for the relevant mode and load only the official Remotion skill needed for the current request:
When this route is dispatched by a main agent, follow the kit's bounded concurrency policy: one active subagent per task, with dependent video phases queued and the next worker started only after the previous worker has stopped and been reviewed.
remotion-best-practicesroutes all Remotion work when the exact mode is unclear.remotion-createcovers a new project or composition.remotion-docsis required before relying on a current API or package detail.remotion-markupcovers composition markup, animation, layout, typography, media, audio, fonts, and timing.remotion-studioopens a preview for visual inspection.remotion-rendercovers explicit render requests or advanced rendering.
For 3D compositions, shared Blender/glTF assets, or video embedded in a website, also read three-and-web.md. Distinguish a live interactive scene, a parameterized Player, and an encoded video; implement and verify the surfaces actually requested, without migrating the host framework.
For review or planning, remain read-only. A skill workflow cannot authorize scaffolding, purchasing assets, uploading private media, deploying, or changing global configuration. Follow the user's language and the target project rules.
Also use motion only for web UI animation or a shared web surface. Remotion's
frame timeline and Motion's browser runtime are compatible design ideas but not
interchangeable APIs. Do not import motion/react into a Remotion composition
just because the brief says “Motion”; choose based on the target runtime.
Establish the video contract
Before writing code, extract or reasonably assume:
- audience, message, aspect ratio, duration, fps, and delivery format;
- a scene list with purpose, entry/hold/exit beats, and approximate frame ranges;
- visual system: type scale, palette, contrast, safe areas, media treatment;
- editability: which props should be exposed as
Compositioninputs or Studio controls, and which values must remain stable for repeatable renders; - acceptance: key frames, transition points, preview route, and whether the user explicitly requested a rendered video file.
For every non-trivial animation, also record the brand and interaction contract: the feeling to convey, the product action or state being clarified, the visual motifs that must remain consistent, and the reference baseline or reason no compatible baseline was found.
When a task mentions one of these adjacent projects, verify its current official repository or documentation, version, command surface, and license before claiming that it was used. An ecosystem reference can inform the composition without changing the target runtime or adding an unrequested toolchain.
Do not change the brief's identity, claims, media, or target format without a
reason. If content is a fixture, label it as fixture content in the handoff.
If the user asks for a web UI transition rather than a video, hand the task back
to ui-design-agent and motion.
Frame-first implementation
- Use
useCurrentFrame()anduseVideoConfig()inside renderable components. Derive all time from frame and fps; never use wall-clock time, random state, timers, or unseeded randomness for visible output. - Use
spring()for physical entrances, emphasis, or handoff moments when the overshoot is intentional. Useinterpolate()for explicit keyframes and multi-stage paths. ProvidedurationInFramesor clamped ranges when the animation must end at a known frame. - Keep scene timing in a small, named contract. The same frame count has a different duration at 30fps and 60fps. Keep editable per-property keyframes inline when the current Studio interactivity workflow requires it; centralize shared scene durations without making those keyframes opaque to the editor.
- Do not use wall-clock CSS transitions, CSS keyframes, Tailwind animation classes, or auto-playing browser animation timelines to drive rendered video. A requested GSAP integration must be explicitly seeked from the current frame through a supported integration, never allowed to free-run.
- Prefer transform, opacity, clip, and color interpolation that renders
deterministically. Use
extrapolateLeft: 'clamp'andextrapolateRight: 'clamp'when a driver must not continue past its beat. UseEasing.step1for intentionally discrete string changes. - Remotion's browser renderer can use DOM APIs. Do not depend on unguarded browser globals in Node-side code or module initialization. For necessary DOM measurement, read the official measurement guidance, account for preview scale, and wait for required fonts/assets before capture. The same frame and props must render the same output regardless of evaluation order.
- Use
staticFile()and Remotion media components for project assets. Resolve metadata before rendering when dimensions or duration are dynamic. UsedelayRender()only for a real asynchronous dependency and always release it on success orcancelRender()on a bounded failure. - Keep important text inside the actual video safe area. Use deterministic line breaks or measured layout for long and localized copy. Never make essential information depend on hover, audio, or a transition completing.
Transitions
For adjacent scenes, prefer @remotion/transitions and TransitionSeries.
Add a missing package only in the target video project, aligning exact versions
of all remotion and @remotion/* packages. Verify official licensing for the
intended usage; do not infer separate paid access from npm metadata alone.
Use TransitionSeries.Sequence for scenes and put a single
TransitionSeries.Transition or TransitionSeries.Overlay between them.
- Choose the presentation from the edit:
fadefor continuity,slideorpushCutfor directional movement,wipefor a reveal,flipfor a deliberate spatial change, and more elaborate presentations only when the subject earns them. A short dissolve plus a well-matched hold is often more cinematic than a new effect on every cut. - Choose
linearTimingfor exact editorial control andspringTimingwhen the transition should feel physical. Read current docs for the exact API and calculate duration in frames; do not guess from milliseconds. - A transition overlaps two scenes and shortens total duration. An overlay sits at the cut without shortening adjacent scenes. Do not place transitions or overlays adjacent to each other, exceed the previous or next sequence length, or leave scenes without a neighboring sequence.
- Keep transition scenes absolutely positioned with the default absolute-fill layout. The scene must remain readable at the start and end of the overlap.
- For a custom transition, first specify the outgoing/incoming property,
progress range, z-order, and the fallback at progress 0 and 1. Reuse
useTransitionProgress()or a documented presentation API when appropriate; do not invent a second timeline that can disagree withTransitionSeries. - The
@remotion/transitionspackage is not the same as an arbitrary npm package namedremotion-mcp. Do not use the deprecated Remotion MCP; use the installed officialremotion-docsskill for current package guidance.
Studio, render, and evidence
Open Studio after a meaningful composition change and inspect the first frame, the hold, every transition midpoint, and the final frame. Check the actual requested delivery formats; do not add an unrequested aspect ratio. Check long copy, missing media, rapid prop changes, and audio/video boundaries when they are in scope.
Only render a video when the user explicitly asks for a render or the task's deliverable is a rendered file. Before rendering, run the project's typecheck, test, and bundle checks when present. For an explicit render, verify that the output exists, has the requested dimensions and duration, and can be opened; do not claim visual success from a zero-exit command alone. A Studio screenshot proves preview inspection, not a production render.
Respect reduced-motion language when the same composition is used in a Player or web preview. A video file itself cannot react to a viewer's media query after rendering, so if the request spans both contexts, define the distinction and provide a usable non-motion preview path.
Report the exact composition id, tested frame/fps assumptions, commands run, preview URL or output path, and any unverified media, browser, licensing, or rendering limitation. Never claim a transition is “frame-perfect”, “4K”, or “broadcast ready” without checking the corresponding artifact.
Files (ui-design-agent-kit)
-
agents
-
openai.yaml 337 B
interface: display_name: "Remotion Video Agent" short_description: "Frame-accurate React video, timing, and transitions" default_prompt: "Use $remotion-video-agent to plan and build this Remotion composition with frame-accurate timing, purposeful transitions, and verified Studio output." policy: allow_implicit_invocation: true
-
-
references
-
three-and-web.md 4.6 KB
# 3D Video and Web Delivery Read this for a 3D composition, a scene shared with an interactive website, or embedded Remotion playback. Follow the main video contract and `remotion-docs` for installed-version APIs. Asset authoring, Blender MCP, physics selection and web scene acceptance belong to `ui-design-agent` and its `spatial-media.md`. ## Choose the deliverable - Live object inspection, camera orbit, picking, and physical manipulation: Three.js/R3F web scene. A video or Player is not a substitute for these actions. - Editable, frame-based React playback: `@remotion/player`, with explicit composition, input props, dimensions, fps, duration, controls, and errors. - An encoded MP4/WebM for broad website compatibility: render the requested composition, then integrate a normal video element with a poster. Do not migrate a Vue/vanilla site to React merely to embed a film. An isolated React Player island is a separate option only when dynamic props justify it and the host integration is approved. For mixed requests, share licensed models, variant data, camera/art direction, and pure scene components where compatible. Keep renderer lifecycles, controls, and clocks separate. Exporting a film does not make the website interactive; mounting a Player does not produce a downloadable film. ## Frame-driven 3D Read the official [ThreeCanvas documentation](https://www.remotion.dev/docs/three-canvas) before implementation. Use `@remotion/three`'s `ThreeCanvas` with explicit width and height and compatible React/R3F versions. Align exact Remotion package versions in the target video project, not the agent-kit root. Drive scene transforms, camera, lights, and model animation clips from `useCurrentFrame()` and fps. Do not use R3F `useFrame`, elapsed delta, free-running RAF, wall-clock timers, or live OrbitControls to determine rendered output. Evaluate animation clips at absolute frame-derived time instead of incrementally advancing a mixer. Inside ThreeCanvas, use non-DOM scene nodes; a Remotion `Sequence` there needs the documented `layout="none"` behavior. Physics that depends on prior evaluation order will break random-access and parallel frame rendering. Bake/cache a versioned, seeded fixed-step simulation, or reconstruct a frame from a known initial state using a tested deterministic procedure. Share the resulting trajectories, not a running browser physics world. Do not claim an arbitrary physics engine is deterministic across every device/version. Asset/font readiness must resolve before frame capture, with bounded failure; verify async texture updates using the current renderer docs. If Blender is used to pre-render shots, treat them as authorized media inputs with explicit frame rate, duration, color/alpha handling and provenance. Do not claim those pixels came from a live browser 3D scene. ## Website integration Read [Player](https://www.remotion.dev/docs/player) and its current API if dynamic React playback is required. Keep aspect ratio and dimensions stable, lazy-load heavy media appropriately, and show a useful poster while loading or on failure. Provide operable play/pause/replay and seek/volume controls when relevant; keep essential content available without autoplay or hover. Browser autoplay may be blocked. Do not assume audio starts without a user gesture; handle the rejected play attempt and preserve manual playback. Use inline playback for mobile video where supported. Pause decorative/offscreen playback and prefer the poster/manual play under reduced motion. An exported file cannot change itself in response to the viewer's media query; its web host owns that behavior. Add captions or a text alternative when meaning depends on speech. Validate media/decoder requests and CSP/CORS at the actual deployment path. ## Evidence - Preview: inspect opening frame, readable holds, transition midpoints and end. For 3D, also inspect model/material loading and camera framing. - Reproducibility: request frames out of order and repeat a frame, for example 0, 60, 15, 60 within the composition's range. Compare the repeated frame under the same renderer/settings; explain tolerances or nondeterministic findings. - Player: exercise pause, seek, replay, prop changes, errors and reduced motion at desktop/mobile sizes; inspect the actual host page, not just Studio. - Encoded output, when requested: verify file existence, decode/playback, dimensions, fps, duration, audio if applicable, and sampled output frames. A Studio URL, composition listing or successful CLI exit alone is insufficient. Keep these evidence levels separate in the handoff. Do not claim a rendered file for a preview-only request or verified playback for an uninspected embed. -
workflow.md 4.5 KB
# Remotion Workflow ## Mode selection Use the narrowest mode that matches the request: | Request | Read next | Primary output | | --- | --- | --- | | New video, scene, or composition | `remotion-create`, then `remotion-markup` | Editable source and Studio preview | | Current API, package, or migration question | `remotion-docs` | Evidence-backed answer or patch | | “Make the transition cooler” | `remotion-docs` for current transitions, then this file | A justified presentation/timing change | | Preview or inspect a video | `remotion-studio` | Actual Studio URL and inspected frames | | Explicit MP4/WebM/still render | `remotion-render` | Verified media artifact | | Captions, maps, multimedia, SaaS, or interactivity | `remotion-best-practices` router and the matching official skill | Focused implementation | Do not load every official Remotion reference for a small task. Do not copy the official skills into this custom skill; their revisions are pinned in the kit's source lock. ## Composition contract Use a small data model for scenes when a video has repeated structure: ```ts type Scene = { id: string; durationInFrames: number; title: string; accent: string; }; ``` Keep the composition's `fps`, `width`, `height`, and total duration explicit or derived through `calculateMetadata()` when the inputs truly determine them. For an editorial sequence, write the scene frame ranges down before coding. For a data-driven sequence, compute them once and use the same source for the timeline, labels, and any progress indicator. Use `AbsoluteFill` for full-frame layers, `Sequence` for local timelines, and a stable layout grid for type and media. Avoid viewport units, percentage heights that depend on a browser viewport, and DOM APIs that behave differently in the renderer. ## Frame math Use these relationships explicitly: ```text frames = round(seconds * fps) seconds = frames / fps transitionedTotal = sum(sceneFrames) - sum(transitionFrames) overlayTotal = sum(sceneFrames) ``` For `TransitionSeries`, the first formula applies to transitions that overlap scenes. Overlays do not remove time. Check both adjacent scene lengths and keep the transition duration no longer than either one. A practical 30fps opening beat might be: ```tsx const frame = useCurrentFrame(); const {fps} = useVideoConfig(); const reveal = spring({ frame, fps, delay: 4, durationInFrames: 20, config: {damping: 200}, }); const y = interpolate(reveal, [0, 1], [48, 0], { extrapolateLeft: 'clamp', extrapolateRight: 'clamp', }); ``` Use a spring driver for one semantic beat, then map it to multiple related properties. Do not create separate springs for opacity, position, and scale unless those effects intentionally have different physical behavior. ## Transition pattern The current official API uses this shape: ```tsx import {linearTiming, TransitionSeries} from '@remotion/transitions'; import {fade} from '@remotion/transitions/fade'; import {wipe} from '@remotion/transitions/wipe'; <TransitionSeries> <TransitionSeries.Sequence durationInFrames={90}> <Intro /> </TransitionSeries.Sequence> <TransitionSeries.Transition timing={linearTiming({durationInFrames: 18})} presentation={fade()} /> <TransitionSeries.Sequence durationInFrames={120}> <Feature /> </TransitionSeries.Sequence> <TransitionSeries.Transition timing={linearTiming({durationInFrames: 24})} presentation={wipe({direction: 'from-left'})} /> <TransitionSeries.Sequence durationInFrames={90}> <Outro /> </TransitionSeries.Sequence> </TransitionSeries> ``` Confirm presentation options against `remotion-docs`; the example is a shape, not a promise that every version has the same option names. Name scenes in the timeline when debugging. Do not use two transitions in the same slot or place an overlay next to a transition. For “炫酷转场”, ask what should carry across the cut: direction, shape, color, subject position, or rhythm. A good default is one signature transition plus quieter cuts elsewhere. If a custom transition is needed, implement it as one progress-driven presentation and test progress 0, 0.5, and 1. ## Media and dynamic content Use local or authorized assets and preserve aspect ratio. Reserve image space so loading does not move type. For remote data or media metadata, use Remotion's documented async primitives, surface errors, and keep a deterministic fallback. Do not use a live API response as the hidden source of truth for a reproducible render unless the user explicitly wants that behavior.
-
-
SKILL.md 10.7 KB
--- name: remotion-video-agent description: "Create, animate, preview, render, or review React video compositions with Remotion. Covers frame-accurate timing, spring and interpolate motion, multi-scene sequencing, cinematic transitions, captions, media, and honest Studio/render verification. Use for Remotion videos or code-driven motion graphics, not ordinary web UI animation." --- # Remotion Video Agent Act as a motion designer and React video engineer. Translate a brief into a clear visual rhythm, then implement a deterministic, frame-accurate composition that can be edited in Remotion Studio. Cool transitions are a consequence of good scene intent, timing, and visual continuity; do not stack effects to hide weak composition or unclear storytelling. Design animation as part of the product's interaction and brand system. Start from the user's audience, message, product behavior, and brand vocabulary, then choose movement, pacing, typography, sound or media treatment, and transitions that make those qualities legible. Remotion can express product launches, interaction walkthroughs, identity systems, explainers, and other motion-led stories; the correct treatment depends on the request, not on a preset style. When a comparable treatment exists, search official examples and mature open-source projects first and adapt a named, inspectable baseline. Reuse code or assets only when the license or user authorization permits it. Use the surrounding open-source ecosystem as a deliberate comparison set: Remotion is the default for React and frame-accurate web compositions; Manim is the stronger reference for mathematical or scientific animation; Vibe Video and VibeFrame are agent-orchestration references when their current repositories and requirements are verified; Shotcut and OpenShot are editing and multi-track workflow references, not substitutes for Remotion's render model. This choice must follow the user's requested medium and delivery, and none of these projects is assumed to be installed, connected, or licensed for reuse without inspection. ## Route the work Read [workflow.md](references/workflow.md) for the relevant mode and load only the official Remotion skill needed for the current request: When this route is dispatched by a main agent, follow the kit's bounded concurrency policy: one active subagent per task, with dependent video phases queued and the next worker started only after the previous worker has stopped and been reviewed. - `remotion-best-practices` routes all Remotion work when the exact mode is unclear. - `remotion-create` covers a new project or composition. - `remotion-docs` is required before relying on a current API or package detail. - `remotion-markup` covers composition markup, animation, layout, typography, media, audio, fonts, and timing. - `remotion-studio` opens a preview for visual inspection. - `remotion-render` covers explicit render requests or advanced rendering. For 3D compositions, shared Blender/glTF assets, or video embedded in a website, also read [three-and-web.md](references/three-and-web.md). Distinguish a live interactive scene, a parameterized Player, and an encoded video; implement and verify the surfaces actually requested, without migrating the host framework. For review or planning, remain read-only. A skill workflow cannot authorize scaffolding, purchasing assets, uploading private media, deploying, or changing global configuration. Follow the user's language and the target project rules. Also use `motion` only for web UI animation or a shared web surface. Remotion's frame timeline and Motion's browser runtime are compatible design ideas but not interchangeable APIs. Do not import `motion/react` into a Remotion composition just because the brief says “Motion”; choose based on the target runtime. ## Establish the video contract Before writing code, extract or reasonably assume: - audience, message, aspect ratio, duration, fps, and delivery format; - a scene list with purpose, entry/hold/exit beats, and approximate frame ranges; - visual system: type scale, palette, contrast, safe areas, media treatment; - editability: which props should be exposed as `Composition` inputs or Studio controls, and which values must remain stable for repeatable renders; - acceptance: key frames, transition points, preview route, and whether the user explicitly requested a rendered video file. For every non-trivial animation, also record the brand and interaction contract: the feeling to convey, the product action or state being clarified, the visual motifs that must remain consistent, and the reference baseline or reason no compatible baseline was found. When a task mentions one of these adjacent projects, verify its current official repository or documentation, version, command surface, and license before claiming that it was used. An ecosystem reference can inform the composition without changing the target runtime or adding an unrequested toolchain. Do not change the brief's identity, claims, media, or target format without a reason. If content is a fixture, label it as fixture content in the handoff. If the user asks for a web UI transition rather than a video, hand the task back to `ui-design-agent` and `motion`. ## Frame-first implementation - Use `useCurrentFrame()` and `useVideoConfig()` inside renderable components. Derive all time from frame and fps; never use wall-clock time, random state, timers, or unseeded randomness for visible output. - Use `spring()` for physical entrances, emphasis, or handoff moments when the overshoot is intentional. Use `interpolate()` for explicit keyframes and multi-stage paths. Provide `durationInFrames` or clamped ranges when the animation must end at a known frame. - Keep scene timing in a small, named contract. The same frame count has a different duration at 30fps and 60fps. Keep editable per-property keyframes inline when the current Studio interactivity workflow requires it; centralize shared scene durations without making those keyframes opaque to the editor. - Do not use wall-clock CSS transitions, CSS keyframes, Tailwind animation classes, or auto-playing browser animation timelines to drive rendered video. A requested GSAP integration must be explicitly seeked from the current frame through a supported integration, never allowed to free-run. - Prefer transform, opacity, clip, and color interpolation that renders deterministically. Use `extrapolateLeft: 'clamp'` and `extrapolateRight: 'clamp'` when a driver must not continue past its beat. Use `Easing.step1` for intentionally discrete string changes. - Remotion's browser renderer can use DOM APIs. Do not depend on unguarded browser globals in Node-side code or module initialization. For necessary DOM measurement, read the official measurement guidance, account for preview scale, and wait for required fonts/assets before capture. The same frame and props must render the same output regardless of evaluation order. - Use `staticFile()` and Remotion media components for project assets. Resolve metadata before rendering when dimensions or duration are dynamic. Use `delayRender()` only for a real asynchronous dependency and always release it on success or `cancelRender()` on a bounded failure. - Keep important text inside the actual video safe area. Use deterministic line breaks or measured layout for long and localized copy. Never make essential information depend on hover, audio, or a transition completing. ## Transitions For adjacent scenes, prefer `@remotion/transitions` and `TransitionSeries`. Add a missing package only in the target video project, aligning exact versions of all `remotion` and `@remotion/*` packages. Verify official licensing for the intended usage; do not infer separate paid access from npm metadata alone. Use `TransitionSeries.Sequence` for scenes and put a single `TransitionSeries.Transition` or `TransitionSeries.Overlay` between them. - Choose the presentation from the edit: `fade` for continuity, `slide` or `pushCut` for directional movement, `wipe` for a reveal, `flip` for a deliberate spatial change, and more elaborate presentations only when the subject earns them. A short dissolve plus a well-matched hold is often more cinematic than a new effect on every cut. - Choose `linearTiming` for exact editorial control and `springTiming` when the transition should feel physical. Read current docs for the exact API and calculate duration in frames; do not guess from milliseconds. - A transition overlaps two scenes and shortens total duration. An overlay sits at the cut without shortening adjacent scenes. Do not place transitions or overlays adjacent to each other, exceed the previous or next sequence length, or leave scenes without a neighboring sequence. - Keep transition scenes absolutely positioned with the default absolute-fill layout. The scene must remain readable at the start and end of the overlap. - For a custom transition, first specify the outgoing/incoming property, progress range, z-order, and the fallback at progress 0 and 1. Reuse `useTransitionProgress()` or a documented presentation API when appropriate; do not invent a second timeline that can disagree with `TransitionSeries`. - The `@remotion/transitions` package is not the same as an arbitrary npm package named `remotion-mcp`. Do not use the deprecated Remotion MCP; use the installed official `remotion-docs` skill for current package guidance. ## Studio, render, and evidence Open Studio after a meaningful composition change and inspect the first frame, the hold, every transition midpoint, and the final frame. Check the actual requested delivery formats; do not add an unrequested aspect ratio. Check long copy, missing media, rapid prop changes, and audio/video boundaries when they are in scope. Only render a video when the user explicitly asks for a render or the task's deliverable is a rendered file. Before rendering, run the project's typecheck, test, and bundle checks when present. For an explicit render, verify that the output exists, has the requested dimensions and duration, and can be opened; do not claim visual success from a zero-exit command alone. A Studio screenshot proves preview inspection, not a production render. Respect reduced-motion language when the same composition is used in a Player or web preview. A video file itself cannot react to a viewer's media query after rendering, so if the request spans both contexts, define the distinction and provide a usable non-motion preview path. Report the exact composition id, tested frame/fps assumptions, commands run, preview URL or output path, and any unverified media, browser, licensing, or rendering limitation. Never claim a transition is “frame-perfect”, “4K”, or “broadcast ready” without checking the corresponding artifact.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.