[StuartCameronCode]

Fixes #134.

Cause

The frame rate pass needs the source frame rate to know its retime ratio. FrameRateParameters.sourceFpsNum/Den was documented as "supplied by the app from ffprobe", but nothing in the app ever set it — only tests did. So the pass mapped as the identity: the progress total stayed at the source count (1775 in the report) while RIFE emitted ~2× that. Once the frame counter passed the total, the executor's safety clamp pinned progress at 100% with ETA: -- for the rest of the encode. Frame-accurate preview of a retimed job seeked the wrong frame for the same reason.

Fix

• VideoJob::effective_pipeline() fills the source rate from the job's input rate, using the same rational the script declares for the clip (fps_to_rational, now shared with ScriptGenerator::frame_rate_to_rational).
• The ratio is taken against the rate at the pass (frame_rate_input_fps, via a new FrameMap::rate_factor). 25i doubled to 50p and then converted to 25 now counts 1×, not 2× — wrong even when a source rate was supplied.
• Removed the now-unused FrameRateParameters::ratio() and corrected the stale doc comments; CLAUDE.md states the rule.

Tests

• Rust unit tests (video_job.rs, frame_rate_progress_tests): no app-supplied rate, an app-supplied rate wins, double-rate deinterlace then retime, preview inverse.
• integration_frame_mapping_test.dart (heavy): the FlowFPS and RIFE cases no longer pass sourceFps (matching what the app sends), every reported progress total is asserted against the frames actually written, and a new double-rate QTGMC → 25 fps case. Against the old worker both new assertions fail (total 75 for 71 frames; 62 for 31); with the fix all 11 pass locally, including RIFE on a real GPU.
• cargo test green apart from the subtitle test (whisper add-on not installed locally); integration_gpu_plugins_test and integration_filter_parameters_test pass.

🤖 Generated with Claude Code

[sanchandhana-commits]

Since the recent changes, frame interpolation seems to take slightly longer than before on my Mac mini M4 Pro. Is there any possibility of reducing the processing time while maintaining the same RIFE 4.26 output quality?

Could you investigate whether the extra processing time comes from the recent changes or from other parts of the pipeline, and optimize it if possible? Ideally, I’d like to achieve the previous processing speed or better without sacrificing interpolation quality.