Runway Enhance Frame Rate ra mắt trên Dev API: từ 24 đến 120 fps, bao gồm cả NTSC

Runway đã đưa một mô hình nội suy khung hình mới lên API dành cho nhà phát triển của mình vào ngày 17 tháng 9 năm 2026, và chi tiết thực sự đáng quan tâm không phải là mức cao nhất của dải — mà là các tốc độ phân số. Runway Enhance Frame Rate định thời lại đoạn phim bạn đã có theo mục tiêu 24, 25, 30, 48, 50, 60 hoặc 120 fps, và nó cũng chấp nhận ba tốc độ mà truyền hình và điện ảnh thực sự cung cấp: 23.98, 29.97 và 59.94. Nhật ký thay đổi dành cho nhà phát triển của chính Runway ghi lại mô hình này là enhance_frame_rate, được gọi thông qua cùng endpoint POST /v1/video_upscale mà công ty đã dùng cho trình nâng cấp sáng tạo của mình, giới hạn ở 300 giây đầu vào mỗi tác vụ và tính phí 1 credit cho mỗi 2 giây.

Dòng tính phí đó là bất ngờ thứ hai. Nội suy khung hình thường được tính giá theo đầu ra — Magnific Video Upscaler của chính Runway trên cùng endpoint đó tính 0,7 credit cho mỗi khung hình đầu ra ở 720p/1K — nghĩa là chuyển đổi từ 24 fps lên 120 fps tốn gấp năm lần so với chuyển đổi từ 24 lên 25. enhance_frame_rate được tính phí theo mỗi giây đầu vào. Nhân khung hình lên 5× và lên 1,05× có chi phí hoàn toàn giống nhau. Nếu công việc của bạn là xuất một đoạn phim ở nhiều tốc độ khung hình khác nhau, chỉ một dòng đó trong bảng giá đã đảo ngược phép tính thông thường.

Thời điểm cũng đầy dụng ý. Công cụ Frame Interpolation độc lập của Runway nằm trong danh sách công cụ bị ngừng hỗ trợ chính thức của hãng, với ứng dụng Animate Keyframes được nêu tên là công cụ thay thế. Enhance Frame Rate không phải là sự hồi sinh của công cụ web đó — đây là tính năng nội suy khung hình được xây dựng lại dưới dạng mô hình API, hướng đến các pipeline thay vì hướng đến một người dùng đang nhấp chuột qua dòng thời gian.

Enhance Frame Rate thực sự làm gì

Đây là một mô hình định thời lại, không phải mô hình sinh. Không có prompt, không có hình ảnh, không có clip tham chiếu. Bạn đưa cho nó một video đã tồn tại — bất cứ thứ gì từ máy quay, một bản dựng, hay một mô hình Runway khác — và nó tổng hợp các khung hình trung gian cần thiết để đạt được tốc độ mục tiêu. Thông báo của Runway trên chính tài khoản X của họ cũng diễn đạt theo cách đó: “chuyển đổi mọi đoạn phim thành các thông số kỹ thuật bạn cần.”

Về mặt cơ chế, đây là một tác vụ bất đồng bộ trên endpoint nâng cấp video. Bạn POST một URI video, đặt model: "enhance_frame_rate", nhận về một task id, rồi poll để lấy kết quả. Vì nó dùng chung endpoint với trình nâng cấp của Runway, một pipeline vốn đã giao tiếp với /v1/video_upscale chỉ cần thay đổi tham số thay vì phải tích hợp mới.

Nhật ký thay đổi của Runway liệt kê những nội dung sau đây là thông số kỹ thuật hiện hành do nhà cung cấp công bố. Không nội dung nào trong đó được xác minh độc lập — không có đánh giá chuẩn nào từ bên thứ ba cho mô hình này, và nó mới chỉ được một ngày vào thời điểm viết bài.

• Tốc độ khung hình mục tiêu — 24, 25, 30, 48, 50, 60 và 120 fps, cộng thêm 23.98, 29.97 và 59.94 fps (được viết trong API là 23_98, 29_97 và 59_94)

• Giới hạn đầu vào — 300 giây mỗi tác vụ

• Giá — 1 credit cho mỗi 2 giây đầu vào; mỗi credit API Runway có giá $0.01

• Truy cập — POST /v1/video_upscale với model: "enhance_frame_rate", trên Runway Dev

• Tiền lệ tại Runway — một loại tác vụ frame_interpolation_v1 đã tồn tại trong phiên bản API 2024-11-06; công cụ Frame Interpolation trên web độc lập đã bị ngừng hỗ trợ

• Đánh giá độc lập — chưa có công bố nào

Thang tốc độ khung hình, và vì sao 23.98 mới là điểm nhấn thực sự

Mọi công cụ nội suy dành cho người dùng phổ thông đều cung cấp tốc độ nguyên. Cột đáng chú ý ở đây là cột phân số, vì tốc độ phân số mới là điều mà thông số kỹ thuật phân phối thực sự nêu:

• 23.98 (23.976) — tốc độ phim NTSC. Gần như mọi bản master chiếu rạp và phát trực tuyến, và là tốc độ mà DVD và Blu-ray được tạo theo.

• 24 — tốc độ khung hình phim thực sự, vẫn được dùng cho DCP và nhiều sản phẩm bàn giao cho liên hoan phim.

• 25 — Các vùng lãnh thổ PAL và EBU: Vương quốc Anh, phần lớn châu Âu, Úc, phần lớn châu Á và châu Phi.

• 29.97 — phát sóng NTSC, người anh em phân số của 30.

• 30 — tốc độ nguyên cho ghi màn hình, web và cảnh quay game.

• 48 — điện ảnh tốc độ khung hình cao (tốc độ mà các phim Hobbit được quay và chiếu).

• 50 — tốc độ khung hình cao PAL, chính xác bằng 2× 25.

• 59.94 — tốc độ khung hình cao NTSC, tốc độ truyền phát sóng 60 Hz tại Mỹ và Nhật Bản.

• 60 — số nguyên 60 Hz, mục tiêu phổ biến để phát lại web mượt mà.

• 120 — chuyển động chậm và khả năng hiển thị tần số quét cao.

Khoảng cách giữa 24 và 23.976 trông có vẻ nhỏ nhặt nhưng thực tế không phải vậy. Sau một giờ chạy, hai mức này lệch nhau khoảng 3,6 giây. Đưa một bản master 24.000 vào chuỗi phân phối 23,98 và bạn sẽ gặp tình trạng trôi đồng bộ âm thanh cùng các lỗi nhịp mà khâu QC phát sóng sẽ đánh trượt — đó là lý do các xưởng hậu kỳ trước đây phải chạy một bước conform riêng để resample tốc độ khung hình, hoặc từ chối nhận việc. Một công cụ xuất trực tiếp tốc độ khung hình phân số sẽ loại bỏ một công đoạn khỏi chuỗi đó. Đó là một tuyên bố hẹp hơn nhiều, nhàm chán hơn nhiều so với "120 fps", và với bất kỳ ai giao sản phẩm cho đài truyền hình, đó chính là lý do để quan tâm.

Trên thực tế, các mục tiêu 48 và 120 là những mục tiêu cần phải hoài nghi. Nội suy tư liệu 24 fps lên 120 fps nghĩa là tạo ra bốn khung hình cho mỗi khung hình thật, và khi có chuyển động nhanh, bị che khuất hoặc nhòe chuyển động mạnh, mọi loại bộ nội suy đều tạo ra hiện tượng bóng ma và biến dạng. Runway không công bố phân tích lỗi hình ảnh, không so sánh với bất kỳ bộ nội suy nào khác và không có hướng dẫn chất lượng cho từng cảnh quay — vậy nên lập trường trung thực là thông số kỹ thuật hỗ trợ 120, còn việc 120 trông ra sao trên tư liệu của bạn thì chưa được kiểm chứng.

Chi phí là bao nhiêu, được tính toán chi tiết

Phép tính gọn gàng đến lạ thường vì đơn vị là số giây đầu vào. Với 1 credit cho mỗi 2 giây, và $0,01 mỗi credit trên API dành cho nhà phát triển của Runway (trả trước, tối thiểu $10 cho 1.000 credit):

• Một clip dài 10 giây, ở bất kỳ tốc độ đích nào — 5 credit, khoảng $0.05

• Clip 30 giây — 15 credits, khoảng $0.15

• Một clip 60 giây — 30 credit, khoảng $0.30

• Một clip 5 phút, mức trần 300 giây — 150 tín dụng, khoảng 1,50 USD

• Một clip 90 giây, 24 → 25 fps — 45 credit, khoảng 0,45 USD

• Cùng một clip dài 90 giây, 24 → 120 fps — 45 credit, khoảng $0,45

Hai dòng cuối đó là toàn bộ lập luận về giá. Theo mô hình tính theo từng khung hình đầu ra, tác vụ thứ hai sẽ có số khung hình gấp 5 lần và do đó hóa đơn cũng vào khoảng gấp 5 lần. Ở đây thì miễn phí.

Việc so sánh với đối thủ trên cùng endpoint giúp làm rõ vấn đề. Magnific Video Upscaler tính phí theo từng khung hình đầu ra — 0,7 credit ở 720p/1K, 0,9 ở 2K, 1,2 ở 4K, với mức tối thiểu một credit cho mỗi lần tạo. Một clip 10 giây, 30 fps là 300 khung hình đầu ra, nên mức 720p/1K rơi vào 210 credit, tức khoảng $2,10. Cùng clip đó khi chạy qua enhance_frame_rate chỉ tốn 5 credit, khoảng $0,05. Nếu bạn muốn tốc độ khung hình cao hơn chứ không phải hình ảnh lớn hơn, việc dùng upscaler sẽ tốn khoảng gấp bốn mươi lần. Cũng lưu ý rằng việc bật tính năng tăng fps tùy chọn của upscaler sẽ thay đổi số khung hình đầu ra và do đó làm hóa đơn đó tăng thêm — tài liệu về giá của Runway nói rõ như vậy.

Một lưu ý về chi phí đáng nêu ra: trang định giá dành cho nhà phát triển của Runway mới là nguồn chính thức ở đây, chứ không phải bài viết này, và giá credit được báo cáo là đang trong diện xem xét để chuyển sang định giá tùy chỉnh kể từ tháng 8 năm 2026. Hãy kiểm tra cổng thông tin trước khi bạn dự trù ngân sách cho một lô lớn.

Giới hạn 300 giây và cách xử lý nó

Mỗi tác vụ chỉ được giới hạn ở 300 giây đầu vào. Con số đó thì thoải mái cho một cảnh quay nhưng lại ngắn đối với một cuộn phim, nên bất cứ thứ gì dài hơn đều phải được chia đoạn — và cách bạn chia đoạn quan trọng hơn chính giới hạn đó.

Cắt tại ranh giới cảnh, không theo một nhịp cố định. Các bộ nội suy suy luận chuyển động giữa các khung hình liền kề; tại một điểm cắt cứng, khung hình cuối của cảnh A và khung hình đầu tiên của cảnh B không có mối quan hệ chuyển động nào cả, và một mô hình không phát hiện được điểm cắt sẽ sẵn sàng bịa ra một morph giữa chúng. Nhật ký thay đổi của Runway không ghi tài liệu về tính năng phát hiện cảnh tự động cho mô hình này, nên giả định an toàn là không có tính năng đó. Chia khối tại các điểm cắt, nội suy từng khối, rồi ghép lại trên dòng thời gian ở tốc độ mới.

Lời khuyên đó không dành riêng cho Runway — đó là lưu ý tiêu chuẩn về việc điều chỉnh thời gian bằng AI ở mọi nơi. Một bài báo SMPTE năm 2025 về hậu kỳ có sự hỗ trợ của AI, mô tả pipeline nội suy được tối ưu hóa bằng TensorRT cho các chuyển đổi như 23.976 → 25 và 29.97 → 23.976, cũng đưa ra quan điểm tương tự: nội dung đã chuyển đổi khung hình cần ngắt khung tại các đoạn cắt cảnh, và kiểm tra chất lượng (QC) sau đó, nếu không mô hình sẽ tạo ảo giác qua mối nối. Hãy dự kiến lượt chạy đầu tiên sẽ cần thay thế khung thủ công xung quanh các chuyển tiếp khó.

Vị thế của nó so với các lựa chọn thay thế

Nội suy khung hình đã là một bài toán gần như được giải quyết từ lâu, dưới hai dạng mà cả hai đều trông khác với dạng này.

• Bộ ứng dụng desktop — các mô hình Apollo và Chronos của Topaz Video AI là điểm tham chiếu cho việc retiming tập trung vào chất lượng. Giấy phép vĩnh viễn, GPU của riêng bạn, không tính theo giây, và một lượt tinh chỉnh dành cho người hiểu rõ mình đang xem xét điều gì.

• Các bộ nội suy mã nguồn mở — RIFE và các mô hình tương tự, tự vận hành, thực tế miễn phí ở chi phí biên một khi bạn đã sở hữu phần cứng, và là nền tảng của hầu hết các pipeline tùy chỉnh mà các xưởng hậu kỳ tự xây dựng.

• Runway Enhance Frame Rate — không cần tính toán cục bộ, chỉ một lệnh gọi API, tính phí theo từng giây đầu vào, và những tốc độ NTSC phân số mà hai công cụ kia từ trước đến nay vẫn luôn để bạn tự thủ công xoay xở cho khớp.

Sự đánh đổi là rõ ràng. Đối với một cảnh quay một lần trên máy trạm bạn đã sở hữu, một trình nội suy cục bộ sẽ rẻ hơn và cung cấp cho bạn các nút điều chỉnh mà Runway không có. Đối với tư liệu đến trong một quy trình tự động, hoặc một ma trận sản phẩm bàn giao nơi cùng một clip phải xuất ra ở 23.98 cho một khu vực và 25 cho khu vực khác, một API trả về tốc độ phân số trực tiếp loại bỏ một bước conform — và giá trên mỗi giây đầu vào nghĩa là đầu ra đa tốc độ không tốn thêm chi phí.

Lớp định tuyến xung quanh nó

Retiming là một giai đoạn trong một pipeline mà có một bước mô hình ngôn ngữ ở đâu đó gần đó. Danh sách cảnh quay và ghi chú conform, khâu phụ đề và chú thích phải được định thời lại theo tốc độ khung hình mới, siêu dữ liệu phân phối theo từng vùng lãnh thổ, nhật ký QC — đó là công việc văn bản, và là phần của pipeline video mà không ai dự trù ngân sách cho.

Lớp đó chạy trên một khóa duy nhất xuyên suốt 200 mô hình trong danh mục OrcaRouter, với giá niêm yết của nhà cung cấp được chuyển nguyên ở mức markup 0% và tự động chuyển đổi dự phòng giữa các nhà cung cấp, để một mô hình mới hơn hoặc rẻ hơn có thể được thử trên lưu lượng trực tiếp mà không đặt cược một đường dẫn sản xuất vào nó. Nói chính xác về phạm vi: Runway Enhance Frame Rate là một mô hình Runway Dev API, được gọi trên endpoint của chính Runway, và OrcaRouter không phục vụ nó. Điều chúng tôi bao phủ là mọi thứ xung quanh nó.

Điều gì vẫn chưa được biết

Hầu như không có gì về chất lượng. Mô hình này chỉ mới khoảng một ngày tuổi vào thời điểm viết bài, và mọi thông tin ở trên về hành vi của nó đều đến từ nhật ký thay đổi và thông báo của chính Runway. Cụ thể là chưa được xác minh:

• Hành vi của artefact khi chuyển động nhanh, bị che khuất, nhòe chuyển động và nguồn bitrate thấp — không có thử nghiệm nào được công bố bởi bất kỳ ai

• Liệu nó tự động phát hiện các điểm cắt cảnh hay hòa trộn xuyên qua chúng

• Liệu âm thanh được truyền qua, lấy mẫu lại hay bị loại bỏ khi tốc độ khung hình thay đổi

• Nó so sánh về chất lượng với RIFE, Apollo hoặc Chronos như thế nào — chưa có so sánh đối đầu trực tiếp nào

• Liệu mức giá trên mỗi giây đầu vào có giữ nguyên khi tốc độ mục tiêu tăng lên, hay sẽ được phân tầng lại sau này

Hãy coi các mục tiêu 120 fps và 48 fps chỉ là tuyên bố cho đến khi bạn đã chạy footage của riêng mình qua chúng, và kiểm tra cách xử lý cắt trên clip đầu tiên bạn gửi.

Ai nên di chuyển bây giờ?

Hãy hành động ngay nếu bạn phân phối theo thông số kỹ thuật phát sóng hoặc đa lãnh thổ và hiện đang phải trả tiền cho một bước conform, nếu đoạn phim của bạn đã chạy qua một quy trình tự động có thể tiếp nhận thêm một lệnh gọi API nữa, hoặc nếu bạn muốn có chuyển động chậm từ một máy ảnh chưa từng quay tốc độ cao và bạn không muốn phải chạy GPU.

Hãy chờ nếu bạn cần hơn năm phút trong một tác vụ đơn lẻ và không thể phân đoạn tại các điểm cắt, nếu bạn cũng cần nâng độ phân giải — đó là upscaler, với mức giá theo từng khung hình — hoặc nếu bạn đã sở hữu một trình nội suy trên máy tính để bàn và đây là cảnh quay một lần. Và hãy chờ nếu chất lượng là yếu tố quyết định thay vì sự tiện lợi: chưa ai ngoài Runway công bố một con số, và so sánh độc lập đầu tiên là thứ đáng để chờ đợi.

Điều đáng để quan sát là liệu Runway có tiếp tục mở rộng endpoint này theo từng mô hình hay không. Nó đã có sẵn một upscaler sáng tạo và giờ là một retimer, cả hai đều dùng POST /v1/video_upscale, cả hai đều được định giá theo những đơn vị hoàn toàn khác nhau. Với bất kỳ ai đang xây dựng các pipeline phân phối, đơn vị — giây đầu vào thay vì khung hình đầu ra — chính là phần đáng để thiết kế xoay quanh.