Runway brings broadcast frame rates to its video API

Runway has added Enhance Frame Rate, a model that converts an existing video to a selected output cadence by synthesising intermediate frames. The advertised ceiling is 120 fps, while the practical advantage for production pipelines is native support for fractional rates such as 23.976, 29.97, and 59.94. Jobs accept up to 300 seconds of video and cost 1 credit per 2 seconds of input.

The clip supplies the content

Existing video is the model's creative input, whether it comes from a camera, an edit, or another Runway model. The request includes no text prompt, reference image, or reference clip. Runway previously offered similar functionality through its deprecated standalone Frame Interpolation tool; Enhance Frame Rate brings that operation into the company's current asynchronous API.

Output frame rate and playback speed remain separate controls. A conversion from 24 to 120 fps keeps the original running time when played at 120 fps. Creating fivefold slow motion requires conforming that 120 fps result to a 24 fps timeline.

One endpoint, a different payload

Runway routes the model through the existing video-upscale endpoint, allowing integrations that already use that endpoint to retain their authentication, upload, polling, retry, and error-handling code.

The core request selects the model, supplies the source video URI, and names the target rate. Authentication and API-version headers follow the rest of Runway's API conventions.

POST /v1/video_upscale
Content-Type: application/json

{
  "model": "enhance_frame_rate",
  "videoUri": "https://your-cdn.example/clip.mp4",
  "targetFrameRate": "23_98"
}

Runway returns a task ID for its existing asynchronous task flow, so clients can poll until completion and handle timeouts or failures through their current task infrastructure.

The fractions are the feature

Runway supports the integer rates common to consumer interpolation tools alongside the fractional cadences required by many broadcast and post-production workflows.

The API label 23_98 represents the 23.976 cadence, conventionally expressed as 24000/1001. That rate differs from 24 fps by about 0.1%. Reinterpreting one hour of 24 fps frames at 23.976 lengthens the sequence by roughly 3.6 seconds, which can disrupt timecode, audio sync, and delivery checks. Direct conversion to the required cadence can remove a separate standards-conversion step.

Five times the frames, same bill

Runway meters Enhance Frame Rate by input duration, so the target rate does not change the job price. A 24 to 120 fps conversion creates five times as many output frames as a 24 to 24 fps job while receiving the same duration-based charge.

At a listed price of $0.01 per credit, the approximate cost is:

Runway's Magnific Video Upscaler uses the same endpoint but charges 0.7 credits per output frame at 720p or 1K. A 10-second, 30 fps clip contains 300 output frames, producing a charge of 210 credits, or about $2.10. Enhance Frame Rate processes the same duration for about $0.05, roughly 42 times less. The two models perform different operations: Magnific adds spatial detail, while Enhance Frame Rate adds temporal samples.

Cuts and occlusion expose the limits

Frame interpolation estimates how objects move between source frames and renders their likely intermediate positions. Fast motion, heavy motion blur, occlusion, particles, reflections, thin geometry, and moving text can undermine that estimate, producing ghosting, doubled edges, or warped shapes.

A 24 to 120 fps conversion inserts four synthetic frames between each pair of source frames, giving errors more opportunities to remain visible. Slow-motion playback also holds each generated frame on screen longer, making artefacts easier to inspect.

A hard cut provides no valid motion path between adjacent shots. Runway has not documented automatic scene-cut detection, so processing across a cut can create a brief morph between unrelated frames. Long-form workflows should split footage at shot boundaries, process each segment separately, and reassemble the results at the target time base. The 300-second job limit already requires this segmentation for videos longer than five minutes.

Runway has yet to publish an artefact study, shot-level guidance, or independent comparisons with RIFE, Topaz Apollo, or Topaz Chronos. Production evaluation should use representative footage rather than clean promotional shots.

Runway packages the operational layer

Topaz Video AI offers Apollo and Chronos as desktop models that run on local hardware. RIFE and its descendants provide open-source components for teams prepared to maintain their own inference stack. These options can offer lower marginal costs on owned GPUs, more tuning controls, and local handling of sensitive footage.

Runway's package combines hosted execution, asynchronous task management, fractional target rates, and duration-based billing. That combination suits automated delivery systems producing several regional versions from one master. Local tools remain practical for individual shots when an operator needs model selection, parameter control, and repeated visual inspection.

A production test should answer six questions

1. Motion quality: Check faces, hands, hair, text, particles, reflections, camera moves, and foreground occlusion.
2. Cut handling: Confirm that segmentation prevents interpolation across edits, flashes, and transitions.
3. Timing: Measure exact duration, frame count, time base, audio sync, and timecode after conversion.
4. Encoding: Verify output codec, resolution, colour metadata, bit depth, and variable-frame-rate behaviour.
5. API reliability: Test queue latency, retries, failed tasks, expiring source URLs, and parallel-job limits.
6. Delivery cost: Include storage, network transfer, segmentation, reassembly, and quality-control labour alongside API credits.

Best fits for an early trial

• Broadcast and multi-territory teams producing 23.976, 25, 29.97, 50, or 59.94 versions from one master
• Developers already using /v1/video_upscale who can reuse their existing task infrastructure
• Automated media pipelines that value predictable duration-based pricing
• Creators generating intermediate frames for slow motion without provisioning a GPU

Teams selecting primarily on image quality should benchmark Enhance Frame Rate against local alternatives before adding it to a delivery chain. The API economics are clear; performance on difficult motion, edits, audio, and production metadata still requires independent testing.