Imported from yaebk/RenderFlow (.claude/skills/renderflow/SKILL.md). Install upstream with npx skills add yaebk/RenderFlow --skill renderflow. Copyright stays with the author.

RenderFlow: Resolve performance profiler and fixer

RenderFlow measures the project that is open in DaVinci Resolve and reports what is slow, why, and what to change. Everything it does is deterministic and reversible; your job is to run it, read the JSON, explain the result in plain language, and apply fixes only with the user's agreement.

Preconditions

1. Resolve is open with a project and (usually) a timeline.
2. The bridge is running inside Resolve: Workspace -> Scripts -> RenderFlow_Bridge (free edition; on Studio the tool attaches directly). Check with:

   python -m renderflow.bridge
   

   If it says no discovery file, ask the user to start the bridge. Do not try to work around it.
3. FFmpeg on PATH (winget install Gyan.FFmpeg on Windows). Without it the decode measurement is skipped and the report says so.

Run every command from the RenderFlow repo directory with python -m renderflow ....

The one command to start with

python -m renderflow report --json

Runs everything: inventory, FFmpeg decode measurement per clip, a render-cost sample of every timeline clip through Resolve's own render queue (takes roughly 15-30 s per clip), and a plan of fixes. Nothing is changed. Read:

• findings[] - ranked high / medium / info, each with code, subject (a clip name, a timeline item as name @V1 01:00:17:09, or project), message, and why. Quote why when explaining.
• scan.clips[].measured - decode fps and realtime_ratio (< 1 cannot play in real time; < 2 no headroom; >= 2 decode is not the problem).
• render.samples[] - ms_per_frame, realtime_ratio, export_share, fusion_tools, color_nodes; render.estimated_export_s for the whole timeline.
• actions[] - what fix --apply would do, with estimate_s for encodes.
• skipped[] - stages that did not run and why.

For a quick look without rendering (seconds instead of minutes): python -m renderflow report --json --no-render.

Applying fixes

python -m renderflow fix            # prints the plan, changes nothing
python -m renderflow fix --apply    # makes the changes, journaled
python -m renderflow fix --undo     # reverses every journaled change

Fix kinds: proxies (DNxHR LB via FFmpeg, linked with LinkProxyMedia, plus Playback -> Proxy Handling -> Prefer Proxies, without which Resolve ignores them); settings (Render Cache -> Smart when a clip measured heavy and carries effects; Super Scale off); timeline markers over clips with high/medium findings. --proxies all forces proxies for every long-GOP clip; --no-markers / --no-settings narrow the plan.

Always show the user the plan and get a yes before --apply. Tell them --undo exists. Proxies take about a quarter of the footage's duration to encode and use disk space under ~/Videos/RenderFlow Proxies.

How to explain results

• Lead with the measured numbers, not the codec folklore. "Your H.264 decodes at 375 fps here, 6x real time - the codec is not the problem" is the kind of sentence the tool exists to make possible.
• Decode ratio answers "is the source footage the bottleneck". Render ratio answers "is the grade / Fusion / scaling the bottleneck". If decode is fine and render is slow, it is the effects.
• export_share says where export time goes; one clip at 60%+ is the thing to simplify or pre-render.
• The render sample includes an encode, so playback is somewhat faster than the render ratio suggests; the ranking between clips is reliable.
• When the plan is empty, say so: the measurements do not justify changes, and guessing would make things worse.

What it cannot do

Read pixels, control Resolve's own render cache beyond the mode setting, or measure playback directly (Resolve exposes no playback timing). It does not bake clips to files (render-in-place); Smart Render Cache covers that case without freezing content.