Runway Enhance Frame Rate เปิดให้ใช้งานบน Dev API แล้ว: 24 ถึง 120 fps พร้อมรองรับ NTSC

Runway เปิดตัวโมเดลแทรกเฟรมใหม่บน API สำหรับนักพัฒนาของบริษัทเมื่อวันที่ 17 กันยายน 2026 และรายละเอียดที่สำคัญจริง ๆ ไม่ใช่ค่าสูงสุดของช่วงพิสัย แต่เป็นอัตราแบบเศษส่วนต่างหาก Runway Enhance Frame Rate จะปรับความเร็วฟุตเทจที่คุณมีอยู่แล้วให้เป็นเป้าหมายที่ 24, 25, 30, 48, 50, 60 หรือ 120 fps และยังรองรับอัตราทั้งสามแบบที่งานออกอากาศและงานภาพยนตร์ส่งมอบได้จริง ได้แก่ 23.98, 29.97 และ 59.94 บันทึกการเปลี่ยนแปลงสำหรับนักพัฒนาของ Runway ระบุโมเดลนี้ว่า enhance_frame_rate ซึ่งเรียกใช้งานผ่านปลายทาง POST /v1/video_upscale เดียวกันกับที่บริษัทใช้อยู่แล้วสำหรับตัวอัปสเกลเลอร์เชิงสร้างสรรค์ของตน โดยจำกัดอินพุตไว้ที่ 300 วินาทีต่องาน และคิดค่าบริการ 1 เครดิตต่อ 2 วินาที

บรรทัดการเรียกเก็บเงินนั้นคือความประหลาดใจที่สอง การแทรกเฟรมมักคิดราคาตามเอาต์พุต — Magnific Video Upscaler ของ Runway เองบนเอนด์พอยต์เดียวกันนั้นคิด 0.7 เครดิตต่อเฟรมเอาต์พุตที่ 720p/1K — ซึ่งหมายความว่าการแปลง 24 fps เป็น 120 fps มีค่าใช้จ่ายเป็นห้าเท่าของการแปลง 24 เป็น 25 fps enhance_frame_rate คิดค่าบริการต่อวินาทีของอินพุต การคูณเฟรม 5× กับการคูณ 1.05× มีค่าใช้จ่ายเท่ากันเป๊ะ หากงานของคุณคือการส่งฟุตเทจชิ้นเดียวในหลายอัตราเฟรม บรรทัดเดียวในตารางราคานั้นก็พลิกการคำนวณตามปกติ

จังหวะเวลาก็มีนัยสำคัญเช่นกัน เครื่องมือ Frame Interpolation แบบสแตนด์อโลนของ Runway อยู่ในรายการเครื่องมือที่เลิกใช้อย่างเป็นทางการของบริษัท โดยมีแอป Animate Keyframes ถูกระบุชื่อเป็นเครื่องมือแทน Enhance Frame Rate ไม่ใช่การนำเครื่องมือเว็บนั้นกลับมาอีกครั้ง — แต่เป็น Frame Interpolation ที่สร้างใหม่ในรูปแบบโมเดล API โดยมุ่งเป้าไปที่ไปป์ไลน์ มากกว่าจะให้ใครสักคนคลิกไปตามไทม์ไลน์

Enhance Frame Rate ทำอะไรจริง ๆ

นี่คือโมเดลรีไทม์มิ่ง ไม่ใช่โมเดลเจเนอเรทีฟ ไม่มีพรอมป์ต์ ไม่มีภาพ ไม่มีคลิปอ้างอิง คุณส่งวิดีโอที่มีอยู่แล้วให้มัน — ไม่ว่าจะมาจากกล้อง จากการตัดต่อ หรือจากโมเดล Runway อื่น — แล้วมันจะสังเคราะห์เฟรมระหว่างกลางที่จำเป็นเพื่อให้ได้อัตราเป้าหมาย ประกาศของ Runway บนบัญชี X ของตัวเองก็วางกรอบแบบเดียวกันว่า "แปลงฟุตเทจใด ๆ ให้เป็นสเปกที่คุณต้องการ"

ในทางกลไกแล้ว มันเป็นงานแบบอะซิงโครนัสบน endpoint สำหรับอัปสเกลวิดีโอ คุณ POST URI ของวิดีโอ ตั้งค่า model: "enhance_frame_rate" ได้ task id กลับมา แล้วโพลล์เพื่อรอผลลัพธ์ เนื่องจากมันใช้ endpoint ร่วมกับตัวอัปสเกลของ Runway pipeline ที่สื่อสารกับ /v1/video_upscale อยู่แล้วจึงเพียงต้องเปลี่ยนพารามิเตอร์ ไม่ใช่ทำอินทิเกรชันใหม่

บันทึกการเปลี่ยนแปลงของ Runway ระบุรายการต่อไปนี้ว่าเป็นสเปกที่ผู้ให้บริการระบุไว้ในปัจจุบัน ทั้งหมดนี้ยังไม่ได้รับการตรวจสอบยืนยันอย่างอิสระ — ไม่มีผลทดสอบเบนช์มาร์กจากบุคคลที่สามสำหรับโมเดลนี้ และ ณ เวลาที่เขียนอยู่นี้ มันมีอายุเพียงหนึ่งวันเท่านั้น

• อัตราเป้าหมาย — 24, 25, 30, 48, 50, 60 และ 120 fps รวมถึง 23.98, 29.97 และ 59.94 fps (เขียนใน API เป็น 23_98, 29_97 และ 59_94)

• ขีดจำกัดอินพุต — 300 วินาทีต่องาน

• ราคา — 1 เครดิตต่ออินพุต 2 วินาที; เครดิต Runway API ราคาเครดิตละ $0.01

• การเข้าถึง — POST /v1/video_upscale ด้วย model: "enhance_frame_rate" บน Runway Dev

• สิ่งที่เคยมีมาก่อนที่ Runway — ประเภทงาน frame_interpolation_v1 เคยมีอยู่ภายใต้ API เวอร์ชัน 2024-11-06; เครื่องมือ Frame Interpolation บนเว็บแบบสแตนด์อโลนถูกเลิกใช้งานแล้ว

• การประเมินโดยอิสระ — ยังไม่มีฉบับเผยแพร่

บันไดอัตราเฟรม และเหตุใด 23.98 จึงเป็นพาดหัวข่าวที่แท้จริง

เครื่องมืออินเทอร์โพเลชันสำหรับผู้ใช้ทั่วไปทุกตัวมีอัตราแบบจำนวนเต็ม คอลัมน์ที่น่าสนใจตรงนี้คือคอลัมน์แบบเศษส่วน เพราะอัตราแบบเศษส่วนคือสิ่งที่สเปกการส่งมอบระบุไว้จริง ๆ:

• 23.98 (23.976) — อัตราแบบฟิล์ม NTSC ซึ่งเป็นอัตราของมาสเตอร์โรงภาพยนตร์และสตรีมมิ่งเกือบทั้งหมด และเป็นอัตราที่ DVD และ Blu-ray ถูกสร้างขึ้นให้สอดคล้องด้วย

• 24 — อัตราเฟรมมาตรฐานของฟิล์มจริง ยังคงใช้สำหรับ DCP และงานส่งมอบสำหรับเทศกาลภาพยนตร์หลายแห่ง

• 25 — ดินแดน PAL และ EBU: สหราชอาณาจักร, ยุโรปส่วนใหญ่, ออสเตรเลีย, พื้นที่ส่วนใหญ่ของเอเชียและแอฟริกา

• 29.97 — การออกอากาศระบบ NTSC พี่น้องเชิงเศษส่วนของ 30

• 30 — อัตราแบบจำนวนเต็มสำหรับการบันทึกหน้าจอ ภาพจากเว็บ และเกม

• 48 — ภาพยนตร์เฟรมเรตสูง (อัตราที่ใช้ถ่ายทำและฉายภาพยนตร์ Hobbit)

• 50 — เฟรมเรตสูงแบบ PAL ซึ่งเท่ากับ 2× ของ 25 พอดี

• 59.94 — NTSC อัตราเฟรมสูง ซึ่งเป็นอัตราการส่งสัญญาณออกอากาศที่ 60 Hz ในสหรัฐอเมริกาและญี่ปุ่น

• 60 — จำนวนเต็ม 60 Hz ซึ่งเป็นเป้าหมายทั่วไปสำหรับการเล่นวิดีโอบนเว็บให้ราบรื่น

• 120 — สโลว์โมชัน และการแสดงผลที่รีเฟรชสูง

ช่องว่างระหว่าง 24 กับ 23.976 ดูเหมือนไม่มีนัยสำคัญ แต่ไม่ใช่เลย ตลอดความยาวหนึ่งชั่วโมง ทั้งสองจะคลาดเคลื่อนออกจากกันประมาณ 3.6 วินาที ป้อนมาสเตอร์ 24.000 เข้าสู่ไปป์ไลน์ส่งมอบ 23.98 แล้วคุณจะได้การคลาดเคลื่อนของซิงก์เสียงและข้อผิดพลาดด้านแคเดนซ์ที่ QC ฝั่งออกอากาศจะไม่ผ่าน ซึ่งเป็นเหตุผลว่าทำไมสตูดิโอโพสต์โปรดักชันในอดีตจึงต้องรันขั้นตอน conform แยกต่างหากเพื่อรีแซมเปิลอัตรา หรือไม่ก็ปฏิเสธงานนั้น เครื่องมือที่ส่งอัตราเศษส่วนออกมาได้โดยตรงจะตัดขั้นตอนหนึ่งออกจากไปป์ไลน์นั้น นั่นเป็นข้อกล่าวอ้างที่แคบกว่ามากและน่าเบื่อกว่ามากเมื่อเทียบกับ “120 fps” และสำหรับใครก็ตามที่ส่งมอบให้กับผู้แพร่ภาพกระจายเสียง นี่คือเหตุผลที่ต้องสนใจ

เป้าหมาย 48 และ 120 คือสิ่งที่ควรตั้งข้อกังขาในทางปฏิบัติ การอินเทอร์โพเลตฟุตเทจ 24 fps ขึ้นไปเป็น 120 fps หมายถึงการสร้างเฟรมขึ้นมา 4 เฟรมสำหรับทุกเฟรมจริงหนึ่งเฟรม และเมื่อมีการเคลื่อนไหวเร็ว การบดบัง หรือโมชันเบลอหนัก ๆ อินเทอร์โพเลเตอร์ทุกแบบต่างก่อให้เกิดอาการภาพซ้อนและภาพบิดเบี้ยว Runway ไม่ได้เผยแพร่การวิเคราะห์อาร์ติแฟกต์ ไม่มีการเปรียบเทียบกับอินเทอร์โพเลเตอร์อื่นใด และไม่มีคำแนะนำคุณภาพรายช็อต — ฉะนั้นจุดยืนที่ตรงไปตรงมาคือ สเปกรองรับ 120 และภาพที่ 120 จะออกมาเป็นอย่างไรบนฟุตเทจของคุณนั้นยังไม่ได้รับการทดสอบ

ค่าใช้จ่าย เมื่อคิดจนครบทุกขั้นตอน

การคำนวณนี้เรียบง่ายผิดปกติเพราะหน่วยคือวินาทีอินพุต ที่ 1 เครดิตต่อ 2 วินาที และ $0.01 ต่อเครดิตบน API สำหรับนักพัฒนาของ Runway (ชำระล่วงหน้า ขั้นต่ำ $10 สำหรับ 1,000 เครดิต):

• คลิปความยาว 10 วินาที ที่อัตราเป้าหมายใดก็ได้ — 5 เครดิต ประมาณ $0.05

• คลิปความยาว 30 วินาที — 15 เครดิต ประมาณ $0.15

• คลิป 60 วินาที — 30 เครดิต ประมาณ $0.30

• คลิป 5 นาที เพดาน 300 วินาที — 150 เครดิต ประมาณ $1.50

• คลิปความยาว 90 วินาที, 24 → 25 fps — 45 เครดิต, ประมาณ $0.45

• คลิป 90 วินาทีเดียวกัน 24 → 120 fps — 45 เครดิต ประมาณ $0.45

สองบรรทัดสุดท้ายนั้นคือข้อโต้แย้งเรื่องราคาทั้งหมด ในโมเดลที่คิดตามจำนวนเฟรมเอาต์พุต งานที่สองจะมีจำนวนเฟรมเป็น 5 เท่า และดังนั้นค่าบิลก็จะประมาณ 5 เท่า แต่ที่นี่ฟรี

การเปรียบเทียบกับตัวเลือกข้างเคียงบนเอนด์พอยต์เดียวกันทำให้ประเด็นนี้ชัดเจนเป็นรูปธรรม Magnific Video Upscaler คิดค่าบริการต่อเฟรมเอาต์พุต — 0.7 เครดิตที่ 720p/1K, 0.9 ที่ 2K, 1.2 ที่ 4K โดยมีขั้นต่ำหนึ่งเครดิตต่อการสร้างหนึ่งครั้ง คลิปความยาว 10 วินาทีที่ 30 fps คือ 300 เฟรมเอาต์พุต ดังนั้นอัตราที่ 720p/1K จะอยู่ที่ 210 เครดิต หรือประมาณ $2.10 คลิปเดียวกันเมื่อผ่าน enhance_frame_rate ใช้ 5 เครดิต ประมาณ $0.05 หากคุณต้องการอัตราเฟรมที่สูงขึ้น ไม่ใช่ภาพที่ใหญ่ขึ้น การเลือกใช้ upscaler จะมีค่าใช้จ่ายสูงกว่าประมาณสี่สิบเท่า โปรดทราบด้วยว่าการเปิดใช้ fps boost แบบเลือกได้ของ upscaler จะเปลี่ยนจำนวนเฟรมเอาต์พุต จึงทำให้ค่าบริการนั้นสูงขึ้นไปอีก — เอกสารราคาของ Runway ระบุไว้อย่างชัดเจน

ข้อควรระวังด้านค่าใช้จ่ายหนึ่งข้อที่ควรชี้ให้เห็น: หน้าเว็บราคาสำหรับนักพัฒนาของ Runway คือแหล่งอ้างอิงที่เชื่อถือได้ในเรื่องนี้ ไม่ใช่บทความนี้ และราคาเครดิตถูกรายงานว่าอยู่ระหว่างการทบทวนเพื่อปรับไปสู่ราคาแบบกำหนดเองตั้งแต่เดือนสิงหาคม 2026 ตรวจสอบพอร์ทัลก่อนที่คุณจะจัดงบประมาณสำหรับการใช้งานเป็นชุดใหญ่

เพดาน 300 วินาที และวิธีหลีกเลี่ยง

ทุกงานถูกจำกัดอินพุตไว้ที่ 300 วินาที สำหรับช็อตเดียวถือว่าเหลือเฟือ แต่สำหรับรีลถือว่าน้อย ดังนั้นอะไรที่ยาวกว่านี้จึงต้องถูกแบ่งเป็นช่วง และวิธีที่คุณแบ่งช่วงสำคัญกว่าเพดานนั้นเอง

ตัดที่ขอบเขตฉาก ไม่ใช่ตามเวลาที่กำหนดตายตัว ตัวสอดแทรกอนุมานการเคลื่อนไหวระหว่างเฟรมที่อยู่ติดกัน ณ จุดตัดแบบทันที เฟรมสุดท้ายของช็อต A และเฟรมแรกของช็อต B ไม่มีความสัมพันธ์ด้านการเคลื่อนไหวเลยแม้แต่น้อย และโมเดลที่ไม่ตรวจจับการตัดจะสร้างมอร์ฟระหว่างเฟรมเหล่านั้นขึ้นมาอย่างง่ายดาย บันทึกการเปลี่ยนแปลงของ Runway ไม่ได้ระบุถึงการตรวจจับฉากอัตโนมัติสำหรับโมเดลนี้ ดังนั้นสมมติฐานที่ปลอดภัยคือไม่มีสิ่งนั้นอยู่ แบ่งเป็นชิ้นส่วนที่จุดตัด สอดแทรกแต่ละชิ้นส่วน แล้วประกอบกลับบนไทม์ไลน์ที่อัตราใหม่

คำแนะนำนั้นไม่ได้เจาะจงกับ Runway — มันเป็นข้อควรระวังมาตรฐานเกี่ยวกับการรีไทม์ด้วย AI ในทุกที่ เอกสาร SMPTE ปี 2025 เกี่ยวกับงานหลังการผลิตที่ใช้ AI ช่วย ซึ่งอธิบายไปป์ไลน์การแทรกเฟรมที่ปรับให้เหมาะกับ TensorRT สำหรับการแปลงเช่น 23.976 → 25 และ 29.97 → 23.976 ก็ชี้ประเด็นเดียวกัน: เนื้อหาที่ผ่านการแปลงเฟรมต้องมีการแบ่งช่วงเฟรมที่รอยตัดฉาก และต้องตรวจสอบคุณภาพ (QC) ภายหลัง ไม่เช่นนั้นโมเดลจะสร้างภาพเพี้ยนข้ามรอยต่อ คาดว่ารอบแรกจะต้องมีการแทนที่เฟรมด้วยมือบริเวณช่วงเปลี่ยนผ่านที่ยากลำบาก

จุดยืนของมันเมื่อเทียบกับทางเลือกอื่นๆ

การแทรกเฟรม (frame interpolation) ถือเป็นปัญหาที่แก้ได้แล้วในระดับหนึ่งมาสักระยะหนึ่ง โดยมีอยู่สองรูปแบบที่ต่างก็ดูแตกต่างไปจากอันนี้

• ชุดซอฟต์แวร์บนเดสก์ท็อป — โมเดล Apollo และ Chronos ของ Topaz Video AI ถือเป็นจุดอ้างอิงสำหรับการปรับความเร็วเฟรมที่เน้นคุณภาพเป็นหลัก ใบอนุญาตแบบถาวร ใช้ GPU ของคุณเอง ไม่มีระบบคิดเงินเป็นรายวินาที และมีขั้นตอนการปรับจูนที่ตอบแทนคนที่รู้ว่าตัวเองกำลังดูอะไรอยู่

• อินเทอร์โพเลเตอร์แบบโอเพนซอร์ส — RIFE และโมเดลที่คล้ายกัน โฮสต์เอง แทบไม่มีต้นทุนส่วนเพิ่มเลยเมื่อคุณมีฮาร์ดแวร์เป็นของตัวเอง และเป็นพื้นฐานของไปป์ไลน์แบบกำหนดเองส่วนใหญ่ที่บรรดาโพสต์เฮาส์สร้างขึ้นเอง

• Runway Enhance Frame Rate — ไม่ต้องประมวลผลในเครื่อง เป็นการเรียก API คิดค่าบริการต่อวินาทีของอินพุต และอัตรา NTSC แบบเศษส่วนที่อีกสองตัวนั้นในอดีตปล่อยให้คุณต้องปรับให้สอดคล้องด้วยมือเอง

ข้อแลกเปลี่ยนนี้เห็นได้ชัด สำหรับการถ่ายช็อตครั้งเดียวบนเวิร์กสเตชันที่คุณมีอยู่แล้ว อินเทอร์โพเลเตอร์ในเครื่องจะถูกกว่าและให้ตัวปรับที่ Runway ไม่เปิดให้เข้าถึง สำหรับฟุตเทจที่เข้ามาในไปป์ไลน์อัตโนมัติ หรือเมทริกซ์สิ่งส่งมอบที่คลิปเดียวกันต้องออกมาเป็น 23.98 สำหรับภูมิภาคหนึ่ง และ 25 สำหรับอีกภูมิภาคหนึ่ง API ที่คืนค่าเฟรมเรตแบบเศษส่วนโดยตรงจะตัดขั้นตอนคอนฟอร์มออกไป — และราคาต่อวินาทีของอินพุตหมายความว่าเอาต์พุตหลายอัตราเฟรมไม่มีค่าใช้จ่ายเพิ่มเติม

เลเยอร์การกำหนดเส้นทางที่อยู่รอบๆ มัน

การปรับไทม์มิ่งเป็นขั้นตอนหนึ่งในไปป์ไลน์ที่มีขั้นตอนโมเดลภาษาอยู่ใกล้ ๆ สักแห่ง รายการช็อตและบันทึกคอนฟอร์ม การทำซับไทเทิลและแคปชันที่ต้องปรับไทม์ใหม่ให้เข้ากับเฟรมเรตใหม่ เมทาดาทาการส่งมอบแยกตามพื้นที่ บันทึก QC — นั่นคืองานข้อความ และเป็นส่วนหนึ่งของไปป์ไลน์วิดีโอที่ไม่มีใครกันงบไว้

ชั้นนั้นทำงานบน คีย์เดียวครอบคลุม 200 โมเดลในแค็ตตาล็อกของ OrcaRouter, โดยมีราคาตามรายการของผู้ให้บริการที่ส่งผ่านโดยไม่มีกำไรเพิ่ม 0% และการสลับไปยังผู้ให้บริการรายอื่นโดยอัตโนมัติเมื่อเกิดข้อขัดข้อง ดังนั้นจึงสามารถลองโมเดลที่ใหม่กว่าหรือถูกกว่าได้กับทราฟฟิกจริง โดยไม่ต้องเดิมพันเส้นทางการผลิตกับมัน เพื่อความแม่นยำเกี่ยวกับขอบเขต: Runway Enhance Frame Rate เป็นโมเดล Runway Dev API ซึ่งเรียกใช้บนเอนด์พอยต์ของ Runway เอง และ OrcaRouter ไม่ได้ให้บริการมัน สิ่งที่เราครอบคลุมคือทุกอย่างที่อยู่รอบๆ มัน

อะไรที่ยังไม่เป็นที่รู้กัน

แทบไม่มีอะไรเกี่ยวกับคุณภาพเลย โมเดลนี้มีอายุประมาณหนึ่งวัน ณ เวลาที่เขียน และทุกอย่างข้างต้นเกี่ยวกับพฤติกรรมของมันมาจากบันทึกการเปลี่ยนแปลงและประกาศของ Runway เอง โดยเฉพาะอย่างยิ่ง สิ่งที่ยังไม่ได้รับการยืนยัน:

• พฤติกรรมอาร์ติแฟกต์ในภาพเคลื่อนไหวเร็ว การถูกบัง การเบลอจากการเคลื่อนไหว และแหล่งวิดีโอบิตเรตต่ำ — ยังไม่มีการทดสอบที่เผยแพร่โดยใครเลย

• ไม่ว่าจะตรวจจับจุดตัดฉากโดยอัตโนมัติ หรือเบลนด์ข้ามจุดตัดเหล่านั้น

• ออดิโอจะถูกส่งผ่าน ถูกรีแซมเปิล หรือถูกทิ้งหรือไม่ เมื่ออัตราเฟรมเปลี่ยน

• เมื่อเทียบคุณภาพกับ RIFE, Apollo หรือ Chronos แล้วเป็นอย่างไร — ยังไม่มีการเปรียบเทียบแบบตัวต่อตัว

• ราคาต่อวินาทีของอินพุตจะคงอยู่หรือไม่เมื่ออัตราเป้าหมายเพิ่มขึ้น หรือจะถูกจัด层级ใหม่ในภายหลัง

ให้ถือว่าเป้าหมาย 120 fps และ 48 fps เป็นเพียงคำกล่าวอ้างจนกว่าคุณจะได้ลองใช้กับฟุตเทจของคุณเอง และตรวจสอบการจัดการการตัดต่อในคลิปแรกที่คุณส่ง

ใครควรย้ายตอนนี้

ย้ายเลยตอนนี้ หากคุณส่งมอบงานตามสเปกสำหรับการออกอากาศหรือหลายดินแดน และปัจจุบันต้องจ่ายสำหรับขั้นตอนคอนฟอร์ม หากฟุตเทจของคุณไหลผ่านไปป์ไลน์อัตโนมัติอยู่แล้วซึ่งรองรับการเรียก API เพิ่มได้อีกหนึ่งครั้ง หรือหากคุณต้องการภาพสโลว์โมชันจากกล้องที่ไม่เคยถ่ายความเร็วสูง และคุณไม่อยากใช้ GPU

รอก่อนหากคุณต้องการเกินห้านาทีในงานเดียวและไม่สามารถแบ่งช่วงที่รอยตัดได้ หากคุณต้องการให้เพิ่มความละเอียดด้วย — นั่นคือตัวอัปสเกลอร์ ในราคาคิดตามเฟรม — หรือหากคุณมีตัวแทรกเฟรมบนเดสก์ท็อปอยู่แล้ว และนี่เป็นช็อตแบบครั้งเดียว และรอก่อนหากคุณภาพเป็นปัจจัยชี้ขาดมากกว่าความสะดวก: ยังไม่มีใครนอก Runway เผยแพร่ตัวเลข และการเปรียบเทียบอิสระครั้งแรกคือสิ่งที่คุ้มค่าจะรอ

รูปแบบที่ต้องจับตาคือ Runway จะขยาย endpoint นี้ไปทีละโมเดลหรือไม่ ตอนนี้มีทั้ง creative upscaler และตอนนี้ก็มี retimer โดยทั้งคู่อยู่บน POST /v1/video_upscale และทั้งคู่คิดราคาด้วยหน่วยที่ต่างกันโดยสิ้นเชิง สำหรับใครก็ตามที่สร้าง delivery pipeline หน่วย—วินาทีของอินพุตแทนที่จะเป็นเฟรมเอาต์พุต—คือส่วนที่ควรค่าแก่การออกแบบให้สอดรับ