הלוגו של ערוץ FAST — הסימן הקטן בפינה — הוא הקבוע הוויזואלי היחיד בכל תוכנית, בכל הפסקת פרסומות, בכל לוח שמשדר הערוץ. הוא חייב להיראות מקצועי בכל רמת איכות שהצופה עשוי לקבל. הגישה הנאיבית — להעלות תמונה ראשית אחת ולתת ל-AWS MediaLive להקטין אותה לפי כל גרסה — מייצרת לוגו חד ב-1080p ולוגו רך ב-360p. זו בעיה למותג עבור כל צופה שאינו מחובר לאינטרנט מהיר. הנה איך התאמנו את גודל הלוגו לרשת הפיקסלים המדויקת של כל גרסה.
סקירה מהירה
| אספקט | פרטים |
|---|---|
| תחום | הטמעת לוגו ערוץ (DOG) בערוצי FAST |
| מנגנון | StaticImageOutputActivate לכל גרסה (1080p, 720p, 480p, 360p) |
| יצירת נכסים | סקריפט Python באמצעות דגימת Lanczos |
| תזמון הפעלה | 1.5 שניות לאחר כל מעבר קלט של התוכנית |
| סטטוס | 1× סטאק לכל גרסה בייצור |
הבעיה העסקית
ערוץ FAST אינו מספק רמת איכות אחת. MediaLive מקודד את אותו ערוץ לכמה גרסאות — 1080p, 720p, 480p, 360p — וכל נגן של צופה בוחר את הטובה ביותר שהחיבור שלהם יכול לתמוך בה. צופים בניידים על נתונים סלולריים צופים ב-360p; צופים בטלוויזיות חכמות על אינטרנט מהיר מקבלים 1080p. כולם מסתכלים על אותו סימן מותג, וכולם מצפים שהוא ייראה מקצועי. כאשר הלוגו חד ב-1080p ורך ב-360p, המותג אינו עקבי — לא פרט שולי בערוץ 24/7 שבו הלוגו הוא האלמנט היחיד שהצופים רואים יותר מכל תוכנית בודדת.
היכן ההטבעות למעשה מוחלות
בצינור מקודד רב-גרסתי, ניתן להחיל הטבעה בשני מקומות:
לפני המקטין לכל גרסה, שבו תמונה ראשית אחת משולבת על המקור והכל מוקטן לכל פלט — זה מה ש-MediaLive עושה עם פעולה גלובלית של StaticImageActivate
אחרי המקטין, שבו כל פלט מקבל את ההטבעה שלו לאחר שהקנבס כבר בגודל הסופי. ההבדל נראה קטן ב-API. ויזואלית, הוא לא. כל דבר שמשולב לפני המקטין יורש כל ארטיפקט שהמקטין מציג, וב-360p, המקטין אגרסיבי.
מדוע התיקונים הברורים נכשלים
"העלה אחד ראשי ותן ל-MediaLive להקטין אותו." הפעולה הגלובלית משלבת את הראשי לפני שהמקטין לכל פלט פועל. ראשי גדול מוקטן ללוגו בגודל 64×21px עבור 360p הוא הפחתה של בערך פי 40 — אפילו דגימת Lanczos מאבדת פרטים עדינים ביחס הזה, והתוצאה עוברת אז דרך אותה שרשרת דחיסה כמו הווידאו עצמו.
"השתמש בראשי גדול יותר." זה הופך את יחס ההקטנה לגדול יותר, לא קטן יותר — הארטיפקט מחמיר, לא משתפר.
"דלג על הלוגו בפלטים SD." דרישות תאימות ומותג דורשות את הסימן בכל גרסה. לא אפשרות.
"שרוף את הלוגו לתוך הווידאו המקורי בזמן הקידוד." מאבד כל מנוף תפעולי — אין שינויים בלוגו לפי קמפיין או אזור, ואין עדכון ללא קידוד מחדש של כל הספרייה.
"השתמש בהטבעה גלובלית עם קואורדינטות ידניות לכל רזולוציה." הפעולה הגלובלית מחשבת מיקום מול רפרנס קבוע של 1920×1080, כך שסרטונים מקוריים צרים יותר מזה מייצרים קואורדינטות מחוץ לקנבס — הלוגו נסחף מהפינה או נחתך.
המנוף האמיתי היה לעקוף את ההקטנה של ההטבעה של MediaLive לחלוטין: להתאים את גודל הלוגו לקנבס של כל גרסה בעצמנו, לפני שהמקודד נוגע בו.
הפתרון
הלוגו של כל גרסה מיוצר מראש למידות הפיקסלים המדויקות שלו ונשמר כ-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, שנבחרה להתנהגות צפויה וחוזרת על עצמה בגדלים קטנים ולא כדי לזכות בתחרות איכות פיקסלים. כל לוגו מגיע לכ-10% מרוחב הקנבס שלו — נראה מבלי להיות פולשני — והוספת גרסה חדשה היא כניסה בודדת למערך ו-PNG חדש אחד.
החלטות מפתח שכדאי לציין
עיכוב הפעלה של 1.5 שניות. פעולות סימון מים מופעלות 1.5 שניות לאחר כל מעבר קלט, לא ברגע המעבר המדויק — הפעלה מיידית יכולה להבהב מול פריימים שעדיין לא יציבים. הערך כוונן אמפירית ומרוכז כקבוע יחיד כך שכיוונון עתידי הוא שינוי שורה אחת.
יצירת נכסים לא מקוונת, מופעלת על ידי אדם — בכוונה. צינור ההקטנה של Lanczos אינו אוטומטי כשלב בנייה או טרנספורמציה בצד CDN. נכסי הלוגו משתנים לעיתים רחוקות מספיק כך שיצירה מחדש של פקודה אחת היא כמות האוטומציה הנכונה; העלות של בניית אוטומציה נוספת עולה על הפעלת סקריפט פעמיים בשנה.
קיים וריאנט "עבה" אך אינו נשלח. הגנרטור גם מייצר וריאנט אלפא מורחב עם קווים עבים יותר, שנועד לשרוד כימות H.264 בקצבי סיביות נמוכים של SD. הוא לא בייצור — הווריאנט הסטנדרטי מספיק לטווח קצבי הסיביות הנוכחי, ואין מדידה שעדיין מצדיקה מעבר. הוא קיים כגיבוי שנבדק בקוד: זול לשמור זמין, מוקדם מדי לשלוח.
מה אנחנו עדיין עוקבים
שום צינור וידאו בייצור אינו באמת גמור, ועדיין יש הזדמנויות לשפר את הגישה הזו לאורך זמן.
היישום הנוכחי מבטיח שכל גרסה תקבל לוגו שהוכן במיוחד עבור רזולוציית הפלט שלה, ומבטל את ההקטנה של ההטבעה בזמן ריצה מצינור MediaLive. המראה הסופי, עם זאת, עדיין מוגבל באופן טבעי על ידי רזולוציית כל גרסה ודחיסת הווידאו, במיוחד בקצבי סיביות נמוכים. ככל שפרופילי הסטרימינג מתפתחים, נמשיך להעריך האם טיפולי לוגו שונים מספקים יתרונות ויזואליים מדידים בתנאים אלה.
מחולל הנכסים כבר תומך גם בגרסה הסטנדרטית וגם בגרסת לוגו עבה יותר. אם בדיקות עתידיות יראו שהגרסה העבה יותר מתפקדת טוב יותר עבור גרסאות בקצב סיביות נמוך, נעשה את בחירת הווריאנט של הלוגו מונעת על ידי תצורה כך שניתן יהיה לשנות אותה ללא פריסה מחדש של היישום.
תוצאות
כל גרסה כעת מקבלת לוגו שהותאם במיוחד לקנבס שלה, כאשר MediaLive אינו מבצע שום הקטנה של ההטבעה בזמן ריצה. כל פלט משתמש ביצירות אמנות שהוכנו עבור רזולוציית היעד שלו, ומונע את הריכוך הנוסף שמוצג על ידי הקטנה בזמן ריצה של ההטבעה תוך שמירה על איכות ויזואלית מעשית הטובה ביותר שהגרסה יכולה לספק.
הבאג של הסטת קואורדינטות מהגישה הגלובלית הקודמת, שבו לוגואים יכלו לזוז על סרטונים מקוריים צרים מ-1920px, מבוטל מבנית מכיוון שההפעלה לכל פלט פועלת לחלוטין בקואורדינטות פלט.
החלפת הלוגו כעת היא משימה תפעולית פשוטה: יצירה מחדש של הנכסים הספציפיים לגרסה עם סקריפט אחד והעלאתם. אין צורך בקידוד וידאו מחדש ואין עריכה ידנית לכל גרסה.
יישום זה עוקב אחר עקרון הנדסי פשוט: לפתור בעיות מוקדם ככל האפשר בצינור, ולעצב סביב יכולות הפלטפורמה במקום להסתמך על פתרונות עוקפים במורד הזרם. על ידי הכנת הנכס הנכון לפני הקידוד, הצינור החי נשאר פשוט יותר, צפוי יותר וקל יותר לתחזוקה.
אם אתם נתקלים בבעיות איכות גרסה או הטבעה דומות בצינור וידאו חי, צרו קשר.
טכנולוגיה: AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)
