העלאה אחת, שישה תוצרים
קטע וידאו מקורי יחיד כיום חייב להפוך ל-Reel אנכי ביחס 9:16, חיתוך מרובע ביחס 1:1, גרסת רוחב (לנדסקייפ) ביחס 16:9, וריאנט מושתק עם כתוביות להפעלה אוטומטית (autoplay), גזרה ממותגת עם לוגו ו-intro/outro, וגרסה דחוסה שנטענת מיידית בחיבור חלש. אותו תוכן, שישה או יותר פורמטים – מוכפלים על פני כל קמפיין וכל יוצר, מדי יום.
פתרון בעיה זו בקנה מידה רחב משמעו שהווידאו חייב להיות מעובד באופן תוכנתי, ולא נערך ידנית. זו העבודה ש-FFmpeg מבצע בצינור העבודה (pipeline) שלנו.
מדוע FFmpeg, באופן ספציפי
FFmpeg הוא כלי שורת פקודה (command-line) חינמי ופתוח (open-source) להמרת, סינון וקידוד אודיו ווידאו. אין לו ממשק משתמש (UI) – אתה מתאר בדיוק מה אתה רוצה כפקודה, והוא מבצע זאת. זוהי כל הצעת הערך (value proposition): ניתן לייצר פקודה באמצעות קוד, להגדיר לה פרמטרים לכל משתמש, להכניס אותה לתור ב-pipeline, ולהריץ אותה על שרת ללא מעורבות אנושית כלל. עריכת וידאו הופכת למשהו שאתה מתכנת במקום משהו שאתה מקליק עליו.
שלוש תכונות הופכות אותו להתאמה מושלמת לבעיה ספציפית זו, ולא רק ל"כלי וידאו שעובד":
מסננים הניתנים לחיבור (Composable filters). ה-filtergraph של FFmpeg מאפשר לך לשרשר (chain) פעולות כמו scale ← crop ← overlay ← fade למעבר יחיד. זה חשוב מכיוון שזה מונע כתיבת קבצי ביניים בכל שלב – pipeline נאיבי שמקודד מחדש (re-encodes) בין כל פעולה מכפיל הן את זמן הרינדור (render time) והן את תנודתיות האחסון (storage churn). שרשור שומר על טרנספורמציה רב-שלבית לקידוד אחד.
פעולות ברמת הזרם (stream-level), לא רק קידוד מחדש (re-encodes). עבור פעולות כמו חיתוך (trimming), FFmpeg יכול להעתיק זרמים קיימים במקום לפענח ולקודד אותם מחדש:
ffmpeg -i input.mp4 -ss 00:00:08 -t 15 -c copy highlight.mp4
-c copy הוא ההבדל בין חיתוך (trim) שמסתיים תוך שניות לבין כזה שלוקח זמן רב כמו קידוד מחדש מלא (full re-encode). אנו משתמשים בו בכל מקום שבו הפעולה אינה דורשת נגיעה בנתוני פיקסלים – חיתוכים (trims), remuxing של פורמטים – ושומרים קידוד מחדש מלא (full re-encoding) עבור שלבים שבאמת זקוקים לכך, כמו שינוי קנה מידה (scaling) או שכבת-על (overlaying).
קידוד מודע לחומרה (Hardware-aware encoding). FFmpeg יכול לנתב דרך מקודדי GPU (NVENC, QSV, VideoToolbox) במקום libx264 מבוסס CPU בלבד. קידוד GPU מנצח בתפוקה גולמית (raw throughput) בנפחים גבוהים; libx264 עדיין נותן איכות צפויה יותר וניתנת לכוונון (tunable) ב-bitrate נתון. איזה מהם ללכת עליו הוא פשרה אמיתית (trade-off), לא ברירת מחדל מוגדרת מראש – אנו נוטים לקידוד CPU עבור כל דבר הפונה למותג שבו בקרת איכות היא החשובה ביותר, ושומרים נתיבי GPU עבור קבוצות (batches) בנפח גבוה ובעדיפות נמוכה יותר.
כיצד ה-Pipeline משתמש בו בפועל
עיבוד מחדש של מסגרת (Reframing).
הבקשה הנפוצה ביותר היא "הפוך את זה שיתאים לכל מקום." מקור אופקי הופך ל-Reel אנכי באמצעות scale-and-crop. חיתוך ישר (straight cropping) מהיר אך זורק חלק מהמסגרת – מצוין עבור נושאים ממורכזים, גרוע כשהנושא זז מחוץ למרכז. במקרים אלה, אנו חוזרים לרקע מטושטש במסגרת מלאה (full-frame background) מאחורי עותק קדמי בגודל הנכון (correctly-scaled foreground copy), כך ששום דבר לא נחתך:
ffmpeg -i input.mp4 -filter_complex \
"[0:v]scale=1080:1920,boxblur=20:5[bg]; \
[0:v]scale=1080:-2[fg]; \
[bg][fg]overlay=(W-w)/2:(H-h)/2" \
-c:a copy output_blurred.mp4
זוהי החלטה מכוונת בעלת שני נתיבים, לא פילטר ברירת מחדל יחיד – חתוך (crop) כשזה בטוח, השתמש בגיבוי טשטוש (blur-fallback) כשזה לא.
מיתוג, כתוביות, אודיו. לוגואים, intros ו-outros מיושמים כשכבות-על (overlays) ושרשורים (concatenations) עם פרמטרים, כך שמיקום, גודל ושקיפות משתנים לפי המותג מבלי לגעת בקוד ה-pipeline. כתוביות נצרבות ישירות לתוך הפריימים במקום להישלח כרצועת כתוביות נפרדת – פידים מושתקים עם autoplay פירושם שהכתובית צריכה לשרוד כל קידוד מחדש (re-encoding) שהפלטפורמה היעד מיישמת, וכתובית צרובה תמיד שורדת; רצועת כתוביות לפעמים לא. האודיו מעורבב ומנורמל עוצמה (loudness-normalized) כך שאף קטע לא יהיה רועש באופן צורם מהקודם לו בפיד גלילה (scroll feed).
אספקה. כל פלט מקודד עם +faststart, שמזיז את מטא-נתוני הקובץ להתחלה כדי שההשמעה תוכל להתחיל לפני שהקובץ כולו יורד – דגל קטן עם השפעה גדולה על זמן הטעינה הנתפס (perceived load time) במיוחד עבור וידאו קצר.
הפשרה שאנחנו עדיין מתמודדים איתה
לא כל החלטה כאן סגורה (מוסכמת). קידוד GPU לעומת CPU הוא זה שאנו בוחנים מחדש הכי הרבה: תפוקת GPU אטרקטיבית ככל שהנפח גדל, אבל עקביות איכות-לפי-bitrate עדיין מעדיפה קידוד CPU עבור פלט קריטי למותג. כרגע ההפרדה הזו מטופלת ידנית לכל סוג משימה (job type); הפיכתה להחלטת ניתוב אוטומטית ומודעת איכות היא החלק הבא של ה-pipeline שאנו בונים.
מדוע זה חשוב
בסך הכל, העלאה אחת מפעילה pipeline שמעבד מחדש את המסגרת לגרסאות אנכיות, מרובעות ולנדסקייפ, ממתג אותו, צורב כתוביות, חותך לגזרה החזקה ביותר, מערבב ומנרמל אודיו, ודוחס לאספקה מהירה – ללא עורך שפותח ציר זמן (timeline). הרחבת קנה המידה (scaling) פירושה פשוט הרצת יותר עובדי FFmpeg במקביל, שכן כל משימה היא עצמאית וחסרת מצב (stateless).
טרנד ה-Reels לא רק שינה את איך שתוכן נראה – הוא שינה כמה פורמטים (shapes) קטע תוכן יחיד צריך לקבל, בציר זמן (timeline) שעריכה ידנית לא יכולה לעמוד בו. FFmpeg עומד בקצב כי הוא מתייחס לווידאו כניתן לתכנות (programmable) וניתן לחיבור (composable) במקום כמשהו שצריך להקליק עליו ידנית. זו הסיבה האמיתית לכך שה-pipeline הזה ניתן להרחבה (scales): לא ש-FFmpeg חזק באופן מופשט, אלא שכל החלטה בו – חיתוך (crop) לעומת גיבוי טשטוש (blur-fallback), העתקת זרם (stream-copy) לעומת קידוד מחדש (re-encode), GPU לעומת CPU – נעשית בכוונה, לכל מקרה לגופו, במקום להיקבע כברירת מחדל.
אם אתם בונים pipeline כזה ורוצים חוות דעת נוספת על הארכיטקטורה, צרו קשר.
