21.10

  1. Авторизационный бэкенд теперь может обновлять конфигурацию стрима для каждой сессии.
    Для этого мы реализовали 2 новых механизма в контексте авторизации. On_publish – механизм авторизации сессий публикации, on_play – сессий проигрывания. Обе опции полезно использовать вместе с шаблонами.
    • On_publish. Взаимодействуя с UGC платформой, стримеры (публикаторы) используют разные камеры и разное оборудование для публикации. Или же, UGC платформы могут монетизировать сервис, предлагая стримерам различные тарифные планы и фичи: запись видеотрансляции в архив, рестриминг на YouTube и пр. Если стример, например, перешел на другой тарифный план или просто начал использовать другое оборудование, авторизационный бэкенд передаст эту информацию в виде обновленного конфига перед тем, как стрим запустится (начнется публикация видео). При этом, конфиг-файл ingest-серверов Flussonic остается статичным. И он не будет меняться с изменением количества пользователей. Это даст возможность быстро, без дополнительных настроек добавить ресурсы при увеличении нагрузки на сервис (например, к выходным дням). Кроме этого, on_publish позволит точно и быстро выполнить балансировку пула транскодеров, стоящих за ingest-серверами.
    • On_play. В более ранних версиях, для создания потоков на проигрывание с динамическим (заранее неизвестным) наименованием, был реализован механизм rewrite. Однако, rewrite представлял собой отдельную опцию внутри конфига Flussonic, то есть нужно было явно прописывать “реврайты” для каждого стрима/ publishing location и т.д. Использование on_play, в отличие от rewrite, позволит иметь статичную конфигурацию на всех серверах-рестримерах. Параметры конфигурации меняются только 1 раз на уровне авторизационного бэкенда.
      Авторизационный бэкенд быстро предоставит актуальную информацию о том, с какого транскодера надо забрать поток для конкретной сессии проигрывания. Это особенно важно в контексте крупных стриминговых платформ. При десятках тысяч открытых сессий, использование механизмов peer и source означало бы долгий поиск нужного стрима по списку серверов.
      Узнайте, как настроить новые опции.
  2. Внедрен новый механизм врезки рекламы методом замены сегментов потока в play сессии
    • В каждой сессии просмотра, сегмент потока меняется в реальном времени на сегмент из рекламного ролика. URL сегмента с рекламой остается одинаковым для всех зрителей потока. При этом, с одного URL можно показывать разную рекламу для разных пользователей.
      2110-2
    • Отличить URL сегмента основного потока от URL рекламного сегмента невозможно. Это дополнительно защищает рекламу от вырезания.
      2110-1
    • Доступно для HLS и DASH (как для мультипериодных манифестов, так и для манифестов с монопериодом.
    • Позволяет делать уникальную таргетированную для каждого пользователя или сессии рекламу без транскодирования.
    • Равная длина сегментов основного потока и рекламного ролика обеспечивает бесшовное переключение между сегментами (поток не будет “рваться” во время рекламных пауз). Обратите внимание, что рекламные ролики должны быть подготовлены специальным образом.

      Этот новый способ врезки рекламы – первый шаг, сделанный для улучшения всего модуля монетизации через рекламу. В ближайших планах – добавление врезки по SCTE-меткам, а также построение удобной системы подготовки рекламных роликов для врезки.
      Врезка рекламы методом замены сегментов потока включается опцией v2 в настройках авторизационного бекенда. Узнайте, как это сделать.

  3. Реализован новый дизайн API со спецификацией в формате Open API 3.0
    • Обеспечить единообразие методов доступа к разным системам
    • Предоставить формализованную схему сервиса, т.е. список доступных методов и описание входных и выходных данных
    • Отказ от сверхсложных правил парсинга строки запроса в пользу JSON-языка запроса
    • Предоставление динамически изменяющихся данных в любой момент времени (н-р, битрейт потока)
      Узнать больше про Flussonic HTTP API.
      2110-3