FAST-канали заробляють на рекламних паузах. Вся бізнес-модель базується на одному припущенні: коли канал говорить "переключитися на рекламу", кожна підключена система — рекламний сервер, SSAI-сплайсер, плеєр смарт-ТБ — чує це в один і той же момент, з точно такою ж тривалістю. SCTE-35 — це стандартний протокол, який передає це повідомлення. Якщо це зробити неправильно мовчки — а мовчання є типовим режимом відмови — то реклама або не відображається, або запускається в неправильному кадрі, або має неправильну тривалість. Глядач бачить заставку. Доходу просто немає.
Це інженерна історія про те, як FAST-канали mStudio видають сигнали SCTE-35, що відповідають стандартам, з інтуїтивно зрозумілих для оператора входів, і чому ми побудували це як три сигнали на паузу замість одного.
Короткий огляд
| Аспект | Деталі |
|---|---|
| Домен | Сигналізація рекламних пауз SCTE-35 для FAST-каналів AWS MediaLive |
| Робочий процес оператора | Редактор рекламних пауз для кожної програми — позиція в секундах, тривалість у секундах |
| Сигнали, що надсилаються за паузу | Три — початок реклами TimeSignal, SpliceInsert, кінець реклами TimeSignal |
| Обмеження тривалості | 10–120 секунд, перевіряється на рівні даних |
| Нижчі споживачі | Наприклад: плеєри, рекламні сервери та AWS MediaTailor (розроблено, але ще не підключено). |
| Статус | Надсилання сигналів SCTE-35 у продакшені; інтеграція SSAI у процесі проектування |
Бізнес-проблема
Кожна комерційна пауза на FAST-каналі є подією для отримання доходу. Канал видає маркер, який говорить: "тут буде реклама, вона триватиме 30 секунд, будь ласка, підготуйтеся." Нижчі системи — Google Ad Manager, AWS MediaTailor, регіональні рекламні сервери, SDK плеєрів смарт-ТБ — зчитують цей маркер і вирішують, що вставити.
Коли маркер правильний, рекламна пауза проходить без збоїв, покази враховуються, і оператор отримує оплату. Коли маркер неправильний — неправильна тривалість, неправильна форма, неправильний формат — рекламна система або відхиляє його (реклама не показується), або приймає його неправильно (реклама неправильної довжини, або та, що виходить за межі наступної програми). Обидва результати коштують реальних грошей, і обидва завершуються мовчки. Канал продовжує трансляцію. Глядач бачить заставку або незручний перехід. Пайплайн монетизації просто видає нижчі цифри та не містить повідомлень про помилки для подальшого аналізу.
Інженерна мета не полягає в "підтримці реклами". Вона полягає в тому, що: кожна рекламна пауза, визначена оператором, повинна надходити до кожного подальшого споживача як сигнал SCTE-35, що відповідає стандартам, у точному кадрі, обраному оператором, кожного разу.
Що таке SCTE-35 насправді (90-секундна версія)
SCTE-35 — це стандарт для вставки сигнальних повідомлень у відеопотік. Ці сигнали не містять рекламного контенту; вони несуть сигнали — "рекламна пауза починається тут", "рекламна пауза закінчується тут", "цей сегмент має тривалість N секунд". Подальша система зчитує ці сигнали та діє відповідно: рівень SSAI вставляє реальний рекламний креатив у маніфест HLS, плеєр смарт-ТБ запускає оверлей, рекламний сервер реєструє можливість слота.
Для нашого випадку важливі дві форми сигналів:
- SpliceInsert — оригінальний сигнал SCTE-35. Містить SpliceEventId, тривалість у секундах та прапорець "out of network". Більшість класичних рекламних серверів читають це.
- TimeSignal — новіший, більш виразний сигнал. Містить SegmentationDescriptor з SegmentationTypeId (52 = Початок реклами провайдера, 53 = Кінець реклами провайдера) та SegmentationDuration в одиницях 90 000 тактів. Системи SSAI та сучасні плеєри віддають перевагу цій формі, оскільки вона чітко поєднується між початком та кінцем.
Обидві форми є коректними SCTE-35. Різні подальші споживачі віддають перевагу різним формам. Надсилання лише однієї форми призводить до втрати доходу.
Чому це важливо. Наївна реалізація надсилає один SpliceInsert на кожну рекламну паузу і вважає, що все зроблено. Рекламна пауза працює на старих плеєрах і мовчки не працює на SSAI. Половина вашого рекламного інвентарю монетизується; половина — ні. Ви не дізнаєтеся, що саме, доки ваші показники доходу не будуть низькими.
Чому наївні підходи зазнають невдачі
Швидкі рішення привабливі, тому що всі вони майже працюють.
- "Під час кодування вставляти рекламу в оригінальне відео." Немає місця для гнучкості. Оператор не може проводити A/B-тестування розміщення, не може змінювати рекламу після розгортання, не може запускати регіональну або цільову рекламу. Вся причина існування FAST-каналів — це монетизація одного й того ж контенту різними способами; вбудовування реклами під час кодування унеможливлює це.
- "Використовувати вставку реклами на стороні клієнта." Блокування реклами просте. Різний шлях коду для кожного пристрою. Немає персоналізації на стороні сервера. І це повністю обходить SSAI, що означає нижчі CPM.
- "Просто надсилайте один SpliceInsert на кожну паузу." Найпоширеніша помилка в продакшені. Працює на деяких плеєрах, мовчки ігнорується системами SSAI, які вимагають TimeSignal сигналів для зв'язування початку/кінця. Часткова монетизація, без помилок для дослідження.
- "Виражати все в тактах 90 кГц, оскільки специфікація про це згадує." Специфікація складніша, ніж здається. SpliceInsert.Duration вимірюється в секундах. SegmentationDuration вимірюється в тактах 90 кГц. Змішування їх призводить до того, що сигнали проходять валідацію схеми та відправляються, а потім зазнають невдачі на плеєрі через некоректну тривалість. Кодер цього не виявить. Плеєр просто пропускає паузу.
- "Дозволити MediaLive підтвердити." Він цього не зробить. MediaLive приймає рекламні паузи, що перекриваються, паузи нульової тривалості та неможливі тривалості сегментації без скарг. Підтвердження має відбуватися до того, як MediaLive побачить дію.
Важелем, який ми мали, був кордон між інтерфейсом користувача оператора — де рекламні паузи є просто парами {position, duration} — і розкладом MediaLive, де кожен сигнал має бути ідеальним.
Наше рішення
Розглядати рекламну паузу як першокласний об'єкт даних наскрізно. Оператор визначає її в найпростіших термінах. Бекенд перевіряє її один раз на рівні схеми. Lambda перетворює її на стек із трьох сигналів під час розгортання, причому кожен сигнал виражений у часовій базі, яку вимагає його власна специфікація. Ніщо інше в стеку не повинно знати про SCTE-35 — перетворення відбувається в одній функції, в тій самій Lambda, яка керує всіма іншими діями розкладу.
Діаграма 1 · Наскрізний пайплайн рекламних маркерів
Архітектура
- Редактор рекламних пауз на фронтенді — оператори додають рекламні паузи для кожної програми, вказуючи зміщення позиції (секунди від початку програми) та тривалість (секунди). Слоти бамперів є частиною моделі даних і готові для рівня відтворення.
- AdMarker колекція (MongoDB) — один документ на програму з рекламними паузами, що посилається на відео. Масив adBreaks[] зберігає {position, duration}, причому Mongoose забезпечує 10 ≤ duration ≤ 120 під час збереження. Бампери містять посилання adBreakId для подальшого зв'язування.
- Бекенд NestJS (schedule.service.ts) — під час розгортання приєднує кожен розклад до його AdMarker і перейменовує поля відповідно до контракту Lambda (position → offsetSeconds, duration → durationSeconds). Один масовий запит, без N+1.
- Оркестратор Lambda (fastChannel-lambda-fun/index.js) — відповідає за перетворення SCTE-35. Для кожної рекламної паузи надсилає стек із трьох сигналів у ту саму BatchUpdateScheduleCommand, яка містить перемикачі вхідних сигналів та водяні знаки. Імена дій версіонуються для кожної програми, щоб очищення від сирітських записів могло їх поєднати після часткового розгортання.
- AWS MediaLive — отримує дії, надсилає маркери #EXT-SCTE35 у маніфесті HLS у секунду, обрану оператором.
Ключові інженерні рішення
1. Три сигнали на рекламну паузу, а не один
Кожна рекламна пауза надсилає три окремі дії для одного й того ж логічного моменту в програмі.
Діаграма 2 · Життєвий цикл однієї рекламної паузи
Початковий та кінцевий сигнали TimeSignal мають спільний SegmentationUpid, щоб подальші системи могли детерміновано їх поєднувати. SpliceInsert містить унікальний SpliceEventId для дедуплікації на рівні плеєра. Різні споживачі читають різні сигнали. Надсилання всіх трьох охоплює кожен контракт, який нас цікавить сьогодні, і кожен імовірний завтра.
Поширена помилка в продакшені. Надсилати один SpliceInsert і припускати, що решта екосистеми зрозуміє. Системи SSAI мовчки відкидають паузи, яким бракує відповідних сигналів TimeSignal; класичні рекламні сервери ігнорують сигнали лише TimeSignal. Без усіх трьох кожна рекламна пауза монетизується частиною вашого нижнього стеку і пропускається рештою — і ви дізнаєтеся про це зі звіту про доходи, а не з логів.
2. Дві часові бази, узгоджені в одній функції
SpliceInsert.Duration вимірюється в секундах. SegmentationDuration всередині дескриптора TimeSignal вимірюється в одиницях 90 000 тактів. Однакова логічна тривалість, два кодування — і найпоширенішою помилкою SCTE-35 є їхнє змішування.
Діаграма 3 · Логіка перетворення часу
Перетворення відбувається в buildProgramActions і тільки там. Існує одне канонічне місце для перевірки, якщо тривалість сигналу виявиться неправильною, і одне місце для зміни, якщо специфікація коли-небудь розвиватиметься.
Компроміс, на який ми пішли свідомо. Ми могли б зберігати обидві часові бази в документі AdMarker і дозволити Lambda копіювати їх. Ми свідомо цього не зробили: зберігання лише значення в секундах означає, що є лише одне число, яке оператор може встановити, лише одне число для перевірки, і лише одне число, яке може бути неправильним. Значення 90 кГц є похідним, ніколи не зберігається. Похідні дані не можуть зміщуватися.
3. Позиція відносна, час спрацьовування абсолютний
Оператор каже "рекламна пауза на 720-й секунді програми". Lambda обчислює фактичний час спрацьовування в UTC як programStartTime + offsetSeconds × 1000 і відмічає це в дії. Кожна інша дія розкладу — перемикання входу, увімкнення водяного знака, закінчення програми — використовує той самий пайплайн перетворення зміщення в мітку часу. Рекламні сигнали приземляються на ті ж межі кадрів, що й все інше, без двозначності щодо того, який годинник керує часовою шкалою.
4. Валідація на рівні даних, а не на мережевому рівні
Схема AdMarker забезпечує виконання duration ∈ [10, 120] секунд під час збереження Mongoose. Пауза, що виходить за межі діапазону, ніколи не досягає Lambda. Рекламні паузи, які б виходили за межі закінчення програми, обрізаються під час збірки, а не відхиляються — оператори не втрачають свою роботу через одну погану паузу. Класи помилок, які не можуть статися, цікавіші, ніж ті, що можуть.
5. Надсилання сигналів відокремлено від SSAI
Те, що ми постачаємо сьогодні, — це рівень сигналізації. Вставка реклами на стороні сервера через AWS MediaTailor — яка буде споживати ці сигнали для вставки реальних рекламних креативів у маніфест HLS — повністю розроблена, але ще не підключена. Навмисний порядок: спочатку отримати коректний рівень сигналів, у продакшені, який використовується реальними каналами, перш ніж вмикати SSAI. Коли інтеграція буде запущена, сигнали вже будуть там. Подальша система отримує чистий контракт для споживання з першого дня.
Чому цей порядок важливий. Налагодження SSAI є жорстоким, коли ваші сигнали неправильні, тому що кожна відмова виглядає як відмова SSAI, навіть якщо винні сигнали. Надсилаючи рівень сигналів ізольовано спочатку та перевіряючи його на реальних плеєрах та рекламних серверах, ми усунули цілу категорію плутанини з інтеграцією, перш ніж вона могла статися.
Результати
- Кожна рекламна пауза, визначена оператором, видає стек SCTE-35, що складається з трьох сигналів, які відповідають стандартам, у маніфесті HLS каналу — у потрібну секунду, відповідно до правильної часової бази.
- Рівень перетворення знаходиться в одній функції. Зміни в специфікації або нові подальші споживачі потребують зміни одного файлу, а не пошуку по всій кодовій базі.
- Перевірка тривалості виконується на рівні даних, перш ніж будь-який сигнал досягне кодера. Помилки оператора виявляються в інтерфейсі користувача, а не мовчки в ефірі — неправильно сформовані сигнали не можуть досягти MediaLive.
- Генерація сигналів є детермінованою: ідентичні вхідні дані оператора призводять до ідентичних дій SCTE-35, тому та сама пауза поводиться однаково при кожному розгортанні та на кожному каналі.
- Рівень сигналізації випущений і працює. Споживач SSAI (MediaTailor) розроблений і готовий до підключення — і коли це станеться, сигнали кожного існуючого каналу вже будуть чекати на нього.
Стек технологій: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · SCTE-35 (Scte35TimeSignalSettings, Scte35SpliceInsertSettings) · AWS SDK v3
