Мониторинг рекламных вставок

Video Compression Guru
«Делать деньги без рекламы может только монетный двор».
Томас Бабингтон Маколей, британский историк, публицист и политический деятель

Реклама — неотъемлемая часть телевещания. С её помощью предприниматели продвигают свои товары и услуги, а средства массовой информации получают прибыль.
Продажа эфирного времени — существенная, а порой и единственная статья доходов для телеканалов. Так например, телекомпания NBC заработала 70 миллионов долларов на показе последнего эпизода «Друзей» в 2004 году: каждый 30-секундный рекламный блок стоил два миллиона долларов. Это был рекордный сбор и рекордная цена для развлекательного шоу. А минута рекламы во время трансляций матчей Чемпионата мира по футболу-2018 на «Первом канале» и «России 1» стоила 7,5 миллиона рублей. Но абсолютным рекордсменом принято считать рекламные блоки во время Супербоула, финальной игры за звание чемпиона НФЛ США в американском футболе: стоимость рекламного слота в 2021 году составляет около $5,5 млн.
Как мы видим, суммы внушительные, и это большая ответственность на плечах тех, кто предоставляет рекламу. Необходимо тщательно следить за технической реализацией вставки и контролировать качество процесса.

В этой статье мы рассмотрим, как реализуется вставка рекламы в транспортный поток и в потоки при адаптивном вещании в форматах HLS и MPEG-DASH, а также разберемся, как тем, кто предоставляет эфирное время для рекламы, избежать споров и судебных процессов с заказчиками.
Для выделения эфирного времени под рекламу в телевещании широко используются метки SCTE-35. По этим меткам специальное оборудование — сплайсер — врезает рекламу в поток. В процессе работы сплайсер непрерывно обращается к FTP-серверу, запрашивая актуальное расписание врезки и заранее подготовленные файлы рекламы. Когда расписание обновляется, сплайсер сверяет список хранящихся медиафайлов с запланированными к врезке и при необходимости скачивает недостающие файлы с FTP-сервера. Метки SCTE-35, приходящие в транспортном потоке, обозначают начало и окончание врезки.
Проблем с предоставлением рекламы может возникнуть довольно много. Все начинается с первоначальной вставки меток SCTE-35 в поток. На этом моменте необходимо точно выделить эфирное время для рекламы в потоке и вставить нужные метки. Некоторые пакеты в транспортном потоке могут быть утеряны, поэтому стандарт предусматривает повторение меток.
Синтаксис полезной нагрузки метки SCTE-35 называется splice_info_section (). Он сигнализирует об одной из шести команд. Команды Splice_schedule() и Splice_insert() предназначены для передачи информации о предстоящей вставке рекламы. Также существует ряд вспомогательных команд: Splice_null(), Bandwidth reservation(), Time_signal(), Private_command(). Однако, в основном для вставки рекламы используются команды splice_insert() и time_signal().
  • Команда Splice_null() не передает какие-либо данные и используется для проверки отклика от устройств — получателей сообщений. Кроме того, периодическая вставка этой команды позволяет избежать срабатывания триггеров TR101290 — PID_error.
  • Команда Bandwidth reservation() передает системе компрессии запрос на выделение дополнительной полосы пропускания, которая будет использоваться для передачи элементарного PID-потока с сообщениями SCTE-35.
  • Команда Time_signal() используется для передачи меток точного времени, на основании которых устройства-получатели команды синхронизируют свои действия с устройствами-отправителями.
  • Команда Private_command() может использоваться для передачи других данных, не оговоренных в спецификациях SCTE-104/35.
Рассмотрим одну из главных команд метки SCTE-35 в транспортном потоке - splice_insert():



Здесь стоит обратить внимание на элемент out_of_network_indicator. Значение «1» означает вход в рекламную вставку, значение «0» — выход. Эти элементы еще обозначаются как cue-out (выход из программы и вход в рекламный блок) и cue-in (выход из рекламного блока, возвращение в основной поток). В дальнейшем разберем эти элементы на примере.
Проблемы могут быть связаны и с непосредственно врезкой рекламы: в этом процессе довольно много нюансов, которые стоит учитывать.
Вот несколько примеров:
  • Врезка рекламы сплайсером должна осуществляться точно в указанное время, описанное в метке SCTE-35, ни кадром раньше или позже;
  • Рекламный блок не должен отличаться по своей структуре от основного потока (кодек/битрейт/GOP/громкость и т. д);
  • Рекламный блок должен начинаться строго с I-кадра, иначе первый GOP рекламной вставки будет испорчен.
Мониторинг рекламных вставок в IPTV
Учитывая вышеописанные нюансы, а также помножив их на количество регионов, где используется местная реклама, возникает вопрос: как же уследить за качеством процесса? Для этого существуют системы мониторинга потоков.
Рассмотрим вставку рекламы на реальном потоке в системе мониторинга, которую использую я, — Elecard Boro.

График вставки рекламы

На графике видим три метки, предвещающие вставку рекламы. Затем начинается сама вставка, и эскизы потока создаются чаще. Рассмотрим более детально, что именно происходит в потоке в эти моменты.

Журнал событий

1) Метка SCTE-35 из TS-потока (команда splice_insert) 2021-07-09 15:52:00 +0700 {"source":"TS","data":{"program":1100,"pid":1015,"pts_adjustment":0,"command_type":"splice_insert","event_id":"1073743534","auto_return":true,"duration":120,"out_of_network_indicator":true,"pts_time":"25:40:54.394","unique_program_id":"1"}}

Первая метка указывает, что должна начаться реклама: , "out_of_network_indicator:true” (true означает 1, или cue-out, вход в рекламу) в конкретно указанное время: "pts_time":"25:40:54.394”.
“auto_return":true — означает, что из рекламного блока необходимо выполнить  cue-in (выход из рекламы) автоматически по истечении 120 секунд  ("duration":120”),
Программа — "program":1100;
PID, по которому идут метки — "pid":1015 .
Вторая и третья метка полностью дублируют информацию и идут с интервалом в 2 секунды. Дублирование производится на случай потери пакетов в потоке.
2) Вставка рекламного блока SCTE-35 2021-07-09 15:52:08 +0700 {"action":"start","type":"scte35","params {"program":1100,"pid":1015,"pts_adjustment":0,"command_type":"splice_insert","event_id":"1073743534","auto_return":true,"duration":120,"out_of_network_indicator":true,"pts_time":"25:40:54.394","unique_program_id":"1"}} Метка SCTE-35 из TS-потока (команда splice_insert)2021-07-09 3:52:04 PM +0700
Далее идет непосредственно вставка рекламного блока уже на основании полученных меток: "action":"start".
3) Вставка рекламного блока SCTE-35 2021-07-09 3:54:07 PM +0700 {"action":"stop","type":"scte35","params":{"program":1100,"pid":1015,"pts_adjustment":8331695488,"command_type":"splice_insert","event_id":"1073743534","auto_return":true,"duration":120,"out_of_network_indicator":false,"pts_time":"25:40:54.394","unique_program_id":"1"}}
Спустя 120 секунд происходит выход из рекламного блока: "out_of_network_indicator":false / "action":"stop".
В рассмотренном примере вставка рекламы прошла без каких-либо проблем. Но если в метке содержатся ошибки, то система мониторинга проверяет целостность CRC. В случае несоответствия она сообщает об этом и выводит подробности в журнал событий для дальнейшего анализа. Кроме того, пользователи могут сформировать отчет об ошибках, чтобы предоставить его ответственным лицам.
Ошибки могут быть следующих типов:
  • ошибка чтения бинарных данных в транспортном потоке или теге HLS. В параметрах передаются неверные значения, приведшие к ошибке;
  • ошибка проверки CRC32 при чтении бинарных данных в транспортном потоке или теге HLS;
  • несоответствие информации в бинарных данных тега и самом теге HLS плейлиста. Подробности представлены в параметрах в виде двух значений в формате tag_<data> и binary_<data>.
Мониторинг рекламных вставок в OTT
ОТТ вещание открыло новые преимущества для вставки рекламы, но и принесло свои трудности.
С одной стороны, реклама стала персонализированной, так как каждое устройство устанавливает индивидуальную сессию, это позволяет показать зрителю то, что его потенциально интересует. Кроме того, в ОТТ вещании не требуется соответствие рекламного блока основному потоку, поскольку каждый сегмент ОТТ вещания декодируется устройством отдельно, и это упрощает сплайсинг рекламы.
С другой стороны, SCTE-35 метки могут находиться не только в транспортном потоке, но и в плейлисте. Т. е. метки дублируются, что в принципе проблемой не является, но и корректным вариантом потока такую ситуацию назвать нельзя. Метки в плейлисте тоже могут потеряться, но уже не из-за пропадания пакетов, а по другим причинам, например, оборудование могло не записать метку в плейлист при обновлении.
Система мониторинга отслеживает следующие события, происходящие с вещанием.
Вставка рекламного блока SCTE-35. Срабатывает, когда зонд определяет начало вставки рекламного блока (по информации из полученных меток SCTE-35). Состояние снимается, когда зонд определяет завершение рекламного блока. Это событие является основой для некоторых событий, которые определяют проблемы со вставкой рекламы.
Вставка превышает заданную длительность. Срабатывает, когда длительность рекламного блока превышает установленный период. Период отсчитывается с момента определения зондом начала рекламного блока по событию «Вставка рекламы».
Ошибка распознавания меток SCTE-35. Срабатывает, когда регистрируется ошибка распознавания меток вставки рекламы. В сообщении возвращаются подробности ошибки.
Вставка рекламного блока SCTE-35 отсутствует. Срабатывает, когда зонд в течение установленного времени не обнаруживает начало вставки рекламного блока в программу (по информации из полученных меток SCTE-35). Состояние снимается, когда зонд определяет начало рекламного блока. Триггер реализован на основе события «Вставка рекламного блока SCTE-35».
Метки SCTE-35 не найдены в плейлисте. Срабатывает, когда зонд не находит каких либо меток вставки в плейлисте в течение установленного времени. Триггер реализован на основе события «Метка SCTE-35 из OTT-плейлиста». Данное событие может быть полезно в ситуации когда мы уверены, что реклама должна быть за определенный промежуток времени, но по каким-либо причинам метки SCTE-35 в плейлисте отсутствуют и вставка рекламы не происходит. В этом случае необходимо искать причины потери меток в плейлисте.

Мониторинг рекламных вставок в OTT

Заключение
Мониторинг рекламных вставок — довольно непростая задача по множеству причин, но с ней можно справиться с помощью правильного инструмента.
Хорошая система мониторинга журналирует каждую метку вставки, найденную в потоке или в плейлисте. Что, вкупе с возможностью записи по приему метки и эскизами потока, позволяет провести детальное исследование произошедшего. Инструмент позволяет проверять целостность метки и возможности ее декодирования. А триггеры на отсутствие вставки рекламы или слишком длительной вставки, помогают своевременно выявить неполадки в работе системы врезки рекламы.

Автор: Вадим Блинов, менеджер продукта Elecard CodecWorks c 2016 года. Опыт работы в сфере видеокодирования более 5 лет.
5

Комментарии

Oskarr
+367
Чтоб ваша реклама рухнула раз и навсегда и везде. Задолбали с ней.
19 ноября 2021 в 22:57
#
Олег Воронин
+2358
И будете платить злотыми за всё налево и направо.
За каждый сайт.
За каждый трек.
За каждую передачу каждого телеканала.
За каждый видеоролик каждого YouTube-блогера.
21 ноября 2021 в 15:34
#

Читайте также