Логотип FAST каналу — це маленька мітка в кутку, яка є єдиною візуальною постійною на всіх програмах, рекламних паузах, заставках, які транслює канал. Він повинен виглядати професійно на кожному рівні якості, який може отримати глядач. Наївний підхід — завантажити одне основне зображення і дозволити AWS MediaLive масштабувати його для кожного варіанту — дає чіткий логотип на 1080p і помітно розмитий на 360p. Це проблема для бренду для кожного глядача, який не користується широкосмуговим інтернетом. Ось як ми підібрали розмір логотипу до точної піксельної сітки кожного варіанту.
Швидкий огляд
| Аспект | Деталі |
|---|---|
| Домен | Накладання логотипу каналу (DOG) на FAST канали |
| Механізм | Пер-варіант StaticImageOutputActivate для кожного варіанту (1080p, 720p, 480p, 360p) |
| Генерація активів | Скрипт на Python з використанням ресемплінгу Ланцоша |
| Час активації | 1,5 секунди після перемикання вхідного сигналу кожної програми |
| Статус | 1× стек на кожен варіант у виробництві |
Бізнес-проблема
FAST канал не надає один рівень якості. MediaLive кодує той самий канал у кілька варіантів — 1080p, 720p, 480p, 360p — і плеєр кожного глядача вибирає найкращий, який може підтримувати їх з'єднання. Мобільні глядачі на стільникових даних дивляться 360p; глядачі на смарт-ТВ з широкосмуговим інтернетом отримують 1080p. Вони всі дивляться на той самий бренд, і всі очікують, що він виглядатиме професійно. Коли логотип чіткий на 1080p і помітно розмитий на 360p, бренд є непослідовним — це не дрібниця на каналі 24/7, де логотип є єдиним елементом, який глядачі бачать більше, ніж будь-яку окрему програму.
Де насправді застосовуються накладання
У конвеєрі енкодера з кількома варіантами накладання можна застосувати в двох місцях:
Перед масштабатором для кожного варіанту, де одне основне зображення компонується на джерело, і все це масштабується вниз для кожного виходу — це те, що MediaLive робить з глобальною дією StaticImageActivate
після масштабатора, де кожен вихід отримує своє накладання, коли полотно вже на кінцевому розмірі. Різниця виглядає незначною в API. Візуально це не так. Все, що компонується перед масштабатором, успадковує кожен артефакт, який вводить масштабатор, а на 360p масштабатор агресивний.
Чому очевидні виправлення не працюють
"Завантажте один майстер і дозвольте MediaLive масштабувати його." Глобальна дія компонує майстер перед тим, як запускається масштабатор для кожного виходу. Великий майстер, зменшений до логотипу розміром 64×21 піксель для 360p, є приблизно 40-кратним зменшенням — навіть ресемплінг Ланцоша втрачає дрібні деталі при такому співвідношенні, і результат потім проходить через той самий ланцюг стиснення, що й саме відео.
"Використовуйте більший майстер." Це робить співвідношення зменшення більшим, а не меншим — артефакт стає гіршим, а не кращим.
"Пропустіть логотип на SD виходах." Вимоги до відповідності та бренду потребують мітки на кожному варіанті. Це не варіант.
"Запишіть логотип у вихідне відео під час кодування." Втрачаються всі операційні важелі — жодних змін логотипу для кожної кампанії або регіону, і жодного оновлення без перекодування всієї бібліотеки.
"Використовуйте глобальне накладання з ручними координатами для кожної роздільної здатності." Глобальна дія обчислює позицію відносно фіксованого еталону 1920×1080, тому вихідні відео вужчі за це дають координати поза полотном — логотип зміщується з кута або обрізається.
Справжнім важелем було повне обходження масштабування накладання MediaLive: підібрати розмір логотипу до полотна кожного варіанту самостійно, перш ніж енкодер взагалі торкнеться його.
Рішення
Логотип кожного варіанту попередньо рендериться до його точних піксельних розмірів і зберігається як окремий PNG. На кожному межі програми оркестратор Lambda випускає чотири дії StaticImageOutputActivate — по одній для кожного варіанту — кожна вказує на PNG, вже підібраний для цього конкретного виходу. MediaLive не виконує жодного масштабування накладання.
GLOBAL (наївний) PER-OUTPUT (що ми постачаємо)
master.png ──► composite onto master.png ──► Lanczos resize (офлайн)
source canvas у 4 PNG точного розміру
│ │
▼ ▼
пер-варіантний масштабатор пер-варіантний масштабатор
(також масштабує накладання → (накладання не торкається —
розмитий логотип на SD виходах) компонується після, на
точному піксельному розмірі)Скрипт на Python генерує чотири розмірені PNG з одного майстра, використовуючи ресемплінг Ланцоша, обраний для передбачуваної, повторюваної поведінки на малих розмірах, а не для перемоги в конкурсі якості пікселів. Кожен логотип займає приблизно 10% ширини свого полотна — видимий, але не нав'язливий — і додавання нового варіанту є одним записом у масиві плюс один новий PNG.
Ключові рішення, які варто назвати
Затримка активації 1,5 секунди. Дії з водяними знаками запускаються через 1,5 секунди після кожного перемикання вхідного сигналу, а не в момент перемикання — активація відразу може мерехтіти проти ще нестабільних кадрів. Значення було емпірично налаштоване і централізоване як одна константа, тому майбутнє налаштування — це зміна в один рядок.
Офлайн, вручну ініційована генерація активів — навмисно. Пайплайн ресемплінгу Ланцоша не автоматизований як етап збірки або трансформація на стороні CDN. Логотипи змінюються досить рідко, щоб однокомандна регенерація була правильним рівнем автоматизації; вартість подальшої автоматизації перевищує запуск скрипту двічі на рік.
Існує "товстий" варіант, але не постачається. Генератор також створює варіант з розширеним альфа-каналом з товстішими штрихами, призначений для виживання при квантизації H.264 на низьких SD бітрейтах. Він не використовується у виробництві — стандартний варіант достатній для поточного діапазону бітрейтів, і жодне вимірювання ще не виправдовує перемикання. Він існує як код-тестований резерв: дешево тримати доступним, передчасно постачати.
Що ми ще спостерігаємо
Жоден виробничий відео конвеєр ніколи не є по-справжньому завершеним, і ще є можливості вдосконалити цей підхід з часом.
Поточна реалізація забезпечує, що кожен варіант отримує логотип, підготовлений спеціально для свого вихідного роздільного здатності, усуваючи масштабування накладання в реальному часі з конвеєра MediaLive. Однак кінцевий вигляд все ще природно обмежений роздільною здатністю кожного варіанту та відео стисненням, особливо при низьких бітрейтах. У міру розвитку потокових профілів ми продовжимо оцінювати, чи різні обробки логотипу надають вимірювані візуальні переваги за цих умов.
Генератор активів вже підтримує як стандартний, так і товстіший варіант логотипу. Якщо майбутні тести покажуть, що товстіший варіант працює краще для варіантів з нижчим бітрейтом, ми зробимо вибір варіанта логотипу конфігурованим, щоб його можна було змінити без повторного розгортання програми.
Результати
Кожен варіант тепер отримує логотип, розмірений спеціально для свого полотна, з MediaLive, що не виконує жодного масштабування накладання в реальному часі. Кожен вихід використовує графіку, підготовлену для своєї цільової роздільної здатності, уникаючи додаткового розмивання, яке вводить масштабування накладання в реальному часі, зберігаючи при цьому найкращу практичну візуальну якість, яку може забезпечити цей варіант.
Помилка зсуву координат з попереднього підходу з глобальним накладанням, де логотипи могли зміщуватися на вихідних відео вужчих за 1920px, структурно усунена, оскільки активація для кожного виходу працює повністю в координатах виходу.
Заміну логотипу тепер є простим операційним завданням: регенеруйте активи, специфічні для варіанту, за допомогою одного скрипту і завантажте їх. Ніякого перекодування відео і ніякого ручного редагування для кожного варіанту не потрібно.
Ця реалізація слідує простому інженерному принципу: вирішуйте проблеми якомога раніше в конвеєрі і проектуйте навколо можливостей платформи замість того, щоб покладатися на обхідні рішення вниз за течією. Підготувавши правильний актив перед кодуванням, живий конвеєр залишається простішим, передбачуванішим і легшим для обслуговування.
Якщо ви стикаєтеся з подібними проблемами з варіантами або якістю накладання на живому відео конвеєрі, зв'яжіться з нами.
Технологічний стек: AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)
