אופטימיזציה של לוגו ערוץ עבור רזולוציות וידאו שונות

הלוגו של ערוץ FAST — הסימן הקטן בפינה — הוא הקבוע הוויזואלי היחיד בכל תוכנית, בכל הפסקת פרסומות, בכל לוח שידור של הערוץ. הוא חייב להיראות מקצועי בכל רמת איכות שהצופה עשוי לקבל. הגישה התמימה — העלאת תמונת מאסטר אחת ומתן האפשרות ל- AWS MediaLive לשנות את קנה המידה שלה עבור כל גרסה (rendition) — מייצרת לוגו חד ב-1080p ולוגו רך באופן גלוי ב-360p. זוהי בעיית מותג עבור כל צופה שאינו מחובר לחיבור פס רחב (broadband). כך שינינו את גודל הלוגו לרשת הפיקסלים המדויקת של כל גרסה במקום זאת.

סקירה מהירה

הבעיה העסקית

ערוץ FAST אינו מספק רמת איכות אחת. MediaLive מקודד את אותו ערוץ למספר גרסאות (renditions) — 1080p, 720p, 480p, 360p — ונגן של כל צופה בוחר את הטובה ביותר שהחיבור שלו יכול לתמוך בה. צופים ניידים על נתוני סלולר צופים ב-360p; צופי טלוויזיות חכמות בפס רחב מקבלים 1080p. כולם מסתכלים על אותו סימן מותג, וכולם מצפים שהוא ייראה מקצועי. כאשר הלוגו חד ב-1080p ורך באופן גלוי ב-360p, המותג לא עקבי — וזה לא פרט קטן בערוץ 24/7 שבו הלוגו הוא האלמנט היחיד שצופים רואים יותר מכל תוכנית בודדת.

היכן שכבות-על מיושמות בפועל

בצינור קידוד מרובה גרסאות (rendition), ניתן ליישם שכבת-על בשני מקומות: 

לפני מנגנון שינוי קנה המידה לכל גרסה (scaler), כאשר תמונת מאסטר אחת משולבת על המקור וכל העניין מוקטן לכל פלט — זה מה ש-MediaLive עושה עם פעולת StaticImageActivate גלובלית

 אחרי מנגנון שינוי קנה המידה, כאשר כל פלט מקבל שכבת-על משלו ברגע שהקנבס כבר בגודלו הסופי. ההבדל נראה קטן ב-API. ויזואלית, זה לא כך. כל דבר שמשולב לפני מנגנון שינוי קנה המידה יורש כל ארטיפקט שהמנגנון מציג, וב-360p, המנגנון אגרסיבי.

מדוע הפתרונות המובנים מאליהם נכשלים

"העלה מאסטר אחד ותן ל-MediaLive לשנות את קנה המידה." הפעולה הגלובלית משלבת את המאסטר לפני שמנגנון שינוי קנה המידה לכל פלט פועל. מאסטר גדול המוקטן ללוגו בגודל 64x21 פיקסלים עבור 360p הוא הפחתה של בערך פי 40 — אפילו Lanczos resampling מאבד פרטים עדינים ביחס כזה, והתוצאה עוברת אז דרך אותה שרשרת דחיסה כמו הווידאו עצמו.

"השתמש במאסטר גדול יותר." זה הופך את יחס ההקטנה לגדול יותר, לא קטן יותר — הארטיפקט מחמיר, לא משתפר.

"דלג על הלוגו בפלטי SD." דרישות תאימות ומותג דורשות את הסימן על כל גרסה (rendition). לא אופציה.

"צרב את הלוגו לווידאו המקור בזמן הקידוד." מאבד כל מנוף תפעולי — אין שינויי לוגו לכל קמפיין או לכל אזור, ואין עדכון ללא קידוד מחדש של כל הספרייה.

"השתמש בשכבת-על גלובלית עם קואורדינטות ידניות לכל רזולוציה." הפעולה הגלובלית מחשבת מיקום מול הפניה קבועה של 1920x1080, כך שסרטוני מקור צרים יותר מכך מייצרים קואורדינטות מחוץ לקנבס — הלוגו נסחף מהפינה או נחתך.

המנוף האמיתי היה עקיפת שינוי קנה המידה של שכבת-העל ב-MediaLive לחלוטין: שינוי גודל הלוגו לקנבס של כל גרסה בעצמנו, לפני שהמקודד נוגע בו בכלל.

הפתרון

הלוגו של כל גרסה (rendition) מעובד מראש למידות הפיקסלים המדויקות שלו ונשמר כקובץ PNG נפרד. בכל גבול תוכנית, מתזמן Lambda מפעיל ארבע פעולות StaticImageOutputActivate — אחת לכל גרסה — כל אחת מצביעה על ה-PNG שכבר בגודל המתאים לפלט הספציפי הזה. MediaLive מבצעת אפס שינוי קנה מידה על שכבת-העל.

GLOBAL (naive)                    PER-OUTPUT (what we ship)
master.png ──► composite onto     master.png ──► Lanczos resize (offline)
               source canvas                     into 4 exact-size PNGs
                    │                                  │
                    ▼                                  ▼
           per-rendition scaler              per-rendition scaler
           (also scales the                  (overlay isn't touched —
            overlay → soft logo               composited after, at
            on SD outputs)                    exact pixel size)

סקריפט Python מייצר את ארבעת קובצי ה-PNG בגודלם המתאים ממאסטר יחיד באמצעות Lanczos resampling, שנבחר בשל התנהגותו הצפויה והניתנת לשחזור בגדלים קטנים, ולא במטרה לזכות בתחרות איכות פיקסלים. כל לוגו נוחת בערך ב-10% מרוחב הקנבס שלו — נראה לעין מבלי להיות פולשני — והוספת גרסה חדשה היא כניסה אחת למערך בתוספת PNG חדש אחד.

החלטות מפתח שראויות לציון

עיכוב הפעלה של 1.5 שניות. פעולות הפעלת סימן מים נורות 1.5 שניות לאחר כל החלפת קלט, לא ברגע ההחלפה המדויק — הפעלה מיידית עלולה לגרום לריצוד מול פריימים שעדיין אינם יציבים. הערך כוונן אמפירית ורוכז כקבוע יחיד כך שכוונון עתידי יהיה שינוי של שורה אחת.

יצירת נכסים לא מקוונת, בהפעלה אנושית — בכוונה. צינור שינוי הגודל של Lanczos אינו ממוכן כשלב בנייה או טרנספורמציה בצד ה-CDN. נכסי לוגו משתנים לעיתים רחוקות מספיק כך ששחזור בפקודה אחת הוא מידת האוטומציה הנכונה; עלות בניית אוטומציה נוספת עולה על הפעלת סקריפט פעמיים בשנה.

גרסה "עבה" קיימת אך אינה נשלחת. הגנרטור מייצר גם גרסת dilated-alpha עם קווים עבים יותר, המיועדת לשרוד קיטון H.264 בביטרייטים נמוכים של SD. היא אינה בייצור — הגרסה הסטנדרטית מספיקה עבור טווח הביטרייטים הנוכחי, ושום מדידה עדיין לא מצדיקה מעבר. היא קיימת כהיערכות שנבדקה בקוד: זולה לשמירה זמינה, מוקדמת מדי לשליחה.

מה אנחנו עדיין עוקבים אחריו

שום צינור וידאו ייצור אינו באמת גמור, ועדיין קיימות הזדמנויות לשכלל גישה זו לאורך זמן.
היישום הנוכחי מבטיח שכל גרסה (rendition) תקבל לוגו שהוכן במיוחד עבור רזולוציית הפלט שלה, ובכך מבטל שינוי קנה מידה של שכבת-על בזמן ריצה מצינור MediaLive. עם זאת, המראה הסופי עדיין מוגבל באופן טבעי על ידי רזולוציית כל גרסה ודחיסת הווידאו, במיוחד בביטרייטים נמוכים יותר. ככל שפרופילי הזרמה יתפתחו, נמשיך להעריך אם טיפולים שונים בלוגו מספקים יתרונות ויזואליים מדידים בתנאים אלו.
מייצר הנכסים כבר תומך הן בגרסה הסטנדרטית והן בגרסת לוגו עבה יותר. אם בדיקות עתידיות יראו שהגרסה העבה יותר מתפקדת טוב יותר עבור גרסאות בביטרייטים נמוכים יותר, נהפוך את בחירת גרסת הלוגו למונעת תצורה כך שניתן יהיה לשנותה ללא פריסה מחדש של היישום.

תוצאות

כעת, כל גרסה (rendition) מקבלת לוגו בגודל ספציפי לקנבס שלה, כאשר MediaLive מבצעת אפס שינוי קנה מידה של שכבת-על בזמן ריצה. כל פלט משתמש ביצירת אמנות שהוכנה לרזולוציית היעד שלו, ובכך נמנעת הריכוך הנוסף שהוצג על ידי שינוי קנה מידה של שכבת-על בזמן ריצה, תוך שמירה על האיכות הוויזואלית המעשית הטובה ביותר שגרסה זו יכולה לספק.
באג סטיית הקואורדינטות מגישת שכבת-העל הגלובלית הקודמת, שבה לוגואים יכלו לזוז בסרטוני מקור צרים מ-1920 פיקסלים, סולק באופן מבני מכיוון שהפעלת לכל פלט פועלת לחלוטין בקואורדינטות הפלט.
החלפת הלוגו היא כעת משימה תפעולית פשוטה: צור מחדש את הנכסים הספציפיים לגרסה באמצעות סקריפט בודד והעלה אותם. אין צורך בקידוד וידאו מחדש ובשום עריכה ידנית לכל גרסה.
יישום זה עוקב אחר עקרון הנדסי פשוט: פתור בעיות בשלב מוקדם ככל האפשר בצינור, ותכנן סביב יכולות הפלטפורמה במקום להסתמך על פתרונות עוקפים בהמשך הדרך. על ידי הכנת הנכס הנכון לפני הקידוד, צינור הזרמה החיה נשאר פשוט יותר, צפוי יותר, וקל יותר לתחזוקה.
אם אתה נתקל בבעיות איכות דומות של גרסאות או שכבות-על בצינור וידאו חי, צור קשר.

Technology Stack: AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)