रोज़मर्रा के काम में AI

Runway में फ़्रेम रेट बढ़ाने के बाद वीडियो की जाँच कैसे करें

लोकल वीडियो तैयार करने और अपलोड करने से लेकर enhance_frame_rate submit, task polling, output save और अंतिम FPS तथा sync जाँच तक पूरा workflow।

BetterToken

संपादकीय टीम

26 सित॰ 202613 मिनट पढ़ने में

विषय-सूची

Runway में फ़्रेम रेट बढ़ाने के बाद वीडियो की जाँच कैसे करें

आपके पास तैयार लोकल वीडियो हो सकता है, लेकिन Runway का बढ़ा हुआ frame-rate output अभी न बना हो। Acceptance जाँच से पहले फ़ाइल तैयार और upload करनी है, targetFramerate भेजना है, task पूरा होने की प्रतीक्षा करनी है और output सुरक्षित करना है। यह गाइड पूरा REST workflow देता है, फिर target FPS, motion artifacts, cuts और audio sync की जाँच कराता है।

17 सितंबर 2026 को Runway ने Runway Dev में enhance_frame_rate जोड़ा। यह video upscale endpoint का उपयोग करता है और 24, 25, 30, 48, 50, 60, 120, 23_98 (23.98 fps), 29_97 (29.97 fps) तथा 59_94 (59.94 fps) लक्ष्य स्वीकार करता है; एक input अधिकतम 300 सेकंड का हो सकता है और launch note में 2 सेकंड पर 1 credit की billing दी गई है।

सिर्फ “वीडियो अधिक smooth दिख रहा है” देखकर उसे स्वीकार न करें। पहले downstream की सटीक cadence चुनें, फिर metadata, जोखिम वाले motion, cuts और शुरुआत, बीच तथा अंत के sync को जाँचें; अंत में वास्तविक timeline और delivery platform पर परीक्षण करें।

पहले delivery cadence चुनें; सटीक specification न हो तो रुकें

पहले editing timeline, broadcaster, ad platform या client specification से exact value लें। 29_97 और 30, या 59_94 और 60, लगभग समान दिखते हैं, लेकिन गलत विकल्प long-form, broadcast या mixed-source काम में नया transcode या पूरा rerun करा सकता है।

लक्ष्य	सामान्य निर्णय आधार	डिलीवरी से पहले पुष्टि करें
`23_98` / `24`	Timeline या क्लाइंट film-style cadence माँगता है	आवश्यकता ठीक 23.98 है या integer 24
`25` / `50`	25/50 fps production chain या क्षेत्रीय delivery specification	Timeline, subtitles, audio और बाकी footage एक ही cadence पर हैं
`29_97` / `30`	Downstream system इनमें से किसी एक को स्पष्ट रूप से माँगता है	एक को दूसरे से बिना अनुमति न बदलें
`59_94` / `60`	तेज़ गति वाला content या high-frame-rate की स्पष्ट माँग	अधिक smooth playback का अर्थ खोया detail वापस मिलना नहीं है
`48` / `120`	विशेष timeline, slow-motion workflow या HFR delivery	केवल स्पष्ट आवश्यकता पर उपयोग करें; अधिक संख्या हमेशा बेहतर नहीं

यदि brief में केवल “वीडियो को अधिक smooth बनाओ” लिखा है, तो अंतिम delivery specification पूछें। वरना तकनीकी रूप से सही 60 fps फ़ाइल बन सकती है जो 59.94 fps timeline में सही तरह फिट न बैठे।

Source baseline बचाएँ, ताकि failure का कारण पता चल सके

Processing से पहले source frame rate, duration, codec और audio tracks दर्ज करें। Baseline न होने पर missing track, बदली duration या frozen tail को source, Runway output और बाद के transcode के बीच अलग करना कठिन होगा।

Source filename, duration, dimensions, codec और original frame rate।
Source constant frame rate (CFR) है या variable frame rate (VFR)।
Audio tracks की संख्या, sample rate, channels और लगभग duration।
Target frame rate और requirement का स्रोत, जैसे “क्लाइंट को 59_94 चाहिए”।
तीन से पाँच high-risk timecodes: तेज़ pan, हाथ, पतली रेखाएँ, occlusion edges, flash, transition, subtitles या UI।
शुरुआत, बीच और अंत में कम से कम तीन audio-sync anchors।

यह baseline समीक्षा को केवल “अब अधिक smooth लग रहा है” तक सीमित नहीं होने देती और duration change, missing track या delivery mismatch को पकड़ने में मदद करती है।

पहले जाँचें कि लोकल वीडियो इस workflow के लिए उपयुक्त है

API call से पहले format, duration और size जाँचें। एक enhance_frame_rate input अधिकतम 300 सेकंड का हो सकता है और ephemeral upload 512 bytes से 200 MB के बीच होना चाहिए। MP4 के साथ H.264, H.265 या AV1 जैसे supported container और codec चुनें; लंबे कार्यक्रम को natural cuts पर बाँटकर अलग-अलग process करें।

यदि वीडियो पहले से object storage में है, तो उसका HTTPS URL सीधे videoUri में दे सकते हैं। URL में IP की जगह domain होना चाहिए, HEAD support होना चाहिए, सही Content-Type और Content-Length लौटने चाहिए और redirect पर निर्भर नहीं होना चाहिए; video URL limit 32 MB है। सामान्य लोकल master के लिए ephemeral upload इन hosting शर्तों से बचाता है।

Account में purchased credits भी होने चाहिए। Launch note 2 सेकंड पर 1 credit बताता है, लेकिन partial interval rounding नहीं बताता; इसलिए submission का estimatedCost और final task record का cost सुरक्षित रखें।

यह script upload, submit, wait और download पूरा करता है

यह REST example किसी SDK helper के पीछे महत्वपूर्ण steps नहीं छिपाता। यह API Key को बिना echo किए पढ़ता है, local duration और size validate करता है, ephemeral upload बनाता है, फ़ाइल भेजता है, frame-rate task submit करता है, हर पाँच सेकंड status पूछता है और सफल output डाउनलोड करता है।

Python dependency install करें और सुनिश्चित करें कि ffprobe उपलब्ध है:

python3 -m pip install requests

नीचे का code runway_fps.py नाम से सहेजें:

from __future__ import annotations

import getpass, json, os, random, subprocess, sys, time
from pathlib import Path
import requests

API = "https://api.dev.runwayml.com"
FPS = {"24", "25", "30", "48", "50", "60", "120", "23_98", "29_97", "59_94"}
RETRYABLE = {429, 502, 503, 504}


def api(session, method, path, body=None):
    for attempt in range(6):
        response = session.request(method, API + path, json=body, timeout=60)
        if response.status_code < 400:
            return response
        if response.status_code in RETRYABLE and attempt < 5:
            time.sleep((2**attempt) * (1 + random.random() * 0.5))
            continue
        raise RuntimeError(f"HTTP {response.status_code}: {response.text}")
    raise RuntimeError("RETRY_LIMIT_REACHED")


def main():
    if len(sys.argv) not in {3, 4}:
        raise SystemExit("python runway_fps.py INPUT_VIDEO TARGET_FPS [OUTPUT_VIDEO]")

    source = Path(sys.argv[1])
    target = sys.argv[2]
    output = Path(sys.argv[3]) if len(sys.argv) == 4 else Path(f"runway-{target}fps.mp4")

    if target not in FPS:
        raise SystemExit(f"UNSUPPORTED_TARGET_FRAMERATE: {target}")
    if not source.is_file():
        raise SystemExit(f"INPUT_NOT_FOUND: {source}")
    if not 512 <= source.stat().st_size <= 200 * 1024 * 1024:
        raise SystemExit(f"INVALID_UPLOAD_SIZE_BYTES: {source.stat().st_size}")

    duration = float(subprocess.run(
        ["ffprobe", "-v", "error", "-show_entries", "format=duration",
         "-of", "default=noprint_wrappers=1:nokey=1", str(source)],
        check=True, capture_output=True, text=True,
    ).stdout.strip())
    if not 0 < duration <= 300:
        raise SystemExit(f"INVALID_DURATION_SECONDS: {duration}")

    key = os.getenv("RUNWAYML_API_SECRET") or getpass.getpass("RUNWAYML_API_SECRET: ")
    session = requests.Session()
    session.headers.update({
        "Authorization": f"Bearer {key}",
        "X-Runway-Version": "2024-11-06",
        "Content-Type": "application/json",
    })

    upload_init = api(session, "POST", "/v1/uploads", {
        "filename": source.name,
        "type": "ephemeral",
    }).json()
    with source.open("rb") as handle:
        upload = requests.post(
            upload_init["uploadUrl"],
            data=upload_init["fields"],
            files={"file": (source.name, handle)},
            timeout=300,
        )
    if upload.status_code >= 400:
        raise RuntimeError(
            f"UPLOAD_FAILED_REQUEST_NEW_UPLOAD: HTTP {upload.status_code}: {upload.text}"
        )

    created = api(session, "POST", "/v1/video_upscale", {
        "model": "enhance_frame_rate",
        "videoUri": upload_init["runwayUri"],
        "targetFramerate": target,
    }).json()
    task_id = created["id"]
    print(json.dumps({"id": task_id, "estimatedCost": created.get("estimatedCost")}, indent=2))

    while True:
        task = api(session, "GET", f"/v1/tasks/{task_id}").json()
        status = task["status"]
        if status in {"PENDING", "THROTTLED", "RUNNING"}:
            time.sleep(5)
            continue
        if status == "SUCCEEDED":
            urls = task.get("output") or []
            if not urls:
                raise RuntimeError("SUCCEEDED_WITHOUT_OUTPUT")
            with requests.get(urls[0], stream=True, timeout=300) as download:
                download.raise_for_status()
                with output.open("wb") as saved:
                    for chunk in download.iter_content(1024 * 1024):
                        if chunk:
                            saved.write(chunk)
            break
        if status == "FAILED":
            raise RuntimeError(json.dumps({
                "status": status,
                "failure": task.get("failure"),
                "failureCode": task.get("failureCode"),
                "cost": task.get("cost"),
            }, ensure_ascii=False))
        if status == "CANCELLED":
            raise RuntimeError(json.dumps({"status": status, "cost": task.get("cost")}))
        raise RuntimeError(f"UNKNOWN_TASK_STATUS: {status}")

    subprocess.run([
        "ffprobe", "-v", "error", "-show_entries",
        "stream=codec_name,width,height,r_frame_rate,avg_frame_rate,time_base,duration:format=duration",
        "-of", "json", str(output),
    ], check=True)
    print(output.resolve())


if __name__ == "__main__":
    main()

input.mp4 को 60 fps में बदलकर output-60fps.mp4 सहेजने का उदाहरण:

python3 runway_fps.py input.mp4 60 output-60fps.mp4

Key केवल RUNWAYML_API_SECRET: prompt आने पर दर्ज करें। Value दिखाई नहीं देती, shell history में नहीं जाती और script उसे file में नहीं लिखता। यदि environment variable पहले से सुरक्षित तरीके से set है, script वही पढ़ेगा।

Script के तीन API stages समझें

तीनों stages सफल होने के बाद ही generation पूरी होती है। Field names case-sensitive हैं; REST JSON में videoUri और targetFramerate ही लिखें।

Stage	Request	Required content	Success signal
Upload initialize	`POST https://api.dev.runwayml.com/v1/uploads`	`filename`, `type: "ephemeral"`	`uploadUrl`, `fields`, `runwayUri` मिलते हैं
Frame-rate submit	`POST https://api.dev.runwayml.com/v1/video_upscale`	`model: "enhance_frame_rate"`, `videoUri`, `targetFramerate`	Task `id` और `estimatedCost` मिलते हैं
Task retrieve	`GET https://api.dev.runwayml.com/v1/tasks/{id}`	Path में task ID	`status: "SUCCEEDED"` और non-empty `output`

Initialization के बाद uploadUrl पर multipart POST भेजें, लौटे हुए सभी fields ज्यों के त्यों रखें और video को file field में लगाएँ। Transfer सफल होने के बाद ही runwayUri enhancement request में उपयोग योग्य है। URI 24 घंटे valid रहता है।

Success मिलते ही output डाउनलोड कर स्थायी रूप से सहेजें

PENDING, THROTTLED या RUNNING पर प्रतीक्षा जारी रखें; Runway एक task के लिए पाँच सेकंड से जल्दी नया update अपेक्षित न करने को कहता है। output[0] केवल SUCCEEDED पर पढ़ें। FAILED और CANCELLED terminal failures हैं।

Output URL सामान्यतः 24–48 घंटे में expire होता है, इसलिए asset तुरंत अपने persistent storage में सहेजें और temporary URL को final delivery link न बनाएँ। Link expire हो जाए तो पहले उसी task को फिर fetch करके नया URL लें, नई paid generation तुरंत न चलाएँ। Download success केवल API job completion बताता है; नीचे की acceptance जाँच अभी भी आवश्यक है।

uploadUrl पर multipart POST fail हो तो उसी presigned upload को retry न करें; /v1/uploads फिर call करके नया upload शुरू करें। 400, 401, 404 या 405 पर input, key, resource या method ठीक करें। Example केवल 429, 502, 503, 504 को exponential backoff और jitter के साथ retry करता है।

Task FAILED हो तो failure, failureCode और cost सहेजें: SAFETY.* retry न करें; ASSET.INVALID पर media duration, dimensions या codec ठीक करें; INTERNAL.BAD_OUTPUT.* से पहले input issue जाँचें; INPUT_PREPROCESSING.INTERNAL, INTERNAL, missing code या THIRD_PARTY.UNAVAILABLE पर delay के बाद retry किया जा सकता है। एक ही request को अनंत बार न चलाएँ।

चरण 1: ffprobe से साबित करें कि फ़ाइल लक्ष्य पूरा करती है

पहले ffprobe से average rate, time base, वास्तविक frame count, duration और audio streams जाँचें। Finder, File Explorer या player का एक FPS label acceptance test नहीं है।

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,width,height,r_frame_rate,avg_frame_rate,time_base,duration \
  -of json output.mp4

ffprobe -v error -select_streams v:0 -count_frames \
  -show_entries stream=nb_read_frames,avg_frame_rate,r_frame_rate,duration \
  -of json output.mp4

ffprobe -v error \
  -show_entries format=duration:stream=index,codec_type,codec_name,sample_rate,channels,duration \
  -of json output.mp4

इन बिंदुओं को देखें:

avg_frame_rate लक्ष्य या उसके समान rational representation से मेल खाता है।
r_frame_rate और avg_frame_rate में बिना कारण बड़ा टकराव नहीं है; बड़ा अंतर VFR जाँच माँगता है।
लगभग CFR फ़ाइल में nb_read_frames, duration × target fps के करीब है।
Output duration source के बराबर है; अंत में frame कटे नहीं हैं और frozen tail नहीं जुड़ी है।
Dimensions, codec और audio streams delivery specification के अनुसार हैं।
Audio stream duration और video stream duration में असामान्य अंतर नहीं है।

29.97 और 59.94 के लिए tools अक्सर 30000/1001 और 60000/1001 दिखाते हैं। Fraction दिखना अपने आप में failure नहीं है।

चरण 2: सबसे जोखिम वाले shots पहले जाँचें

Fast motion, occlusion edges, छोटा text और cut points पहले देखें, क्योंकि interpolation failures वहीं जल्दी दिखते हैं। 100% scale पर frame by frame या धीमी playback में ये हिस्से जाँचें:

तेज़ pans, tracking shots और तेज़ objects;
हाथ, उँगलियाँ, बाल, चश्मे की frame और होंठ;
fence, blinds, grid, छोटा text और पतली UI lines;
foreground objects जो background edge को ढकते या खोलते हैं;
पानी, धुआँ, particles, पत्तियाँ और high-frequency textures;
flashes, hard cuts, dissolves और shot change के आसपास के frames।

केवल “sharp लग रहा है या नहीं” न देखें। Reproducible defects खोजें: double contours, ghosting, मुड़े edges, एक frame के लिए गायब object, pulsing texture, विकृत अंग, cut पर blended frame या स्थिर text में jitter।

समस्या मिलने पर exact timecode, target rate, source excerpt और output excerpt दर्ज करें। इससे source में पहले से मौजूद defect, नया issue और player decoder difference अलग किए जा सकते हैं।

चरण 3: शुरुआत, बीच और अंत में audio sync जाँचें

शुरुआत में sync सही होना पूरी फ़ाइल के सही होने का प्रमाण नहीं है; fixed offset और progressive drift अलग करने के लिए शुरुआत, बीच और अंत जाँचें। यह क्रम अपनाएँ:

शुरुआत में स्पष्ट anchor खोजें—clap, plosive consonant, impact, landing या visual cut।
वही जाँच बीच और अंत में दोहराएँ।
तीनों स्थानों पर लगभग समान offset fixed delay का संकेत देता है।
अंत की ओर बढ़ती गलती duration, time base या frame-rate interpretation की समस्या हो सकती है।
Lip sync के लिए लगातार बोले गए वाक्य के शुरू, बीच और अंत को देखें, केवल एक syllable को नहीं।

लॉन्च नोट ऑडियो handling का वर्णन नहीं करता। इसलिए यह न मानें कि track हमेशा बिना बदलाव सुरक्षित रहता है या अपने आप sync हो जाता है। निष्कर्ष delivered file देखकर ही निकालें।

चरण 4: वास्तविक timeline और platform पर फिर परीक्षण करें

फ़ाइल को वास्तविक editing timeline और final platform पर अवश्य चलाएँ, क्योंकि NLE या second transcode cadence को reinterpret, speed को बदल या audio track को खो सकता है। कम से कम ये दो checks करें:

फ़ाइल को इच्छित editing timeline पर रखें और देखें कि NLE उसे reinterpret, speed change या audio track loss तो नहीं कर रहा।
अंतिम platform या device पर चलाएँ और पुष्टि करें कि second transcode ने cadence, subtitles या sync नहीं बदला।

यदि platform फिर transcode करता है, तो Runway output और platform version दोनों रखें। Upstream file को दोष देने से पहले दोनों को अलग-अलग जाँचें।

इस table से pass, rework या source segment चुनें

फ़ाइल तभी pass करें जब सभी critical items delivery requirement पूरी करें। केवल एक shot fail हो तो पूरे program को rerun करने से पहले वही segment rework करें या source shot रखें।

जाँच	Pass condition	Failure पर कार्रवाई
Target frame rate	Exact delivery cadence; 29.97/59.94 को 30/60 न माना जाए	Target या timeline interpretation सही करें
Duration और frames	Duration source के बराबर; CFR count अनुमान के करीब	VFR, truncation, frozen tail और time base जाँचें
Dimensions और codec	Editor या channel requirements के अनुसार	Specification के अनुसार rewrap या transcode करें
Fast motion	अस्वीकार्य double image, bending या object disappearance नहीं	Timecodes mark करें; दूसरा target आज़माएँ या source segment रखें
Cuts और flashes	Cuts के पास blended, repeated frames या असामान्य flicker नहीं	Natural cut पर split करें, फिर process और seam review करें
Text और UI	Glyphs, thin lines और static overlays stable रहें	Graphics को post-production में दोबारा overlay करें
Audio sync	शुरुआत, बीच और अंत में offset या drift नहीं	Stream durations/time base तुलना करें, फिर realign या transcode करें
File integrity	Full decode सफल; ending और audio tracks सही	Redownload, rewrap या task rerun करें

इन स्थितियों में 60 से 120 fps पर न जाएँ

यदि 120 fps केवल file size और downstream load बढ़ाता है, तो specification पूरा करने वाली कम rate पर रुकें। इन स्थितियों में frame rate न बढ़ाएँ:

downstream को केवल 24, 25, 29.97 या 30 fps चाहिए;
source में पहले से भारी ghosting, compression blocks या motion blur है;
subtitles, UI या thin lines कम stable हो रहे हैं;
audio-sync problem का कारण अभी स्पष्ट नहीं है;
target platform कम frame rate में forced transcode करेगा;
visible benefit नहीं है, लेकिन storage, decoding या downstream transcode load बढ़ता है।

Frame rate delivery parameter है, अलग quality score नहीं। Pass का अर्थ है “आवश्यक cadence से मेल खाता है और नए अस्वीकार्य defect नहीं हैं”, न कि “सबसे बड़ा नंबर है”।

दस चरणों में source से delivery पूरी करें

कम rework वाला क्रम specification और baseline, upload और submit, wait और save, फिर technical, visual और real-environment verification है।

Downstream specification से exact targetFramerate चुनें।
ffprobe से source rate, duration, audio और risk timecodes सहेजें; duration 300 सेकंड से अधिक न हो।
Local file के लिए POST /v1/uploads call करके uploadUrl, fields, runwayUri सहेजें।
uploadUrl पर multipart form भेजें; failure पर नया upload माँगें।
model, videoUri, targetFramerate के साथ POST /v1/video_upscale call करें।
Task id और estimatedCost सहेजें।
Terminal status तक हर पाँच सेकंड GET /v1/tasks/{id} call करें।
SUCCEEDED पर output डाउनलोड और persist करें; FAILED या CANCELLED को error type के अनुसार संभालें।
ffprobe और frame-by-frame review से actual cadence, duration, artifacts, cuts और audio sync जाँचें।
Handoff से पहले real timeline और target platform पर परीक्षण करें।