Почему я решил рассказать о стриминге видео?

Что такое набор инструментов Akka? Удобно ли им пользоваться?

Что такое Akka Streams?

Что такое Akka HTTP?

HTML5-тег <video>

Как будет работать стриминг с использованием тега и FileIO?</font></h2>Хотя на первый взгляд кажется, что стриминг с использованием тега <video> и FileIO это нечто архисложное, если в этот вопрос немного вникнуть, окажется, что ничего особенного в нём нет. Дело в том, что то, о чём идёт речь, представлено готовыми блоками, из которых нужно лишь собрать то, что нам нужно.На стороне сервера основная нагрузка ложится на объект <code>FileIO</code>. Он будет генерировать события, содержащие фрагменты файла, потоковую передачу которого мы осуществляем. Конечно, размеры этих фрагментов поддаются настройке. И, более того, настроить можно и позицию, начиная с которой будет осуществляться стриминг файла. То есть видео необязательно смотреть сначала его можно начинать смотреть с любого места, интересующего пользователя. Всё это отлично сочетается с возможностями тега <code><video></code>, выполняющего запрос HTTP GET с заголовком <code>Range</code> для того чтобы включить воспроизведение видео без его предварительной загрузки.Вот пара примеров запросов, выполняемых элементом <code><video></code>:<img src="http://personeltest.ru/aways/lh3.googleusercontent.com/Dfgd_RjgpV9W3jzBF9TVNLT_n8cAf5_VfvhxbfeK5wYH5slwUtXhjQ0FlZ0I79gCWsNgIF1Q3q7nPty5HqpCpgXIYrEtjQINuyMaMHe1nWu228-p8o9Hf3n-cHNZN_5iS0QGktk" align="center"><img src="http://personeltest.ru/aways/lh3.googleusercontent.com/SQPBs8xy8HVsT8cw2_WRoOnQW1dqKRp2WVSAzfFsbCBkSmETbm7NKS8zMLBdwcWdIo1AQDO_tSJJw1_2Tcd_oMoaBzdTwDz62Tq2jtzKX0ujmuCEqo99NKH_YLnlL6FQbZ5UOd0" align="center">Если кому интересно заголовок <code>Range:bytes=x-</code> отвечает за выбор позиции, с которой начинается воспроизведение видео. Первый запрос уходит на сервер в начале воспроизведения видео, а второй может быть отправлен тогда, когда пользователь решит куда-нибудь перемотать видео.Сейчас, после довольно-таки длинного вступления, пришло время заняться кодом.<h2><font color="#3AC1EF">Пишем стриминговый сервис</font></h2>В нескольких следующих разделах я расскажу о реализации серверной части нашего стримингового сервиса. А потом мы создадим простую HTML-страницу, с помощью которой проверим правильность работы этого сервиса.Я люблю делать предположения, поэтому сделаю ещё одно, которое заключается в том, что я ожидают, что тот, кто это читает, владеет основами Scala и SBT.<h3><font color="#3AC1EF">1</font></h3>Добавим в файл <code>build.sbt</code> необходимые зависимости. В этом проекте нам понадобится 3 пакета: <code>akka-http</code>, <code>akka-actor-typed</code> (пакета <code>akka-actor</code>, в теории, достаточно, но никогда нельзя забывать о типобезопасности) и <code>akka-stream</code>.<source lang="scala">libraryDependencies ++= Seq("com.typesafe.akka" %% "akka-actor-typed" % "2.6.14","com.typesafe.akka" %% "akka-stream" % "2.6.14","com.typesafe.akka" %% "akka-http" % "10.2.4")</source><h3><font color="#3AC1EF">2</font></h3>Теперь можно создать главный класс, ответственный за запуск приложения. Я решил расширить класс <code>App</code>. Мне кажется, что это удобнее, чем создавать метод <code>main</code>. На следующем шаге мы поместим сюда код, имеющий отношение к созданию системы акторов и HTTP-сервера.<source lang="scala">object Runner extends App {}</source><h3><font color="#3AC1EF">3</font></h3>После создания главного класса мы можем добавить в него код, о котором говорили выше.<source lang="scala">object Runner extends App {val (host, port) = ("localhost", 8090)implicit val system: ActorSystem[Nothing] = ActorSystem(Behaviors.empty, "akka-video-stream")Http().newServerAt(host, port)}</source>Сейчас нас вполне устроит такая конфигурация. На последнем шаге мы добавим в код вызов метода <code>bind</code>, что позволит открыть доступ к нашему REST API. Тут мы создаём объект <code>ActorSystem</code> с именем <code>akka-video-stream</code> и HTTP-сервер, прослушивающий порт <code>8090</code> на локальном компьютере. Не забудьте о ключевом слове <code>implicit</code> в определении системы акторов, так как подобный неявный параметр необходим в сигнатуре метода <code>Http</code>.<h3><font color="#3AC1EF">4</font></h3>А тут мы, наконец, реализуем конечную точку REST API, используемую для обработки запросов от тега <code><video></code>.<source lang="scala">object Streamer {val route: Route =path("api" / "files" / "default") {get {optionalHeaderValueByName("Range") {case None =>complete(StatusCodes.RangeNotSatisfiable)case Some(range) => complete(HttpResponse(StatusCodes.OK))}}}}</source>Как видите, я создал конечную точку с URL <code>api/files/default/</code>. В её коде проверяется, есть ли в запросе заголовок <code>Range</code>. Если он содержит корректные данные сервер возвращает ответ с кодом <code>200</code> (<code>OK</code>). В противном случае возвращается ответ с кодом <code>416</code> (<code>Range Not Satisfiable</code>).<h3><font color="#3AC1EF">5</font></h3>Пятый шаг нашей работы отлично подходит для реализации метода, ради которого, собственно, и была написана эта статья.<source lang="scala">private def stream(rangeHeader: String): HttpResponse = {val path = "path/to/file"val file = new File(path)val fileSize = file.length()val range = rangeHeader.split("=")(1).split("-")val start = range(0).toIntval end = fileSize - 1val headers = List(RawHeader("Content-Range", s"bytes ${start}-${end}/${fileSize}"),RawHeader("Accept-Ranges", s"bytes"))val fileSource: Source[ByteString, Future[IOResult]] = FileIO.fromPath(file.toPath, 1024, start)val responseEntity = HttpEntity(MediaTypes.`video/mp4`, fileSource)HttpResponse(StatusCodes.PartialContent, headers, responseEntity)}</source>Тут я сделал следующее:<ul><li>Загрузил файл, потоковую передачу которого я хочу организовать, а затем, учитывая заголовок из запроса, и данные о файле, нашёл позицию в файле, с которой начнётся стриминг, а так же сформировал заголовок <code>Content Range</code>.</li><li>С помощью <code>FileIO</code> создал поток из ранее загруженного файла. Затем я использовал этот поток в роли данных в <code>HttpEntity</code>.</li><li>Я создал ответ, <code>HttpResponse</code>, с кодом <code>206</code> (<code>Partial Content</code>), с соответствующими заголовками и с телом в виде <code>responseEntity</code>.</li></ul>Ещё мне хочется подробнее поговорить о <code>FileIO</code>, так как это самый удивительный механизм во всей статье. Что, на самом деле, происходит при выполнении строки <code>FileIO.fromPath(file.toPath, 1024, start)</code>?Тут, из содержимого файла, находящегося по заданному пути, создаётся объект <code>Source</code> (Akka-аналог Producer из Reactive Streams). Каждый элемент, выдаваемый этим объектом, имеет размер, в точности равный 1 Мб. Первый элемент будет взят из позиции, указанной в параметре <code>start</code>. Поэтому, если в <code>start </code>будет 0 первый элемент окажется первым мегабайтом файла.<h3><font color="#3AC1EF">6</font></h3>Мы уже реализовали основную логику серверной части приложения. А сейчас нам надо отрефакторить её код для того чтобы нашим сервером можно было бы пользоваться.Начнём с внесения изменений в определение REST API:<source>complete(HttpResponse(StatusCodes.Ok)) => complete(stream(range))</source>Получается, что вместо того, чтобы просто возвращать <code>OK</code>, мы вызываем метод <code>stream</code> с передачей ему параметра <code>range</code> и начинаем стриминг.Нельзя забывать о том, что наш API всё ещё недоступен для внешнего мира. Поэтому нам нужно модифицировать соответствующий фрагмент кода, ответственный за запуск HTTP-сервера:<source>Http().newServerAt(host, port) =>Http().newServerAt(host, port).bind(Streamer.route)</source>Готово! Теперь у нас есть рабочий бэкенд, а наш REST API ждёт подключений от любых программ, которым он нужен. Осталось лишь всё протестировать.<h2><font color="#3AC1EF">Тестирование стримингового сервиса</font></h2>Мы, чтобы протестировать приложение, создадим простую HTTP-страницу, единственным достойным внимания элементом которой будет тег <code><video></code>. Причём, обо всём, что надо знать для понимания работы этой страницы, мы уже говорили. Поэтому я просто приведу ниже полный код соответствующего HTML-документа.То, что вы в итоге увидите в окне браузера, открыв эту страницу, должно, более или менее, напоминать то, что я покажу ниже. Конечно, ваш стриминговый сервис вполне может передавать не тот видеофайл, который использовал я.<source lang="html"><!DOCTYPE html><html lang="en"><head><title>Akka streaming example</title></head><body style="background: black"><div style="display: flex; justify-content: center"><video width="1280" height="960" muted autoplay controls><source src="http://personeltest.ru/away/localhost:8090/api/files/default" type="video/mp4">Update your browser to one from XXI century

1. Я использовал возможности тега <source> вместо использования соответствующих атрибутов тега <video>.
2. В атрибуте src тега <source> я указал путь, при обращении к которому бэкенд начнёт потоковую передачу видеофайла.
3. В атрибуте type тега <source> я указал тип файла.
4. Я добавил к тегу <video> атрибуты autoplay и muted для того чтобы видео начинало бы воспроизводиться автоматически.
5. К тегу <video> я добавил и атрибут controls, благодаря чему будут выводиться элементы управления видеоплеера, встроенного в страницу.

Что можно улучшить?

Итоги

Этой весной мы оказались в очень весёлых условиях. Из-за пандемии стало ясно, что наши летние конференции необходимо переносить в онлайн. А чтобы провести их в онлайне качественно, нам не подходили готовые софтовые решения, требовалось написать собственное. И на это у нас было три месяца.

Понятно, что это были увлекательные три месяца. Но со стороны не вполне очевидно: что вообще представляет собой платформа для онлайн-конференций? Из каких частей она состоит? Поэтому на последней из летних конференций DevOops я расспросил тех, кто отвечал за эту задачу:

• Николай Молчанов технический директор JUG Ru Group;
• Владимир Красильщик прагматичный Java-программист, занимающийся бэкендом (вы также могли видеть его доклады на наших Java-конференциях);
• Артём Никонов отвечает за весь наш видеостриминг.

Кстати, на осенне-зимних конференциях мы будем использовать улучшенную версию той же платформы так что многие хабрачитатели ещё окажутся её пользователями.

Общая картина

Каким был состав команды?

Николай Молчанов: У нас есть аналитик, дизайнер, тестировщик, три фронтендера, бэкендер. И, конечно, T-shaped специалист!

Как в целом выглядел процесс?

Николай: До середины марта у нас к онлайну не было готово вообще ничего. А 15 марта завертелась вся карусель с онлайном. Мы завели несколько репозиториев, спланировали, обсудили базовую архитектуру и сделали всё за три месяца.

Это, конечно, прошло классические этапы планирования, архитектуры, выбора фич, голосование за эти фичи, политики этих фич, их дизайна, разработки, тестирования. В итоге 6 июня мы выкатили всё в прод на TechTrain. На всё про всё было 90 дней.

Получилось ли успеть то, на что мы коммитились?

Николай: Раз мы сейчас участвуем в конференции DevOops в онлайне значит, получилось. Я лично закоммитился на главную вещь: принесу заказчикам инструмент, при помощи которого можно будет сделать конференцию в онлайне.

Задача стояла так: дайте нам инструмент, с помощью которого мы сможем транслировать наши конференции обладателям билетов.

Все планирование было разбито на несколько этапов, и все фичи (около 30 глобальных), были поделены на 4 категории:

• которые мы сделаем обязательно (без них жить не можем),
• которые мы сделаем во вторую очередь,
• которые мы никогда не сделаем,
• и которые никогда-никогда не сделаем.

Все фичи из первых двух категорий мы сделали.

Я знаю, что всего было заведено 600 JIRA-задач. За три месяца вы сделали 13 микросервисов, и подозреваю, что они написаны не только на Java. Вы использовали разные технологии, у вас поднято два Kubernetes-кластера в трех зонах доступности и 5 RTMP-стримов в Amazon.

Давайте теперь разберёмся с каждой составляющей системы по отдельности.

Стриминг

Начнём с того, когда у нас уже есть видео-картинка, и она передаётся на какие-то сервисы. Артём, расскажи, как происходит этот стриминг?

Артём Никонов: Общая схема у нас выглядит так: изображение с камеры -> наша пультовая -> локальный RTMP-сервер -> Amazon -> видеоплеер. Подробнее писали об этом на Хабре в июне.

Вообще есть два глобальных пути, как это можно делать: либо на железе, либо на базе софтверных решений. Мы выбрали путь софта, потому что это проще в случае с удалёнными спикерами. Не всегда есть возможность привезти спикеру в другой стране железку, а поставить ПО спикеру кажется проще и надёжнее.

С точки зрения железа у нас есть некоторое количество камер (в наших студиях и у удалённых спикеров), некоторое количество пультов в студии, которые иногда приходится чинить прямо во время эфира под столом.

Сигналы от этих устройств попадают в компьютеры с платами захвата, ввода/вывода, звуковыми карточками. Там сигналы микшируются, собираются в лейауты:

Пример лейаута на 4-х спикеров

Пример лейаута на 4-х спикеров

Дальше беспрерывный эфир обеспечивается с помощью трёх компьютеров: есть одна главная машина и пара работающих по очереди. Первый компьютер собирает первый доклад, второй перерыв, первый следующий доклад, вторый следующий перерыв и так далее. А главная машина микширует первую со второй.

Таким образом получается некий треугольник, и в случае падения любого из этих узлов мы можем быстро и без потери качества продолжить доставлять клиентам контент. Такая ситуация у нас была. На первой неделе конференций мы чинили одну машину, включали/выключали. Кажется, что люди довольны нашей отказоустойчивостью.

Далее потоки из компьютеров попадают на локальный сервер, у которого две задачи: роутить RTMP-потоки и записывать бэкап. Таким образом, у нас есть несколько точек записи. Затем потоки видео отправляются в часть нашей системы, построенную на амазоновских SaaS-сервисах. Используем MediaLive, S3, CloudFront.

Николай: А что там происходит до того, как видео попадёт к зрителям? Вы же должны его нарезать как-то?

Артём: Мы сжимаем со своей стороны видео, отправляем его в MediaLive. Там запускаем транскодеры. Они перекодируют видео в режиме реального времени в несколько разрешений для того, чтобы люди могли смотреть их на телефонах, через плохой интернет на даче и так далее. Потом эти стримы режутся на чанки, так работает протокол HLS. На фронтенд мы отдаем плейлист, в котором есть указатели на эти чанки.

Мы используем разрешение 1080р?

Артём: По ширине у нас как 1080p видео 1920 пикселей, а по высоте чуть меньше, картинка более вытянутая на это есть свои причины.

Плеер

Артём описал, как видео попадает в стримы, как распределяется на разные плейлисты для разных разрешений экранов, режется на чанки и попадает в плеер. Коля, расскажи теперь, что это за плеер, как он потребляет стрим, почему HLS?

Николай: У нас есть плеер, который наблюдают все зрители конференции.

По сути, это обёртка над библиотекой hls.js, на которой написано много других плееров. Но нам была необходима очень специфическая функциональность: перемотка назад и отметка на месте, в котором находится человек, какой доклад он сейчас смотрит. Также нужны были собственные лейауты, всякие логотипы и все прочее, что встроилось у нас. Поэтому мы решили написать собственную библиотеку (обёртку над HLS) и встроить это на сайт.

Это корневая функциональность, так что её реализовали практически первой. А потом вокруг этого всё уже обрастало.

По факту плеер через авторизацию получает от бэкенда плейлист со ссылками на чанки, соотнесённые с временем и качеством, выкачивает нужные и показывает пользователю, проводя по ходу некоторую магию.

Пример таймлайна

Прямо в плеер встроена кнопка для выведения таймлайна всех докладов

Николай: Да, мы сразу решали проблему навигации пользователя. В середине апреля решили, что не будем транслировать каждую из наших конференций на отдельном сайте, а объединим все на одном. Чтобы пользователи билетов Full Pass могли свободно переключаться между разными конференциями: и прямым эфиром, и записями прошедших.

А чтобы пользователям было проще передвигаться по текущему стриму и переключаться между треками, решили сделать кнопку Весь эфир и горизонтальные карточки докладов для переключения между треками и докладами. Там есть управление с клавиатуры.

Были какие-то технические сложности с этим?

Николай: Были с полоской прокрутки, на которой отмечаются точки начала разных докладов.

В итоге вы реализовали эти отметки на полосе прокрутки раньше, чем похожее сделал YouTube?

Артём: У них это тогда было в бете. Кажется, что это довольно сложная фича, потому что они частично тестировали ее на пользователях в течение последнего года. И вот теперь она дошла до прода.

Николай: Но мы действительно до прода донесли быстрее. Честно сказать, что за этой простой фичей стоит огромное количество и бэкенда, и фронтенда, и расчетов и матана внутри плеера.

Фронтенд

Давайте разберемся, как этот контент, который мы показываем (карточку доклада, спикеры, сайт, расписание), выходит на фронтенд?

Владимир Красильщик: У нас есть несколько внутренних айтишных систем. Есть система, в которой заведены все доклады и все спикеры. Есть процесс, по которому докладчик принимает участие в конференции. Спикер подает заявку, система её захватывает, дальше есть некий пайплайн, по которому создаётся доклад.

Так спикер видит пайплайн

Эта система наша внутренняя разработка.

Дальше из отдельных докладов нужно построить расписание. Как известно, это NP-сложная задача, но мы её как-то решаем. Для этого запускаем другой компонент, который формирует расписание и засовывает его в сторонний облачный сервис Contentful. Там всё выглядит уже как таблица, в которой есть дни конференции, в днях временные слоты, а в слотах доклады, перерывы или спонсорские активности. Так что контент, который мы видим, располагается в стороннем сервисе. И стоит задача донести его до сайта.

Казалось бы, сайт это просто страница с плеером, и ничего сложного тут нет. За исключением того, что это не так. Бэкенд, стоящий за этой страницей, идёт в Contentful, достает оттуда расписание, формирует некоторые объекты и отсылает на фронтенд. При помощи вебсокет-соединения, которое делает каждый клиент нашей платформы, мы с бэкенда на фронтенд закидываем ему обновление в расписании.

Реальный случай: спикер прямо во время конференции сменил работу. Надо поменять ему плашку компании-работодателя. Как это происходит с бэкенда? По вебсокету всем клиентам летит обновление, и дальше фронтенд уже сам перерисовывает таймлайн. Все это проходит бесшовно. Совокупность облачного сервиса и нескольких наших компонентов дают нам возможность сформировать весь этот контент и предоставить его фронту.

Николай: Здесь важно уточнить, что наш сайт не является классическим SPA-приложением. Это и свёрстанный, отрендеренный сайт, и SPA. На самом деле Google видит этот сайт как отрендеренный HTML. Это хорошо для SEO и для доставки пользователю контента. Он не ждет загрузки 1,5 мегабайт JavaScript, чтобы потом увидеть страницу, он сразу видит уже отрендеренную страницу, а вы это чувствуете каждый раз, когда переключаете доклад. Всё получается за полсекунды, так как контент уже готов и выложен в правильное место.

Подведём черту под всем вышесказанным, перечислив технологии. Тёма рассказал, что у нас есть 5 Amazon-стримов, туда доставляем видео и звук. Там у нас bash-скрипты, с их помощью запускаем, конфигурим

Артём: Это происходит через API AWS, там есть еще много побочных технических сервисов. Мы разделили свои обязанности так, что я доставляю на CloudFront, а фронтенд- и бэкенд-разработчики оттуда забирают. У нас некоторое количество своих обвязок для упрощения выкладки контента, который мы делаем потом в 4К и т.д. Поскольку сроки были очень сжатые, мы практически целиком сделали это на базе AWS.

Дальше все это попадает в плеер, используя бэкенд системы. У нас в плеере TypeScript, React, Next.JS. И на бэкенде у нас есть несколько сервисов на С#, Java, Spring Boot и Node.js. Это все разворачивается с помощью Kubernetes, используя инфраструктуру Яндекс.Облака.

Ещё хочу заметить, что когда мне понадобилось познакомиться с платформой, это оказалось несложно: все репозитории находятся на GitLab, всё хорошо названо, написаны тесты, есть документация. То есть даже в авральном режиме заботились о таких вещах.

Бизнес-ограничения и аналитика

Мы таргетировались по бизнес-требованиям на 10 000 пользователей. Самое время рассказать про бизнес-ограничения, которые у нас были. Мы должны были обеспечивать высокую нагрузку, обеспечивать выполнение закона о сохранении персональных данных. А что ещё?

Николай: Изначально мы отталкивались от требований к видео. Самое главное распределённое хранение видео по миру для быстрой доставки клиенту. Из других разрешение 1080р, а также перемотка назад, что у многих других в лайв-режиме не реализовано. Позже мы добавили возможность включить скорость 2x, с её помощью можно догнать лайв и дальше смотреть конференцию в реальном времени. И ещё по ходу появилась функциональность разметки таймлайна. Плюс к этому мы должны были быть отказоустойчивыми и выдерживать нагрузку 10 000 соединений. С точки зрения бэкенда это примерно 10 000 соединений умножить на 8 запросов на каждый рефреш страницы. А это уже 80 000 RPS/сек. Довольно много.

Ещё были требования к виртуальной выставке с онлайн-стендами партнёров?

Николай: Да, это нужно было сделать довольно быстро и универсально. У нас было до 10 компаний-партнёров на каждую конференцию, и страницы их всех нужно было заверстать за неделю-две. При этом контент у них немного различается по формату. Но был сделан определённый шаблонизатор, собирающий эти страницы на лету, практически без дальнейшего участия по разработке.

Было еще требования по аналитике просмотров в реал-тайме и статистике. Знаю, что мы используем для этого Prometheus, а расскажите подробнее: какие требования мы выполняем по аналитике, и как это реализуется?

Николай: Изначально у нас есть маркетологические требования по сбору для А/В-тестирования и по сбору информации для того, чтобы понять, как правильно клиенту доставлять лучший контент в дальнейшем. Еще есть требования по некой аналитике по партнерским активностям и аналитика, которую вы видите (счетчик посещений). Вся информация собирается в реал-тайме.

Эту информацию мы можем выдавать в агрегированном виде даже спикерам: сколько людей тебя смотрели в определенный момент времени. При этом для соблюдения 152 ФЗ личный кабинет и персональные данные не трекаются никак.

На платформе уже есть и маркетологические инструменты, и наши метрики для измерения пользовательской активности именно в реалтайме (кто смотрел какую секунду доклада), чтобы строить графики посещения докладов. На основе этих данных делаются исследования, которые позволят сделать следующие конференции лучше.

Фрод

У нас есть механизмы антифрода?

Николай: В связи с жёсткими временными рамками с точки зрения бизнеса изначально не ставилась задача сразу же блокировать лишние соединения. Если два пользователя заходили под одним и тем же аккаунтом, они могли посмотреть контент. Но мы знаем, сколько одновременных просмотров было с одного аккаунта. И нескольких особо злостных нарушителей мы забанили.

Владимир: Надо отдать должное, один из забаненных пользователей понял, почему это случилось. Пришёл, извинился и обещал купить билет.

Чтобы это все происходило, вы должны полностью трассировать всех пользователей от входа до выхода, всегда знать что они делают. Как устроена эта система?

Владимир: Я бы хотел рассказать про аналитику и статистику, которую мы потом анализируем для успешности доклада или можем предоставить потом партнерам. Все клиенты присоединены по вебсокет-соединению к определенному кластеру бэкенда. Там стоит Hazelcast. Каждый клиент в каждый период времени отсылает, что он делает и какой трек он смотрит. Дальше эта информация быстрыми Hazelcast-джобами агрегируется и отсылается в обратку всем, кто смотрит эти треки. Мы видим в углу, сколько людей сейчас находятся вместе с нами.

Эта же информация складируется в Mongo и уезжает в наше озеро данных, по которому мы имеем возможность строить более интересный график. Приходит вопрос: сколько уникальных пользователей посмотрели данный доклад? Мы идем в Postgres, там пинги всех людей, которые пришли по id этого доклада. Собрали, агрегировали уникальных, и теперь можем понять.

Николай: Но при этом мы получаем ещё реалтайм-данные с Prometheus. Он натравлен на все Kubernetes-сервисы, на сам Kubernetes. Собирает абсолютно всё, и с Grafana мы можем строить любые графики в реальном времени.

Владимир: С одной стороны, мы это сгружаем для дальнейшей обработки типа OLAP. А для OLTP приложение сгружает все это дело в Prometheus, Grafana и графики даже сходятся!

Тот самый случай, когда графики сходятся.

Динамические изменения

Расскажите, как выкатываются динамические изменения: если доклад отменился за 6 минут до начала, какая цепочка действий? Какой пайплайн срабатывает?

Владимир: Пайплайн очень условный. Есть несколько возможностей. Первая программа формирования расписания сработала и изменила это расписание. Изменённое расписание выгружается в Contentful. После чего бэкенд понимает, что есть изменения по данной конференции в Contentful, берёт и пересобирает. Всё собирается и отсылается по websocket.

Вторая возможность, когда всё происходит в бешеном темпе: редактор руками меняет в Contentful информацию (ссылку на Telegram, презентацию докладчика и т.д.) и срабатывает та же самая логика, что и в первый раз.

Николай: Все происходит без рефреша страницы. Все изменения происходят абсолютно бесшовно для клиента. Также и с переключением докладов. Когда подходит время, меняется доклад и интерфейс.

Владимир: Также и временные отсечки начала докладов в таймлайне. В самом начале ничего нет. А если навести мышку на красную полоску, то в какой-то момент, благодаря режиссеру трансляции, появятся отсечки. Режиссер ставит правильное начало трансляции, бэкенд это изменение схватывает, рассчитывает соответственно расписанию конференции время начала и окончания докладов всего трека, отправляет нашим клиентам, плеер рисует отсечки. Теперь пользователь может спокойно навигироваться в начало и конец доклада. Это было жесткое бизнес-требование, очень удобное и полезное. Ты не тратишь время, чтобы найти настоящее время начала доклада. А когда мы сделаем превью, будет вообще замечательно.

Деплоймент

Я бы хотел спросить про деплоймент. Коля и команда в начале убили много времени, чтобы настроить всю инфраструктуру, в которой у нас всё разворачивается. Расскажи, из чего это всё?

Николай: У нас изначально было требование с технической точки зрения к продукту максимально абстрагироваться от какого-либо вендора. Прийти в AWS делать Terraform-скрипты конкретно AWS-овские, или конкретно яндексовские, или Azure-овские и т.д. не очень подходило. Мы должны были в своё время куда-то съехать.

Первые недели три мы постоянно искали путь, как это лучше сделать. В итоге пришли к тому, что Kubernetes в данном случае это наше всё, потому что позволяет делать автоматически-масштабируемые сервисы, автовыкатку и получить из коробки практически все сервисы. Естественно, надо было обучить все сервисы работе с Kubernetes, Docker, и команде тоже научиться.

У нас два кластера. Тестовый и продовский. Они абсолютно одинаковые с точки зрения железа, настроек. Имплементируем инфраструктуру как код. Все сервисы автоматическим пайплайном раскатываются в три среды из фичи-веток, из мастер-веток, из тестовых, из GitLab. Это максимально интегрировано в GitLab, максимально интегрировано с Elastic, Prometheus.

Мы получаем возможность быстро (для бэкенда в течение 10 минут, для фронтенда в течение 5 минут) выкатить изменения в любую среду со всеми тестами, интеграциями, запуском функциональных тестов, интеграционных тестов на среде, и еще и протестировать нагрузочными тестами на тестовой среде примерно то же самое, что мы хотим получить в продакшене.

Про тесты

Вы почти всё тестируете, тяжело поверить, как вы всё написали. Можете рассказать как по бэкенду по тестам: насколько все покрыто, какие тесты?

Владимир: Написано два типа тестов. Первые компонентные тесты. Тесты уровня подъема всего спрингового приложения и базы в Testcontainers. Это проверка самых высокоуровневых бизнес-сценариев. Я не тестирую функции. Мы тестируем только какие-то крупные штуки. Например, прямо в тесте эмулируется процесс логина пользователя, запрос этим пользователем билетов, куда он может сходить, запрос доступа на просмотр стрима. Очень понятные пользовательские сценарии.

Примерно то же самое реализовано в так называемых интеграционных тестах, которые реально бегут на среде. Фактически, когда очередной деплоймент в прод раскатывается, на проде также бегут настоящие базовые сценарии. Тот же самый логин, запрос билетов, запрос доступа до CloudFront, проверка того, что стрим действительно цепляется с моими разрешениями, проверка режиссерского интерфейса.

На данный момент у меня на борту примерно 70 компонентных тестов и около 40 интеграционных. Покрытие очень близко к 95%. Это по компонентным, по интеграционным поменьше, там столько просто не надо. Учитывая то, что в проекте всякие кодогенерации, это очень хороший показатель. Никакого другого способа сделать то, что мы сделали за три месяца, не было. Потому что если бы мы тестировали ручным образом, отдавая фичи нашей тестировщице, а она бы находила баги и возвращала нам на фиксы, то этот round trip по отлаживанию кода был бы очень долгий, и мы бы не влезли ни в какие сроки.

Николай: Условно, чтобы провести регресс на всей платформе при изменении какой-то функции, нужно два дня сидеть и тыкать везде.

Владимир: Поэтому большой успех, что, когда я эстимирую фичу, говорю, что мне нужно 4 дня на две простые ручки и 1 websocket, Коля разрешает. Он уже привык, что в эти 4 дня заложены 2 типа тестов, и потом, скорее всего, это будет работать.

Николай: У меня тоже написано 140 тестов: компонентных + функциональных, которые делают то же самое. Все те же самые сценарии тестируются и на продакшене, на тесте и на деве. Также недавно у нас появились функциональные базовые UI-ные тесты. Так мы покрываем самые базовые функциональности, которые могут развалиться.

Владимир: Конечно же, стоит рассказать про нагрузочные тесты. Нужно было проверить платформу под нагрузкой, приближенной к реальной, чтобы понять, как оно все, что происходит с Rabbit, что происходит с JVM-ками, сколько реально надо памяти.

Я не знаю точно, тестируем ли мы что-нибудь на стороне стримов, но я помню, что были проблемы с транскодерами, когда мы делали митапы. Тестировали ли мы стримы?

Артём: Тестили итеративно. Организовывая митапы. В процессе организации митапов было примерно 2300 JIRA-тикетов. Это просто шаблонные вещи, которые люди делали, чтобы сделать митапы. Мы брали части платформы на отдельную страницу для митапов, которой занимался Кирилл Толкачев (tolkkv).

Честно говоря, больших проблем не было. Буквально пару раз ловили баги по кэшированию на CloudFront, решили довольно быстро просто перенастроили политики. Багов было значительно больше в людях, в системах стриминга на площадке.

Во время конференций пришлось писать еще несколько экспортёров для того чтобы покрыть больше оборудования и сервисов. Местами приходилось делать свои велосипеды только ради метрик. Мир AV (аудио-видео) железа не очень радужный у тебя есть какое-то API оборудования, на которое ты просто не можешь повлиять. И далеко не факт, что получится забрать ту информацию, которая тебе нужна. Вендоры железа реально медленные, и от них почти невозможно добиться желаемого. Итого более 100 железок, отдают они не то, что нужно, а ты пишешь странные и избыточные экспортёры, благодаря которым можно хоть как-то дебажить систему.

Оборудование

Я помню, как до начала конференций мы частично дозакупали оборудование.

Артём: Закупали компьютеры, ноутбуки, батарейные блоки. На данный момент мы можем жить без электричества 40 минут. В июне в Питере были сильные грозы так что такое отключение у нас было. При этом к нам приходят несколько провайдеров оптическими линками из разных точек. Это действительно 40 минут даунтайма здания, при которых у нас будет гореть свет, работать звук, камеры и т.д.

С интернетом у нас похожая история. В офисе, где находятся наши студии, мы между этажами протащили лютую сеть.

Артём: У нас 20 ГБит оптики между этажами. Дальше по этажам где-то оптика, где-то нет, но все-таки меньше, чем гигабитных, каналов нет мы гоняем по ним между треками конференции видео. Вообще очень удобно работать на своей инфраструктуре, на офлайн-конференциях на площадках так редко получается делать.

Еще не работая в JUG Ru Group, я видел, как за ночь разворачиваются аппаратные на офлайн-конференциях, где стоит большой монитор со всеми метриками, которые вы строите в Grafana. Сейчас также есть помещение-штаб, в котором сидит команда разработки, которая во время конференции чинит какие-то баги и разрабатывает фичи. При этом есть система мониторинга, которая выводится на большой экран. Артём, Коля и другие ребята сидят и смотрят, чтобы это все не падало и красиво работало.

Курьёзы и проблемы

Вы хорошо рассказали о том, что у нас есть стриминг с Амазоном, есть плеер с вебом, все написано на разных языках программирования, обеспечивается отказоустойчивость и другие бизнес-требования, в том числе есть личный кабинет, который поддерживается для юридических и физических лиц, и мы можем интегрироваться с кем-то по OAuth 2.0, есть антифрод, блокировка пользователя. Мы можем динамически выкатывать изменения, потому что сделали это хорошо, и при этом это все тестируется.

Мне интересно узнать, какие были курьёзы с тем, чтобы что-то запустилось. Были ли странные ситуации, когда вы разрабатывали бэкенд, фронтенд, получалась какая-то дичь и вы не понимали, что с этим делать?

Владимир: Мне кажется, такое было только последние три месяца. Каждый день. Как вы можете увидеть, все мои волосы вырваны.

Владимир Красильщик после 3 месяцев, когда получалась какая-то дичь и никто не понимал, что с этим делать

Каждый день что-то такое было, когда был такой момент, когда ты берешь и рвёшь на себе волосы, либо понимаешь, что больше никого нет, и только ты можешь это сделать. Первым большим мероприятием у нас был TechTrain. 6 июня в 2 часа ночи у нас еще не было раскатано продакшен-окружение, его раскатывал Коля. И не работал личный кабинет, как сервер авторизации по OAuth2.0. Мы превратили его в провайдера OAuth2.0, чтобы к нему подключить платформу. Я работал, наверное, уже 18 час подряд, смотрел в компьютер и ничего не видел, не понимал, почему он не работает, и удалённо Коля смотрел в мой код, искал баг в конфигурации Spring, нашел, и ЛК заработал, и в продакшене тоже.

Николай: И за час до TechTrain релиз состоялся.

Здесь сложились очень многие звёзды. Нам крайне повезло, потому что у нас сложилась просто супер-команда, и все задрайвились идеей сделать онлайн. Все эти три месяца нас драйвило то, что мы делали YouTube. Я не позволял себе рвать волосы, а говорил всем, что всё получится, потому что на самом деле всё давно просчитано.

Про производительность

Можете ли рассказать, сколько было максимально людей на сайте на одном треке? Были ли проблемы с производительностью?

Николай: Проблем с производительностью, как мы уже говорили, не было. Максимальное количество людей, которые были на одном докладе, 1300 человек, это на Heisenbug.

Были ли проблемы с локальным просмотром? И возможно ли техническое описание со схемами того, как это все устроено?

Николай: Сделаем об этом позже статью.

Локально можно отдебажить даже стримы. Как только начались конференции, это стало даже проще, потому что появились продакшен-стримы, которые мы можем смотреть постоянно.

Владимир: Как я понимаю, фронтенд-девелоперы локально работали с моками, а потом, поскольку время выкатки на дев во фронте тоже небольшое (5 минут), посмотреть, что там с сертификатами, проблем никаких нет.

Все тестируется, дебажится, даже локально. Значит, напишем статью со всеми техническими особенностями, покажем, расскажем все со схемами, как было.

Владимир: Сможете взять и повторить.

За 3 месяца.

Итог

Всё описанное вместе звучит круто с учётом того, что это сделано маленькой командой за три месяца.

Николай: Большая команда этого бы не сделала. А вот маленькая группа людей, которые довольно плотно и хорошо друг с другом общаются и могут договориться, могла бы. У них нет каких-то противоречий, архитектура была придумана за два дня, была финализирована и фактически не поменялась. Есть очень жесткая фасилитация поступающих бизнес-требований с точки зрения наваливания фич-реквестов и изменений.

Что оказалось в вашем списке дальнейших задач, когда летние конференции уже состоялись?

Николай: Например, титры. Бегущие строки на видео, всплывашки в некоторых местах видео в зависимости от показа контента. Например, спикер хочет задать вопрос в аудиторию, и на экране всплывает голосовалка, которая обратно в бэк по результатам голосования уходит самому спикеру. Какая-то социальная активность в виде лайков, сердечек, оценок доклада во время самой презентации, чтобы можно было, не отвлекаясь потом на формы обратной связи, заполнить фидбэк в нужную секунду. Первоначально вот так.

А ещё добавление всей платформе, кроме стримингового и конференционного, также постконференционное состояние. Это плейлисты (в том числе составленные пользователями), возможно, контент с других прошедших конференций, интегрированные, промаркированные, доступные для пользователя, ну и доступные для просмотра на нашем сайте (live.jugru.org).

Ребята, спасибо большое за ответы!

Если среди читателей есть те, кто был на наших летних конференциях поделитесь вашими впечатлениями от плеера и трансляции. Что было удобно, что раздражало, что хочется увидеть в будущем?

Если платформа заинтересовала и захотелось увидеть её в бою мы снова используем её на наших осенне-зимних конференциях. Их целый ряд, так что почти наверняка есть подходящая для вас.

Всем привет, в этом руководстве рассмотрим создание скриптов для OBS на языке Lua.

Скриптинг в OBS доступен начиная с версии 21, на данный момент новейшая 26.0.0-rc3 версия доступна для тестирования.Обновление включает в себя виртуальную веб камеру (пока что только на Windows), улучшенный UI, возможность скриншота любого источника( КДПВ была сделана с помощью этой функции).

Описание глобальных функций, API, настроек

Добавить скрипт можно через меню -> Инструменты -> Скрипты -> значок "плюс".
Скрипты могут быть добавлены, перезагружены, удалены в режиме реального времени.

Сходства и различия c С-API

Сходства: почти полный доступ к API, СБОЙ или УТЕЧКА ПАМЯТИ с неправильно написанным скриптом.

Различия: некоторые функции(с двойными указателями) недоступны, некоторые заменены на другие.

У каждого скрипта своё пространство имён, убедиться в этом можно открыв текущую коллекцию сцен "~/obs-studio/basic/scenes".

Настройки settings представляют собой JSON строку, они могут быть созданы/загружены/сохранены с помощью JSON строк или файлов.

Описание функций:

• obslua модуль для доступа к функциям OBS
• script_description() описание скрипта, поддерживает примитивный HTML
• script_properties() пользовательский интерфейс
• script_defaults(settings) устанавливает настройки по умолчанию
• script_update(settings) вызывается каждый раз когда пользователь изменил настройки через пользовательский интерфейс
• script_load(settings) загружает настройки при первом запуске
• script_unload() вызывается при закрытии скрипта
• script_save(settings) используется в основном для сохранения горячих клавиш, настройки c пользовательского интерфейса сохраняются автоматически
• script_tick(seconds) вызывается каждый кадр, аргумент seconds получает значение потраченных секунд с предыдущего кадра
• script_path() возвращает абсолютный путь к папке скрипта
• timer_add(callback,milliseconds) вызов функции периодично
• timer_remove(callback) удаление функции с таймера, также есть вариант использовать remove_current_callback() внутри функции которая вызывается периодично

Пример скрипта

Скрипт: Движение по линии с использованием кнопок и таймера.

local obs = obslualocal selected_sourcepos = obs.vec2()switch = falsecounter = 0

Короткая запись модуля, local var инициализация значения как nil, pos структура предоставляемая OBS для перемещения источников на сцене.

function script_properties()  local props = obs.obs_properties_create()  obs.obs_properties_add_button(props, "button1", "Вкл/Выкл",on_off)  obs.obs_properties_add_button(props, "button2", "Добавить источник",add_source)  obs.obs_properties_add_button(props, "button3", "Подвинуть источник на +10,0",move_button)  local p = obs.obs_properties_add_list(props, "selected_source", "Выберите источник", obs.OBS_COMBO_TYPE_EDITABLE, obs.OBS_COMBO_FORMAT_STRING)  local sources = obs.obs_enum_sources()  if sources ~= nil then    for _, source in ipairs(sources) do      source_id = obs.obs_source_get_unversioned_id(source)      if source_id == "color_source" then        local name = obs.obs_source_get_name(source)        obs.obs_property_list_add_string(p, name, name)      end    end  end  obs.source_list_release(sources)  return propsend

Добавляем пользовательский интерфейс. obs.obs_properties_add_button(props, "имя", "Описание",функция), local p = obs.obs_properties_add_list выпадающие меню с выбором источника, source_id = obs.obs_source_get_unversioned_id(source) получение имени источника при этом игнорируя его версию, obs.source_list_release(sources) освобождение памяти

function script_update(settings)  selected_source = obs.obs_data_get_string(settings,"selected_source")end

Обновление selected_source каждый раз когда настройки (выпадающее меню в этом случае) изменены.

function add_source()  current_scene = obs.obs_frontend_get_current_scene()  scene = obs.obs_scene_from_source(current_scene)  settings = obs.obs_data_create()  counter = counter + 1  green = 0xff00ff00  hotkey_data = nil  obs.obs_data_set_int(settings, "width",200)  obs.obs_data_set_int(settings, "height",200)  obs.obs_data_set_int(settings, "color",green)  source = obs.obs_source_create("color_source", "ист#" .. counter, settings, hotkey_data)  obs.obs_scene_add(scene, source)  obs.obs_scene_release(scene)  obs.obs_data_release(settings)  obs.obs_source_release(source)end

Выбор сцены и создание настроек для источника, добавление на сцену, освобождение памяти.

function move_source_on_scene()  current_scene = obs.obs_frontend_get_current_scene()  scene = obs.obs_scene_from_source(current_scene)  scene_item = obs.obs_scene_find_source(scene, selected_source)  if scene_item then    dx, dy = 10, 0    obs.obs_sceneitem_get_pos( scene_item, pos) -- обновить позицию если источник был перемещён мышкой    pos.x = pos.x + dx    pos.y = pos.y + dy    obs.obs_sceneitem_set_pos(scene_item, pos)   end  obs.obs_scene_release(scene)end

Функция перемещения источника в рамках сцены.

function move_button(props,p)  move_source_on_scene()end

Кнопка перемещения источника и 2 необходимых аргумента.

function on_off()  if switch then     obs.timer_add(move_source_on_scene,50)  else    obs.timer_remove(move_source_on_scene)  end  switch = not switchend

Кнопка переключатель и таймер периодического запуска функции в миллисекундах.

local obs = obslualocal selected_sourcepos = obs.vec2()switch = falsecounter = 0function on_off()  if switch then     obs.timer_add(move_source_on_scene,50)  else    obs.timer_remove(move_source_on_scene)  end  switch = not switchendfunction add_source()  current_scene = obs.obs_frontend_get_current_scene()  scene = obs.obs_scene_from_source(current_scene)  settings = obs.obs_data_create()  counter = counter + 1  green = 0xff00ff00  hotkey_data = nil  obs.obs_data_set_int(settings, "width",200)  obs.obs_data_set_int(settings, "height",200)  obs.obs_data_set_int(settings, "color",green)  source = obs.obs_source_create("color_source", "ист#" .. counter, settings, hotkey_data)  obs.obs_scene_add(scene, source)  obs.obs_scene_release(scene)  obs.obs_data_release(settings)  obs.obs_source_release(source)endfunction move_button(props,p)  move_source_on_scene()endfunction move_source_on_scene()  current_scene = obs.obs_frontend_get_current_scene()  scene = obs.obs_scene_from_source(current_scene)  scene_item = obs.obs_scene_find_source(scene, selected_source)  if scene_item then    dx, dy = 10, 0    obs.obs_sceneitem_get_pos( scene_item, pos) -- обновить позицию если источник был перемещён мышкой    pos.x = pos.x + dx    pos.y = pos.y + dy    obs.obs_sceneitem_set_pos(scene_item, pos)   end  obs.obs_scene_release(scene)endfunction script_properties()  local props = obs.obs_properties_create()  obs.obs_properties_add_button(props, "button1", "Вкл/Выкл",on_off)  obs.obs_properties_add_button(props, "button2", "Добавить источник",add_source)  obs.obs_properties_add_button(props, "button3", "Cдвинуть источник на +10,0",move_button)  local p = obs.obs_properties_add_list(props, "selected_source", "Выберите источник", obs.OBS_COMBO_TYPE_EDITABLE, obs.OBS_COMBO_FORMAT_STRING)  local sources = obs.obs_enum_sources()  if sources ~= nil then    for _, source in ipairs(sources) do      source_id = obs.obs_source_get_unversioned_id(source)      if source_id == "color_source" then        local name = obs.obs_source_get_name(source)        obs.obs_property_list_add_string(p, name, name)      end    end  end  obs.source_list_release(sources)  return propsendfunction script_update(settings)  selected_source = obs.obs_data_get_string(settings,"selected_source")end

Пример горячих клавиш

Скрипт: Создание постоянных и изменяющихся горячих клавиш.

Создание изменяющихся горячих клавиш, в том смысле что их можно поменять в настройках OBS.

hotkeys = {  htk_stop = "Стоп",  htk_start = "Старт",}hk = {}function hotkey_mapping(hotkey)  if hotkey == "htk_stop" then    print('Стоп')  elseif hotkey == "htk_start" then    print('Старт')  endend

Словарь с клавишами и функция типа "switch"

function script_load(settings)  for k, v in pairs(hotkeys) do     hk[k] = obs.obs_hotkey_register_frontend(k, v, function(pressed)      if pressed then         hotkey_mapping(k)      end     end)    a = obs.obs_data_get_array(settings, k)    obs.obs_hotkey_load(hk[k], a)    obs.obs_data_array_release(a)  end  ...function script_save(settings)  for k, v in pairs(hotkeys) do    a = obs.obs_hotkey_save(hk[k])    obs.obs_data_set_array(settings, k, a)    obs.obs_data_array_release(a)  endend

Сохранение/загрузка изменяющихся горячих клавиш.

function htk_1_cb(pressed)   if pressed then    print('1')  endendfunction htk_2_cb(pressed)   if pressed then    print('2 активно')  else    print('2 не активно')  endendkey_1 = '{"htk_1": [ { "key": "OBS_KEY_1" } ],'key_2 = '"htk_2": [ { "key": "OBS_KEY_2" } ]}'json_s = key_1 .. key_2default_hotkeys = {  {id='htk_1',des='Кнопка 1 ',callback=htk_1_cb},  {id='htk_2',des='Кнопка 2 ',callback=htk_2_cb},}

Создание постоянных клавиш, их можно поменять в настройках, но при перезапуске OBS они примут значения по умолчанию. В данном случае кнопку 1 и 2.

function script_load(settings)  ...  s = obs.obs_data_create_from_json(json_s)  for _,v in pairs(default_hotkeys) do     a = obs.obs_data_get_array(s,v.id)    h = obs.obs_hotkey_register_frontend(v.id,v.des,v.callback)    obs.obs_hotkey_load(h,a)    obs.obs_data_array_release(a)  end  obs.obs_data_release(s)end

local obs = obsluahotkeys = {  htk_stop = "Стоп",  htk_start = "Старт",}hk = {}function hotkey_mapping(hotkey)  if hotkey == "htk_stop" then    print('Стоп')  elseif hotkey == "htk_start" then    print('Старт')  endendfunction htk_1_cb(pressed)   if pressed then    print('1')  endendfunction htk_2_cb(pressed)   if pressed then    print('2 активно')  else    print('2 не активно')  endendkey_1 = '{"htk_1": [ { "key": "OBS_KEY_1" } ],'key_2 = '"htk_2": [ { "key": "OBS_KEY_2" } ]}'json_s = key_1 .. key_2default_hotkeys = {  {id='htk_1',des='Кнопка 1 ',callback=htk_1_cb},  {id='htk_2',des='Кнопка 2 ',callback=htk_2_cb},}function script_load(settings)  for k, v in pairs(hotkeys) do     hk[k] = obs.obs_hotkey_register_frontend(k, v, function(pressed)      if pressed then         hotkey_mapping(k)      end     end)    a = obs.obs_data_get_array(settings, k)    obs.obs_hotkey_load(hk[k], a)    obs.obs_data_array_release(a)  end  s = obs.obs_data_create_from_json(json_s)  for _,v in pairs(default_hotkeys) do     a = obs.obs_data_get_array(s,v.id)    h = obs.obs_hotkey_register_frontend(v.id,v.des,v.callback)    obs.obs_hotkey_load(h,a)    obs.obs_data_array_release(a)  end  obs.obs_data_release(s)endfunction script_save(settings)  for k, v in pairs(hotkeys) do    a = obs.obs_hotkey_save(hk[k])    obs.obs_data_set_array(settings, k, a)    obs.obs_data_array_release(a)  endend

Задачи

Задача на движение по кругу:
На основе скрипта движение по линии, создайте скрипт с движением вокруг часовой/против.

Задача на использование кнопок клавиатуры:
На основе скрипта с горячими клавишами, создайте скрипт с переключателем вкл/выкл,
доп кнопкой через JSON, доп кнопкой с комбинацией клавиш через JSON.

Ссылки

• Книга 1-го издания Lua
• Задания тесты Lua
• Модули доступные в LuaJIT
• Документация по скриптингу OBS
• Заметки, краткое описание OBS API и модуль obspython
• Форумный раздел со скриптами OBS
• Дискорд комната #scripting
• Гитхаб гист obslua
• Гитхаб поиск obslua
• Баг API где в аргументах указатель-указатель

Всем привет, в этой части руководства рассмотрим:
фильтры, сцены, предметы сцен, Frontend API, создание функциональных фильтров и прочее
С первой частью можно ознакомиться по этой ссылке.

Краткая справка для этой части

• Источник Источники используются для рендера аудио/видео, например: захват камеры, игры, звука. С помощью источников можно создавать фильтры, переходы

  
  

• Фильтр Источник который дополняет другие источники

  
  

• Сцены Коллекция источников, сцена является источником ( сцену можно добавить как источник в другой сцене)

  
  

• Предмет сцены конкретный источник в сцене, его можно: перемещать, увеличивать/уменьшать, переворачивать, менять состояние выкл/вкл и.т.д

  
  

• Frontend API Набор функций который предоставляет OBS Studio, например:

  
  
  • подписка на событие о переключении сцен
  • запрос статуса о том, идёт ли стрим/запись
  • вкл/выкл стрим/запись
  • переключение сцен
  
  

Фильтры

Типы фильтров так же как и источников, можно узнать через функцию obs_source_get_unversioned_id

В английском варианте: ссылка

Скрипт: изменение параметра прозрачности у фильтра на случайную величину от 1 до 100.

Чтобы узнать название параметра "прозрачность" необходимо добавить фильтр с прозрачностью на какой-нибудь источник, изменить этот параметр. Далее открыть файл коллекции сцен, путь к директории можно узнать через меню OBS:
Справка > Файлы журнала > Показать файлы журнала
далее с этой директории поднимаемся выше, и получаем путь ~/basic>scenes>название_сцены.json
В этом файле ищем color_filter или color_key_filter (оба фильтра могут изменить прозрачность источника).
В строке settings видим что прозрачность записана как opacity.
Ещё один способ узнать название параметра, прочитать исходный код фильтра ссылка

Находим источник по имени

function add_filter_to_source(random_n)  source = obs.obs_get_source_by_name(source_name)

Создаём настройки с изменением параметра opacity на случайное число

settings = obs.obs_data_create()obs.obs_data_set_int(settings, "opacity",random_n)

Проверяем существует ли уже фильтр на источнике, если нет добавляем

_color_filter = obs.obs_source_get_filter_by_name(source,"opacity_random")if _color_filter == nil then -- if not exists  _color_filter = obs.obs_source_create_private( "color_filter", "opacity_random", settings)  obs.obs_source_filter_add(source, _color_filter)end

Обновляем и освобождаем память

  obs.obs_source_update(_color_filter,settings)  obs.obs_source_release(source)  obs.obs_data_release(settings)  obs.obs_source_release(_color_filter)end

Привязка к горячей клавише

function htk_1_cb(pressed)   if pressed then    n = math.random(1,100)    add_filter_to_source(n)  endend

local obs = obsluasource_name = ''function htk_1_cb(pressed)   if pressed then    n = math.random(1,100)    add_filter_to_source(n)  endendfunction add_filter_to_source(random_n)  source = obs.obs_get_source_by_name(source_name)  settings = obs.obs_data_create()  obs.obs_data_set_int(settings, "opacity",random_n)  _color_filter = obs.obs_source_get_filter_by_name(source,"opacity_random")  if _color_filter == nil then -- if not exists    _color_filter = obs.obs_source_create_private( "color_filter", "opacity_random", settings)    obs.obs_source_filter_add(source, _color_filter)  end  obs.obs_source_update(_color_filter,settings)  obs.obs_source_release(source)  obs.obs_data_release(settings)  obs.obs_source_release(_color_filter)endfunction script_properties()  -- source https://raw.githubusercontent.com/insin/obs-bounce/master/bounce.lua  local props = obs.obs_properties_create()  local source = obs.obs_properties_add_list(    props,    'source',    'Source:',    obs.OBS_COMBO_TYPE_EDITABLE,    obs.OBS_COMBO_FORMAT_STRING)  for _, name in ipairs(get_source_names()) do    obs.obs_property_list_add_string(source, name, name)  end  return propsendfunction script_update(settings)  source_name = obs.obs_data_get_string(settings, 'source')end--- get a list of source names, sorted alphabeticallyfunction get_source_names()  local sources = obs.obs_enum_sources()  local source_names = {}  if sources then    for _, source in ipairs(sources) do      -- exclude Desktop Audio and Mic/Aux by their capabilities      local capability_flags = obs.obs_source_get_output_flags(source)      if bit.band(capability_flags, obs.OBS_SOURCE_DO_NOT_SELF_MONITOR) == 0 and        capability_flags ~= bit.bor(obs.OBS_SOURCE_AUDIO, obs.OBS_SOURCE_DO_NOT_DUPLICATE) then        table.insert(source_names, obs.obs_source_get_name(source))      end    end  end  obs.source_list_release(sources)  table.sort(source_names, function(a, b)    return string.lower(a) < string.lower(b)  end)  return source_namesendkey_1 = '{"htk_1": [ { "key": "OBS_KEY_1" } ]}'json_s = key_1default_hotkeys = {  {id='htk_1',des='Кнопка 1 ',callback=htk_1_cb},}function script_load(settings)  s = obs.obs_data_create_from_json(json_s)  for _,v in pairs(default_hotkeys) do     a = obs.obs_data_get_array(s,v.id)    h = obs.obs_hotkey_register_frontend(v.id,v.des,v.callback)    obs.obs_hotkey_load(h,a)    obs.obs_data_array_release(a)  end  obs.obs_data_release(s)end

Стоит упомянуть также о функции obs_source_enum_filters с её помощью можно получить
список всех фильтров у конкретного источника, кстати эта функция не работает в obspython,
но об этом чуть позже.

function check()  source = obs.obs_get_source_by_name(source_name)  result = obs.obs_source_enum_filters(source)  for k,v in pairs(result) do     name = obs.obs_source_get_name(v)    print('name'.. name)  end  obs.source_list_release(result)  obs.obs_source_release(source)end

Эвенты и состояние

Скрипт: звуковое оповещение о том что сцена изменена, с использованием .mp3 файла.
На основе этого скрипта

Создадим функцию для проигрывания звука при смене сцен.

function on_event(event)   if event == obs.OBS_FRONTEND_EVENT_SCENE_CHANGED    then obs_play_sound_release_source()  end end

Добавим источник медиа, установим настройки: файл alert.mp3 относителен директории нахождения
скрипта, obs_source_set_monitoring_type выставляет прослушивание аудио.

function play_sound()  mediaSource = obs.obs_source_create_private("ffmpeg_source", "Global Media Source", nil)  local s = obs.obs_data_create()  obs.obs_data_set_string(s, "local_file",script_path() .. "alert.mp3")  obs.obs_source_update(mediaSource,s)  obs.obs_source_set_monitoring_type(mediaSource,obs.OBS_MONITORING_TYPE_MONITOR_AND_OUTPUT)  obs.obs_data_release(s)  obs.obs_set_output_source(outputIndex, mediaSource)  return mediaSourceendfunction obs_play_sound_release_source()  r = play_sound()  obs.obs_source_release(r)end

local obs = obsluamediaSource = nil -- Null pointeroutputIndex = 63 -- Last indexfunction play_sound()  mediaSource = obs.obs_source_create_private("ffmpeg_source", "Global Media Source", nil)  local s = obs.obs_data_create()  obs.obs_data_set_string(s, "local_file",script_path() .. "alert.mp3")  obs.obs_source_update(mediaSource,s)  obs.obs_source_set_monitoring_type(mediaSource,obs.OBS_MONITORING_TYPE_MONITOR_AND_OUTPUT)  obs.obs_data_release(s)  obs.obs_set_output_source(outputIndex, mediaSource)  return mediaSourceendfunction obs_play_sound_release_source()  r = play_sound()  obs.obs_source_release(r)endfunction on_event(event)   if event == obs.OBS_FRONTEND_EVENT_SCENE_CHANGED    then obs_play_sound_release_source()  end endfunction script_load(settings)  obs.obs_frontend_add_event_callback(on_event)endfunction script_unload()  obs.obs_set_output_source(outputIndex, nil)end

Время и файлы

Запись в файл, "a" создаст(если нет) файл и добавит "content", а "w" перезапишет .

io.output(io.open(script_path() .. "out.txt","a"))io.write("content")io.close()

print(os.date("%c"))-- День недели Месяц Время Год

• чтение с файла SO
• io
• os.time

Сцены и предметы сцен

• obs_sceneitem_get_source предметы сцен в источник
• obs_scene_from_source преобразование сцены в источник
• obs_scene_find_source преобразование источника в предмет сцены
• obs_frontend_get_scenes получение всех сцен, освобождать с source_list_release
• obs_frontend_get_current_scene получение текущей сцены
• obs_scene_enum_items список всех предметов в сцене, освобождать с sceneitem_list_release

Скрипт: включение и выключение предмета сцены(источника на сцене).

Получение всех сцен и предметов в них

function toggle_source()  scenes = obs.obs_frontend_get_scenes()  for _,scene in pairs(scenes) do    scene_source = obs.obs_scene_from_source(scene)    items = obs.obs_scene_enum_items(scene_source)...

Поиск конкретного источника и его включение или выключение, source_name и boolean определены глобально.

...for _,scene_item in pairs(items) do  _source = obs.obs_sceneitem_get_source(scene_item)  _name = obs.obs_source_get_name(_source)  if _name == source_name then    boolean = not boolean     obs.obs_sceneitem_set_visible(scene_item, boolean)  endend...

local obs = obsluasource_name = ''boolean = truefunction htk_1_cb(pressed)   if pressed then    toggle_source()  endendfunction toggle_source()  scenes = obs.obs_frontend_get_scenes()  for _,scene in pairs(scenes) do    scene_source = obs.obs_scene_from_source(scene)    items = obs.obs_scene_enum_items(scene_source)    for _,scene_item in pairs(items) do      _source = obs.obs_sceneitem_get_source(scene_item)      _name = obs.obs_source_get_name(_source)      if _name == source_name then        boolean = not boolean         obs.obs_sceneitem_set_visible(scene_item, boolean)      end    end    obs.sceneitem_list_release(items)  end  obs.source_list_release(scenes)endfunction script_properties()  -- source https://raw.githubusercontent.com/insin/obs-bounce/master/bounce.lua  local props = obs.obs_properties_create()  local source = obs.obs_properties_add_list(    props,    'source',    'Source:',    obs.OBS_COMBO_TYPE_EDITABLE,    obs.OBS_COMBO_FORMAT_STRING)  for _, name in ipairs(get_source_names()) do    obs.obs_property_list_add_string(source, name, name)  end  obs.obs_property_set_long_description(source,"?" )  return propsendfunction script_update(settings)  source_name = obs.obs_data_get_string(settings, 'source')end--- get a list of source names, sorted alphabeticallyfunction get_source_names()  local sources = obs.obs_enum_sources()  local source_names = {}  if sources then    for _, source in ipairs(sources) do      -- exclude Desktop Audio and Mic/Aux by their capabilities      local capability_flags = obs.obs_source_get_output_flags(source)      if bit.band(capability_flags, obs.OBS_SOURCE_DO_NOT_SELF_MONITOR) == 0 and        capability_flags ~= bit.bor(obs.OBS_SOURCE_AUDIO, obs.OBS_SOURCE_DO_NOT_DUPLICATE) then        table.insert(source_names, obs.obs_source_get_name(source))      end    end  end  obs.source_list_release(sources)  table.sort(source_names, function(a, b)    return string.lower(a) < string.lower(b)  end)  return source_namesendkey_1 = '{"htk_1": [ { "key": "OBS_KEY_1" } ]}'json_s = key_1default_hotkeys = {  {id='htk_1',des='Кнопка 1 ',callback=htk_1_cb},}function script_load(settings)  s = obs.obs_data_create_from_json(json_s)  for _,v in pairs(default_hotkeys) do     a = obs.obs_data_get_array(s,v.id)    h = obs.obs_hotkey_register_frontend(v.id,v.des,v.callback)    obs.obs_hotkey_load(h,a)    obs.obs_data_array_release(a)  end  obs.obs_data_release(s)end

Регистрация фильтров

В obslua доступна функция obs_register_source, с её помощью можно зарегистрировать
источник( переходы и фильтры это источники). Для этого понадобится создать таблицу источника
Регистрация фильтров удобна тем, что позволяет закрепить функциональность скрипта за
определенным источником. Поддерживает горячие клавиши, интерфейс, таймеры.

Скрипт: закрепление горячих клавиш на фильтре, и полный доступ к источнику.

Импорт библиотеки, и определение типа как источник-фильтр.

local obs = obslualocal bit = require("bit")local info = {} -- obs_source_info https://obsproject.com/docs/reference-sources.htmlinfo.id = "uniq_filter_id"info.type = obs.OBS_SOURCE_TYPE_FILTERinfo.output_flags = bit.bor(obs.OBS_SOURCE_VIDEO)info.get_name = function() return 'default filter name' end

Инициализация фильтра, будет вызываться при запуске программы или при добавлении к источнику

info.create = function(settings,source)   local filter = {}  filter.context = source

Начальная регистрация горячих клавиш, принадлежащих конкретному фильтру.

filter.hotkeys = {  htk_stop = "[stop] ",  htk_restart = "[start] ",}filter.hotkey_mapping = function(hotkey,data)  if hotkey == "htk_stop" then    print('stop '.. data.srsn .. " : " .. data.filn)  elseif hotkey == "htk_restart" then    print('restart ' .. data.srsn .. " : " .. data.filn)  endendfilter.hk = {}for k,v in pairs(filter.hotkeys) do   filter.hk[k] = obs.OBS_INVALID_HOTKEY_IDend

Создание функции которая запустится не сразу ( это необходимо т.к фильтр ещё не создан)
Он будет создан после return

filter._reg_htk = function()    info.reg_htk(filter,settings)  end  obs.timer_add(filter._reg_htk,100) -- callback to register hotkeys, one time only

Завершающая регистрация горячих клавиш,obs_filter_get_parent источник который фильтруется
к которому прикреплён фильтр этого типа. Удаление таймера.

info.reg_htk = function(filter,settings) -- register hotkeys after 100 ms since filter was created  local target = obs.obs_filter_get_parent(filter.context)  local srsn = obs.obs_source_get_name(target)   local filn =  obs.obs_source_get_name(filter.context)  local data = {srsn = srsn, filn = filn}   for k, v in pairs(filter.hotkeys) do     filter.hk[k] = obs.obs_hotkey_register_frontend(k, v .. srsn .. " : " .. filn, function(pressed)    if pressed then filter.hotkey_mapping(k,data) end end)    local a = obs.obs_data_get_array(settings, k)    obs.obs_hotkey_load(filter.hk[k], a)    obs.obs_data_array_release(a)  end  obs.remove_current_callback()end

Необходимый код для пропуска фильтрации, без него при добавлении фильтра источник "выключится"

info.video_render = function(filter, effect)   -- called every frame  local target = obs.obs_filter_get_parent(filter.context)  if target ~= nil then    filter.width = obs.obs_source_get_base_width(target)    filter.height = obs.obs_source_get_base_height(target)  end  obs.obs_source_skip_video_filter(filter.context) endinfo.get_width = function(filter)  return filter.widthendinfo.get_height = function(filter)  return filter.heightend

Функция .save вызывается при сохранении настроек, т.е можно переназначить горячие клавиши.
obs.obs_register_source(info) регистрация фильтра, теперь его видно при нажатии ПКМ

info.save = function(filter,settings)  for k, v in pairs(filter.hotkeys) do    local a = obs.obs_hotkey_save(filter.hk[k])    obs.obs_data_set_array(settings, k, a)    obs.obs_data_array_release(a)  endendobs.obs_register_source(info)

info.load также как и script_load, вызывается при запуске программы, но в данном
случае дублирует функциональность и требует перезапуска. .update, .get_properties
функции аналогичные script_update, script_properties.

local obs = obslualocal bit = require("bit")local info = {} -- obs_source_info https://obsproject.com/docs/reference-sources.htmlinfo.id = "uniq_filter_id"info.type = obs.OBS_SOURCE_TYPE_FILTERinfo.output_flags = bit.bor(obs.OBS_SOURCE_VIDEO)info.get_name = function() return 'default filter name' endinfo.create = function(settings,source)   local filter = {}  filter.context = source  filter.hotkeys = {    htk_stop = "[stop] ",    htk_restart = "[start] ",  }  filter.hotkey_mapping = function(hotkey,data)    if hotkey == "htk_stop" then      print('stop '.. data.srsn .. " : " .. data.filn)    elseif hotkey == "htk_restart" then      print('restart ' .. data.srsn .. " : " .. data.filn)    end  end  filter.hk = {}  for k,v in pairs(filter.hotkeys) do     filter.hk[k] = obs.OBS_INVALID_HOTKEY_ID  end  filter._reg_htk = function()    info.reg_htk(filter,settings)  end  obs.timer_add(filter._reg_htk,100) -- callback to register hotkeys, one time only  return filterendinfo.reg_htk = function(filter,settings) -- register hotkeys after 100 ms since filter was created  local target = obs.obs_filter_get_parent(filter.context)  local srsn = obs.obs_source_get_name(target)   local filn =  obs.obs_source_get_name(filter.context)  local data = {srsn = srsn, filn = filn}   for k, v in pairs(filter.hotkeys) do     filter.hk[k] = obs.obs_hotkey_register_frontend(k, v .. srsn .. " : " .. filn, function(pressed)    if pressed then filter.hotkey_mapping(k,data) end end)    local a = obs.obs_data_get_array(settings, k)    obs.obs_hotkey_load(filter.hk[k], a)    obs.obs_data_array_release(a)  end  obs.remove_current_callback()endinfo.video_render = function(filter, effect)   -- called every frame  local target = obs.obs_filter_get_parent(filter.context)  if target ~= nil then    filter.width = obs.obs_source_get_base_width(target)    filter.height = obs.obs_source_get_base_height(target)  end  obs.obs_source_skip_video_filter(filter.context) endinfo.get_width = function(filter)  return filter.widthendinfo.get_height = function(filter)  return filter.heightend--info.load = function(filter,settings) -- restart required--... same code as in info.reg_htk, but filters will be created from scratch every time--obs restarts, there is no reason to define it here again becuase hotkeys will be duplicated--endinfo.save = function(filter,settings)  for k, v in pairs(filter.hotkeys) do    local a = obs.obs_hotkey_save(filter.hk[k])    obs.obs_data_set_array(settings, k, a)    obs.obs_data_array_release(a)  endendobs.obs_register_source(info)

obspython

В OBS также доступен скриптинг через Python, для Windows только 3.6 версия, для Linux встроенная (т.к в настройках нельзя указать путь),
для MacOS Python не доступен для текущей (26.0.0) версии.
В отличии от Lua тут нельзя регистрировать источники, перебор фильтров не работает,
т.к не написан wrapper на функции с аргументом типа указатель-указатель.
Но в контексте скриптинга имеет место быть т.к:

• Модули для доступа к сети
• Возможноть удалённой отладки скрипта
• Контекстные менеджеры, поддержка OOП, большой набор модулей и.т.д
• http://lua-users.org/wiki/LuaVersusPython сравнение Lua с Python

Задачи

Перед тем как начать делать задачи, рекомендую сделать бэкап коллекции сцен,
с осторожностью использовать script_tick(вызывается раз в каждый кадр)
Проверять утечки памяти в папке logs, последняя строка последнего файла
пример время: Number of memory leaks: 0, если скрипт написан неправильно то
этой строчки там не окажется т.к OBS вылетит с ошибкой при закрытии.

3)[фильтры] "Динамическая прокрутка"
Создать программно или выбрать через интерфейс источник который будет фильтроваться,
к этом источнику добавить(если нет) фильтр Прокрутка (scroll_filter),
добавить интерфейс и/или горячие клавиши которые меняют значение вертикальной скорости
на случайную величину от 0 до 1000 при этом включать/выключать повторение с 50% шансом.

4)[эвенты] "Проверка"
При переключении сцен проверять идёт ли запись.
Если нет вывести оповещение ( например через error())

5)[время и файлы] "Пост-продакшен"
Создать скрипт который при нажатии горячей клавиши записывает текущее время,
относительное время от старта записи, добавляет текст "МЕТКА",
а через интерфейс UI кнопку записать текст, и место для набора текста.

6)[предметы сцены] "Сумма"
Посчитать количество сцен и предметов сцен, записать ответ в названии первой сцены.
Не учитывать группы, т.к перебор предметов груп не работает.

7) [фильтры и источники] "Нэйтив скриптинг"
Создать фильтр который будет с интервалом в 2 секунды включать и выключать источник за которым он закреплён.

Ответы на задачи и код скриптов включая первую часть на Github

Ссылки

• Девлог скрипта DVD заставки
• https://github.com/WiiPlayer2/obs-scripts репозиторий с нативными фильтрами
• https://github.com/bfxdev/OBS пиксель арт фильтр, код документирован
• https://github.com/Palakis/obs-websocket доступ к API OBS Studio через websocket, плагин для OBS

Медиасервер OvenMediaEngine.

• RTMP Push, MPEG2-TS Push, RTSP Pull Input
• WebRTC sub-second streaming
• Embedded WebRTC Signalling Server (WebSocket based)
• ICE (Interactive Connectivity Establishment)
• DTLS (Datagram Transport Layer Security)
• SRTP (Secure Real-time Transport Protocol)
• ULPFEC (Forward Error Correction) with VP8, H.264
• In-band FEC (Forward Error Correction) with Opus
• Low-Latency MPEG-DASH streaming (Chunked CMAF)
• Legacy HLS/MPEG-DASH streaming
• Embedded Live Transcoder (VP8, H.264, Opus, AAC, Bypass)
• Origin-Edge structure
• Monitoring
• Experiment
• P2P Traffic Distribution
• RTSP Pull, MPEG-TS Push Input

1. Показывают, как работают примеры по http и ws протоколу, хотя, очевидно, показывать нужно сразу, как работать на https и wss, все равно же придется заново все перенастраивать. К тому же, о прикреплении бесплатных сертификатов от Lets Encrypt в документации ни слова, хотя официально полностью поддерживают.
2. Аналогично, после настройки и запуска сервера точка входа публично доступна для всех.(как и у nginx-rtmp-module) Нужно сразу показывать, как защищать точку входа.

Установка. Быстрый старт

docker run -d \-p 1935:1935 -p 4000-4005:4000-4005/udp -p 3333:3333 -p 8080:8080 -p 9000:9000 -p 10000-10010:10000-10010/udp \airensoft/ovenmediaengine:latest

sudo docker container ls

sudo docker cp 87b8610034bc:/opt/ovenmediaengine/bin/origin_conf/Server.xml ./Server.xml

<Host>    <Names>        <Name>stream.***.ru</Name>    </Names>    <TLS>        <CertPath>/opt/ovenmediaengine/bin/cert.pem</CertPath>        <KeyPath>/opt/ovenmediaengine/bin/privkey.pem</KeyPath>        <ChainCertPath>/opt/ovenmediaengine/bin/chain.pem</ChainCertPath>    </TLS></Host>

<Publishers>    <HLS>        <TLSPort>${env:OME_HLS_STREAM_PORT:8080}</TLSPort>    </HLS>    <DASH>        <TLSPort>${env:OME_DASH_STREAM_PORT:8080}</TLSPort>    </DASH>    <WebRTC>        <Signalling>            <TLSPort>${env:OME_SIGNALLING_PORT:3333}</TLSPort>        </Signalling>    </WebRTC></Publishers>

sudo docker cp ./Server.xml 87b8610034bc:/opt/ovenmediaengine/bin/origin_conf/Server.xml

docker cp /etc/letsencrypt/live/stream.****.ru/chain.pem 87b8610034bc:/opt/ovenmediaengine/bin/docker cp /etc/letsencrypt/live/stream.****.ru/privkey.pem 87b8610034bc:/opt/ovenmediaengine/bin/docker cp /etc/letsencrypt/live/stream.****.ru/cert.pem 87b8610034bc:/opt/ovenmediaengine/bin/

sudo docker restart 87b8610034bc

rtmp://stream.***.ru:1935/app

dash https://stream.***.ru:8080/app/stream/manifest.mpddash ll https://stream.***.ru:8080/app/stream/manifest_ll.mpdhls https://stream.***.ru:8080/app/stream/playlist.m3u8webrtc wss://stream.***.ru:3333/app/stream/

Подписывание ссылок

<SignedPolicy>    <PolicyQueryKeyName>policy</PolicyQueryKeyName>    <SignatureQueryKeyName>signature</SignatureQueryKeyName>    <SecretKey>secretkey</SecretKey>          <Enables>        <Providers>rtmp</Providers>        <Publishers>webrtc,hls,dash,lldash</Publishers>    </Enables></SignedPolicy>

sudo bash ./signed_policy_url_generator.sh secretkey rtmp://stream.***.ru:1935/app/stream signature policy '{url_expire:8807083098927}'

rtmp://stream.***.ru:1935/app/stream?policy=eyJ1cmxfZXhwaXJlIjo4ODA3MDgzMDk4OTI3fQ&signature=xjS7NY-l4lY1f9e9sOiRNhPtAqI

sudo bash ./signed_policy_url_generator.sh secretkey wss://stream.***.ru:3333/app/stream signature policy '{"url_expire":8807083098927}'

sudo systemctl enable docker

sudo docker update --restart unless-stopped 87b8610034bc

Еще немного о корейской морковке

Пожелания

1. Система логов это обычные txt файлики. Было бы очень круто иметь чуть более продвиную визуальную аналитику
2. Я пробовал новый nginx-unit с его модным json-api в качестве команд управления/конфига. Суть в чем, обновляешь вебсервер, а он продолжает работать, заливаешь сертификаты, а ему не надо перезагружаться, домен, поддомен, добавить заголовки, убрать все налету без перезагрузки. А поверх json-api появляется миллион офигенно удобных админок с UI. Хотя в OME и вроде бы и нет нужды в таком API, но наверняка кто-то что-то потом обязательно придумает)
   

Как начались странности

Расследование

Прозрение

1. Две высокие шипованные части, где скорость передачи данных достигает 500 байт/мс. Эта фаза буферизации, перед началом воспроизведения. Обработчик копирует данные так быстро, как только может.
   
2. Область посередине это нормальное воспроизведение. Аудиоданные перемещаются со скоростью около 45 байт/мс.
   
3. Область заикания находится справа, где аудиоданные движутся со скоростью ближе 10 байт/мс. Это недостаточно быстро, чтобы воспроизведение продолжалось.
   

Корень проблемы

Извлеченные уроки

• Профессия Data Scientist
• Профессия Data Analyst

Streams like teen spirit

Pulsar или Kafka что лучше? Здесь мы обсудим плюсы и минусы, распространенные мифы и нетехнические критерии, чтобы найти лучший инструмент для ваших задач.

Обычно я рассказываю об Apache Kafka и ее экосистеме. О Pulsar за последние годы меня спрашивали только коммитеры и авторы Pulsar. Они задавали сложные технические вопросы, чтобы показать, что Kafka не идет ни в какое сравнение с Pulsar. На Reddit и подобных платформах разгораются яростные и очень субъективные споры на эту тему. Я поделюсь своей точкой зрения, основанной на многолетнем опыте работы со стриминговыми опенсорс-платформами.

Сравнение технологий нынче в моде: Kafka vs. Middleware, Event Streaming и API Platforms

Цель сравнения технологий помочь людям подобрать подходящее решение и архитектуру для своих потребностей. Универсального решения не существует. И это не дело вкуса. Просто для каждой задачи есть свой инструмент.

При этом такие сравнения почти всегда субъективны. Даже если автор не работает на вендора и представляется независимым консультантом, скорее всего, у него все равно есть любимчики, даже если он сам себе в этом не признается. Однако полезно посмотреть на инструменты с разных точек зрения. Поскольку Apache Pulsar сейчас обсуждают, я решил поделиться своим мнением и сравнить его с Kafka. Я работаю в Confluent, а мы лучшие эксперты по Apache Kafka и ее экосистеме. И все же я постараюсь быть максимально объективным и оперировать голыми фактами.

Опенсорс-фреймворки и коммерческие программы постоянно сравнивают. Я и сам делал такие сравнения в своем блоге и на других платформах, например InfoQ: Сравнение платформ интеграции, Выбор подходящего ESB для ваших потребностей, Kafka vs. ETL / ESB / MQ, Kafka vs. Mainframe и Apache Kafka и API Management / API Gateway. Просто заказчики хотели понять, какой инструмент поможет решить те или иные задачи.

Если говорить о сравнении Pulsar и Kafka, ситуация немного отличается.

Зачем сравнивать Pulsar и Kafka?

Реальные и потенциальные заказчики редко спрашивают о Pulsar. Хотя, если честно, в последние месяцы чуть чаще где-то на каждой 15-й или 20-й встрече. Потому что фичи и варианты использования у них частично совпадают. Хотя, по-моему, все дело в паре статей о том, что Pulsar якобы в чем-то лучше Kafka. В пользу противоположной точки зрения нет никаких фактов и очень мало материала.

Я не видел ни одной организации, которая бы всерьез задумывалась о Pulsar в продакшене, хотя по всему миру множество пользователей, которым нужна технология распределенной обработки сообщений, вроде Kafka или Pulsar. По-моему, те, кто рекомендует Pulsar, чего-то не договаривают.

Например, их главный пользователь Tencent, крупная китайская технологическая компания, которая при этом очень активно использует Kafka везде, кроме одного проекта, где пригодился Pulsar. Tencent обрабатывает с Kafka десять триллионов сообщений в день (только представьте: 10 000 000 000 000). Если посчитать, Tencent использует Kafka в тысячу раз активнее, чем Pulsar (10 трлн против десятков млрд). Tencent с удовольствием рассказывают о своем деплое Kafka: Как Tencent PCG использует Apache Kafka для обработки 10+ трлн сообщений в день.

Сравнение двух конкурирующих опенсорс-платформ

Apache Kafka и Apache Pulsar две замечательные конкурирующие технологии. Логично будет их сравнить.

У Apache Kafka и Apache Pulsar очень схожий набор функций. Советую оценить обе платформы на предмет доступных функций, зрелости, распространения на рынке, опенсорс-инструментов и проектов, обучающего материала, проведения митапов по регионам, видео, статей и так далее. Примеры вариантов использования в вашей отрасли помогут принять правильное решение.

Confluent уже писал сравнение Kafka vs. Pulsar vs. RabbitMQ: производительность, архитектура и функции. Я тоже поучаствовал. Значит, сравнение уже есть

О чем тогда эта статья?

Я хочу рассмотреть несколько мифов из споров на тему Kafka против Pulsar, которые регулярно возникают в блогах и на форумах. Затем я сравню их не только по техническим аспектам, потому что обычно никто не говорит о Pulsar с этой стороны.

Kafka vs Pulsar мифы

Мне попадалось несколько мифов. С некоторыми я согласен, другие можно легко развенчать фактами. Ваше мнение может отличаться от моего, это нормально. Я излагаю исключительно свою точку зрения.

Миф 1. У Pulsar есть характеристики, которых нет у Kafka.

Правда.

Если сравнивать Apache Kafka и Apache Pulsar, можно найти различия в многоуровневой архитектуре, очередях и мультитенантности.

Но!

У Kafka тоже есть уникальные особенности:

• В два раза меньше серверов, которыми приходится управлять.
• Данные сохраняются на диск только один раз.
• Данные кэшируются в памяти только однажды.
• Проверенный протокол репликации.
• Производительность zero-copy.
• Транзакции.
• Встроенная обработка потока.
• Долгосрочное хранилище.
• В разработке: удаление ZooKeeper (KIP-500), чтобы использовать и деплоить Kafka было еще проще, чем Pulsar с его четырехкомпонентной архитектурой (Pulsar, ZooKeeper, BookKeeper и RocksDB), а еще чтобы повысить масштабируемость, устойчивость и т. д.
• В разработке: многоуровневое хранилище (KIP-405), чтобы повысить эластичность и экономичность Kafka.

Спросите себя: можно ли сравнивать опенсорс-платформы или продукты и вендоров с комплексным предложением?

Легко добавлять новые функции, если для них не нужно предоставлять критическую поддержку. Не оценивайте характеристики по списку. Узнайте, насколько они проверены в рабочих сценариях. Сколько из этих уникальных особенностей имеют низкое качество и реализованы наспех?

Например. Понадобилось несколько лет, чтобы реализовать и испытать в бою Kafka Streams в качестве нативного движка обработки потоков. Как это можно сравнивать с Pulsar Functions? Последнее позволяет добавлять определяемые пользователем функции (UDF) безо всякой связи с обработкой реальных потоков. Или это скорее похоже на Single Message Transformations (SMT), основную функцию Kafka Connect? Не сравнивайте круглое с квадратным и не забывайте учитывать зрелость. Чем критичнее функция, тем больше зрелости ей требуется.

Сообщество Kafka вкладывает невероятные усилия в работу над основным проектом и его экосистемой. Только в Confluent 200 инженеров занимаются исключительно проектом Kafka, дополнительными компонентами, коммерческими продуктами и предложениями SaaS в основных облачных провайдерах.

Миф 2. У Pulsar есть несколько крупных пользователей, например китайский Tencent.

Правда.

Но! Tencent использует Kafka активнее, чем Pulsar. Отдел выставления счетов, где используется Pulsar, это лишь малая часть Tencent, в то время как остальные используют Kafka. У них есть глобальная архитектура на основе Kafka, где больше тысячи брокеров сгруппированы в единый логический кластер.

Будьте осторожны с опенсорс-проектами. Проверяйте, какого успеха добились с ними обычные компании. Если эту технологию использует один технологический гигант, это еще не значит, что вам она тоже подойдет. Сколько компаний из Fortune 2000 могут похвастаться историями успеха с Pulsar?

Ищите примеры не только среди гигантов!

Примеры обычных компаний позволят лучше понять, как применяется тот или иной инструмент в реальном мире. Если это не истории успеха от самих вендоров. На сайте Kafka можно найти много примеров компаний. Более того, на конференциях Kafka Summit в Сан-Франциско, Нью-Йорке и Лондоне каждый год разные предприятия из разных отраслей делятся своими историями и кейсами. Это компании из Fortune 2000, предприятия среднего бизнеса и стартапы.

Приведу один пример про Kafka. Для репликации данных в реальном времени между отдельными кластерами Kafka существует много разных инструментов, включая MirrorMaker 1 (часть проекта Apache Kafka), MirrorMaker 2 (часть проекта Apache Kafka), Confluent Replicator (от Confluent, доступен только в рамках Confluent Platform и Confluent Cloud), uReplicator (опенсорс от Uber), Mirus (опенсорс от Salesforce), Brooklin (опенсорс от LinkedIn).

На практике разумно использовать только два варианта, если, конечно, вы не хотите обслуживать и улучшать код самостоятельно. Это MirrorMaker 2 (еще не вполне зрелая новинка, но отличный выбор для средне- и долгосрочной перспективы) и Confluent Replicator (проверенный на практике во многих критически важных для бизнеса деплоях, но платный). Остальные варианты тоже нормальные. Но кто обслуживает эти проекты? Кто разбирается с багами и проблемами безопасности? Кому звонить, если в продакшене что-то случилось? Одно дело деплоить критически важные системы в продакшене, другое оценивать и пробовать опенсорс-проект.

Миф 3. Pulsar предлагает очереди и стриминг в одном решении.

Частично.

Очереди используются для обмена сообщениями между двумя точками. Они предоставляют асинхронный протокол взаимодействия, то есть отправитель и получатель сообщения не должны обращаться к очереди одновременно.

Pulsar предлагает только ограниченную поддержку очередей сообщений и стриминга событий. В обеих областях он пока не может составить крепкую конкуренцию по двум причинам:

1. Pulsar предлагает ограниченную поддержку очередей сообщений, потому что ему не хватает таких популярных функций, как XA-транзакции, маршрутизация, фильтрация сообщений и т. д. Это обычные функции в таких системах сообщений, как IBM MQ, RabbitMQ, и ActiveMQ. Адаптеры Pulsar для систем сообщений тоже ограничены в этом смысле. В теории все выглядит нормально, но на практике...

   
   

2. Pulsar предлагает ограниченную поддержку стриминга. Например, на практике в большинстве случаев он не поддерживает семантику строго однократной (exactly-once) доставки и обработки. Вряд ли кто-то станет использовать Pulsar для платежной системы, потому что платежи могут дублироваться и теряться. Ему не хватает функционала для обработки потоков с соединением, агрегированием, окнами, отказоустойчивым управлением состоянием и обработкой на основе времени событий. Топики в Pulsar отличаются от топиков в Kafka в худшую сторону из-за BookKeeper, который был придуман в 2008 году как лог упреждающей записи для HDFS namenode в Hadoop в расчете на краткосрочное хранение.

   
   

Примечание. Адаптер Kafka для Pulsar тоже ограничен. В теории звучит заманчиво, но в реальности не все получается, потому что он поддерживает только небольшую часть функционала Kafka.

Как и Pulsar, Kafka предлагает ограниченную поддержку очереди.

В Kafka можно использовать разные обходные пути, чтобы реализовать нормальное поведение очереди. Если вы хотите использовать отдельные очереди вместо общих топиков Kafka для:

• Безопасности => используйте Kafka ACL (и дополнительные инструменты, вроде контроля доступа на основе ролей (RBAC) от Confluent).
• Семантики (отдельных приложений) => используйте группы консюмеров в Kafka.
• Балансировки нагрузки => используйте партиции Kafka.

Обычно я спрашиваю заказчиков, зачем им нужны очереди. Kafka предлагает готовые решения для разных сценариев, на которые можно просто посмотреть с другой стороны. Редко встречаются случаи, когда действительно требуется высокая пропускная способность с очередями.

Зная обходные пути и ограничения Pulsar и Kafka в плане сообщений, давайте проясним: ни одна из платформ не предлагает решение для обмена сообщениями.

Если вам нужно именно оно, возьмите что-то вроде RabbitMQ или NATS.

Однозначного решения здесь нет. Многие наши заказчики заменяют имеющиеся системы сообщений, вроде IBM MQ, на Kafka (из соображений масштабируемости и затрат). Просто нужно знать имеющиеся варианты и их недостатки, все взвесить и подобрать решение, которое лучше всего подходит именно вам.

Миф 4. Pulsar предоставляет потоковую обработку.

Неправда.

Или, если по-честному, все зависит от того, что вы называете обработкой потоков. Это какая-то простейшая функция или прямо полноценная обработка?

Если в двух словах, обработкой потоков я называю непрерывное потребление, обработку и агрегирование событий из разных источников данных. В реальном времени. В любом масштабе. Естественно, с защитой от сбоев, особенно если речь идет о stateful.

Pulsar предлагает минимальную потоковую обработку через Pulsar Functions. Она подходит для простых обратных вызовов, но не сравнится с функционалом Kafka Streams или ksqlDB для создания стриминговых приложений со stateful-информацией, скользящими окнами и другими функциями. Варианты применения можно найти в разных отраслях. Например, на сайте Kafka Streams есть кейсы New York Times, Pinterest, Trivago, Zalando и других.

Для стриминга аналитики Pulsar обычно используется в сочетании с нормальной платформой обработки потоков, вроде Apache Spark или Apache Flink, но вам придется управлять дополнительным элементами распределенной архитектуры и разбираться в их сложном взаимодействии.

Миф 5. Pulsar предоставляет семантику exactly-once, как и Kafka.

Неправда.

В Pulsar есть функция дедупликации, чтобы одно сообщение не сохранялось в брокере Pulsar дважды, но ничто не мешает консюмеру прочитать это сообщение несколько раз. Этого недостаточно для любого применения обработки потоков, где для входа и выхода используется Pulsar.

В отличие от функции транзакций в Kafka, здесь нельзя привязывать отправленные сообщения к состоянию, записанному в обработчике потоков.

Семантика Exactly-Once Semantics (EOS) доступна с версии Kafka 0.11, которая вышла три года назад, и используется во многих продакшен-деплоях. Kafka EOS поддерживает всю экосистему Kafka, включая Kafka Connect, Kafka Streams, ksqlDB и такие клиенты, как Java, C, C++, Go и Python. На конференции Kafka Summit было несколько выступлений, посвященных функционалу Kafka EOS, включая это превосходное и понятное введение со слайдами и видео.

Миф 6. У Pulsar производительность выше, чем у Kafka.

Неправда.

Я не поклонник разных бенчмарков производительности и пропускной способности. Обычно они субъективны и относятся к конкретной задаче независимо от того, кто их проводит вендор, независимый консультант или исследователь.

Например, GIGAOM опубликовали один бенчмарк, где сравнивается задержка и производительность в Kafka и Pulsar. Автор намеренно замедлил Kafka, настроив параметр flush.messages = 1, в результате которого каждый запрос вызывает fsync и Kafka синхронизируется с диском при каждом сообщении. В этом же бенчмарке консюмер Kafka отправляет подтверждение синхронно, а консюмер Pulsar асинхронно. Неудивительно, что Pulsar вышел явным победителем. Правда, автор забыл упомянуть или объяснить существенные отличия в конфигурации и измерениях. Давайте не будем путать теплое с мягким.

На самом деле архитектура Pulsar сильнее нагружает сеть (из-за брокера, который выступает как прокси перед серверами bookie BookKeeper) и требует в два раза больше пропускной способности (потому что BookKeeper записывает данные в лог упреждающей записи и в главный сегмент).

Confluent тоже делал бенчмарки. Только там сравнивалось сопоставимое. Неудивительно, что результаты получились другими. Но нужно ли вообще встревать в эти бои на бенчмарках между вендорами?

Оцените свои требования к производительности. Сделайте proof-of-concept с Kafka и Pulsar, если надо. Скорее всего, в 99% случаев обе платформы покажут приемлемую производительность для вашего сценария. Не доверяйте посторонним субъективным бенчмаркам! Ваш случай все равно уникален, и производительность это только один из аспектов.

Миф 7. Pulsar проще в использовании, чем Kafka.

Неправда.

Без дополнительных инструментов вам будет сложно и с Kafka, и с Pulsar.

У Kafka две распределенных системы: сама Kafka и Apache ZooKeeper.

Но! У Pulsar три распределенных системы, а еще хранилище: Pulsar, ZooKeeper и Apache BookKeeper. Как и Pulsar, BookKeeper использует ZooKeeper. Для некоторых задач хранения используется RocksDB. Это означает, что Pulsar гораздо сложнее понять и настроить по сравнению с Kafka. Кроме того, у Pulsar больше параметров конфигурации, чем у Kafka.

Kafka движется в противоположном направлении скоро ZooKeeper будет удален (см. KIP-500), так что останется всего одна распределенная система, которую нужно деплоить, обслуживать, масштабировать и мониторить:

ZooKeeper мешает масштабированию в Kafka и усложняет эксплуатацию. Но у Pulsar все еще хуже!

Одна из главных проблем моих заказчиков использование ZooKeeper в критически важных деплоях в большом масштабе. С нетерпением жду упрощения архитектуры Kafka, чтобы остались только брокеры. Кроме того, мы получим единую модель безопасности, потому что больше не придется отдельно настраивать безопасность для ZooKeeper. Это огромное преимущество, особенно для крупных организаций и отраслей со строгим регулированием. Ребята из комплаенса и ИБ скажут вам спасибо за упрощенную архитектуру.

Использование платформы связано НЕ только с архитектурой

У Kafka гораздо более подробная документация, огромное сообщество экспертов и большой набор поддерживающих инструментов, которые упрощают работу.

Кроме того, по Kafka есть много вариантов обучения онлайн-курсы, книги, митапы и конференции. К сожалению, у Pulsar с этим все плохо.

Миф 8. Архитектура с тремя уровнями лучше, чем с двумя.

Зависит от ситуации.

Лично я скептически отношусь к тому, что трехуровневую архитектуру Pulsar (брокеры Pulsar, ZooKeeper и BookKeeper) можно считать преимуществом для большинства проектов. Тут есть издержки.

Twitter рассказал, как отказался от BookKeeper + DistributedLog (DistributedLog похож на Pulsar по архитектуре и дизайну) около года назад, соблазнившись такими преимуществами одноуровневой архитектуры Kafka, как экономичность и улучшенная производительность, которых недоставало двухуровневой архитектуре с отдельным хранилищем.

Как и Pulsar, DistributedLog построен на BookKeeper и добавляет стриминговый функционал, схожий с Pulsar (например, уровень обработки существует отдельно от уровня хранилища). Изначально DistributedLog был отдельным проектом, но потом присоединился к BookKeeper, хотя сегодня им, похоже, мало кто занимается (всего пара коммитов за последний год). Среди основных причин перехода Twitter на Kafka называлась значительная экономия и повышение производительности, а также обширное сообщество и популярность Kafka. Вот какие выводы они сделали: Для одного консюмера экономия ресурсов составила 68%, а для нескольких целых 75%.

Преимущества трехуровневой архитектуры проявляются при создании масштабируемой инфраструктуры. При этом дополнительный уровень увеличивает нагрузку на сеть минимум на 33%, а данные, которые хранятся в брокерах Pulsar, приходится дополнительно кэшировать на обоих уровнях, чтобы добиться аналогичной производительности, а еще дважды записывать на диск, потому что формат хранения в Bookkeeper основан не на логе.

В облаке, где работает большинство деплоев Kafka, лучшим внешним хранилищем выступает не такая узкоспециализированная технология, как BookKeeper, а популярное и проверенное хранилище объектов, вроде AWS S3 и GCP GCS.

Tiered Storage в Confluent Platform на основе AWS S3, GCP GCS и им подобных, дает те же преимущества без дополнительного слоя BookKeeper, как у Pulsar, и без дополнительных затрат и задержек, связанных с передачей данных по сети. У Confluent ушло два года на то, чтобы выпустить GA-версию Tiered Storage for Kafka с круглосуточной поддержкой для самых критичных данных. Tiered Storage пока недоступно для опенсорсной версии Apache Kafka, но Confluent вместе с сообществом Kafka (включая крупные технологические компании, вроде Uber) работает над KIP-405, чтобы добавить Tiered Storage в Kafka с разными вариантами хранения.

У обеих архитектур есть плюсы и минусы. Лично мне кажется, что 95% проектов не нуждаются в сложной трехуровневой архитектуре. Она может пригодиться там, где требуется внешнее недорогое хранилище, но вам придется отвечать за круглосуточное соблюдение SLA, масштабируемость и пропускную способность. А еще за безопасность, управление, поддержку и интеграцию в вашу экосистему. Если вам действительно нужна трехуровневая архитектура, не стану вас останавливать.

Связанный миф: Pulsar лучше подходит для отстающих консюмеров благодаря уровню кэширования и хранения.

Неправда.

Основная проблема отстающих консюмеров в том, что они занимают page cache, то есть последние сообщения уже кэшированы. При чтении из предыдущих сегментов они заменяются, что снижает производительность консюмеров, читающих с начала лога.

Архитектура Pulsar проявляет себя даже хуже в этом отношении. Проблема сброса кэша сохраняется, при этом для чтения нужно сделать лишний прыжок по сети и загрузить сеть вместо того, чтобы просто прочитать сообщение с локального носителя.

Миф 9. Kafka масштабируется хуже, чем Pulsar.

Неправда.

Это один из главных аргументов сообщества Pulsar. Как я уже говорил, это всегда зависит от выбранного бенчмарка. Например, я видел тесты с эквивалентными вычислительными ресурсами, где на высокой пропускной способности у Kafka результат был гораздо лучше, чем у Pulsar. Вот один из таких бенчмарков:

В большинстве случаев масштабируемость не проблема. Kafka можно легко разогнать до нескольких гигабайтов в секунду, как в демонстрации Масштабирование Apache Kafka до 10+ ГБ в секунду в Confluent Cloud:

Честно говоря, этот вопрос должен волновать менее 1% пользователей. Если у вас требования, как у Netflix (петабайты в день) или LinkedIn (триллионы сообщений), есть смысл обсуждать самую подходящую архитектуру, железо и конфигурацию. Остальным можно не беспокоиться.

Связанный миф: сейчас в Kafka может храниться всего 500к партиций на кластер.

Правда.

Пока у Kafka не лучшая архитектура для масштабных деплоев с сотнями тысяч топиков и партиций.

Но! Pulsar тоже не резиновый. Просто у него другие лимиты.

Ограничения в Kafka связаны с Zookeeper. Когда Zookeeper удалят через KIP-500, верхняя граница уйдет вместе с ним.

Примечание: успех зависит от подходящего устройства архитектуры!

Если у заказчика возникли проблемы с количеством партиций и масштабируемостью в Kafka, скорее всего, он ошибся в архитектуре и приложениях (Pulsar бы тут точно не помог).

Kafka это платформа стриминга, а не очередной IBM MQ. Если вы попробуете воссоздать любимое решение и архитектуру MQ с Kafka, у вас вряд ли что-то получится. У меня было несколько заказчиков, которые потерпели крах, но смогли привести все в порядок с нашей помощью.

Скорее всего, у вас не возникнет проблем с количеством партиций и масштабируемостью, даже пока Kafka еще использует ZooKeeper, если вы правильно все спроектируете и разберетесь в базовых принципах Kafka. Такие проблемы часто возникают с любой технологией, вроде Kafka, которая вводит совершенно новый уровень и парадигму (например, при первом появлении облаков немало компаний набили себе шишки при попытке их освоить).

Связанный миф: Pulsar поддерживает практически неограниченное число партиций.

Неправда.

У BookKeeper существуют те же ограничения по одному файлу на ledger, что и у Kafka, но в одной партиции таких ledger несколько. Брокеры Pulsar объединяют партиции в группы, но на уровне хранения, в Bookkeeper, данные хранятся в сегментах, и на каждую партицию приходится много сегментов.

В Kafka метаданные для этих сегментов хранятся в Zookeeper, откуда и возникают эти ограничения по числу. Когда Kafka избавится от этой зависимости, границы возможного раздвинутся. С нетерпением жду реализации KIP-500. Подробности читайте в статье Apache Kafka справится сама: удаление зависимости от Apache ZooKeeper.

Связанный миф: потребности масштабирования в Kafka необходимо определять при создании топика.

Отчасти это правда.

Если требуется очень большой масштаб, в топиках Kafka можно сразу создать больше партиций, чем обычно требуется для этой задачи. (См. Потоки и таблицы в Apache Kafka: топики, партиции и хранение.) Или можно добавить партиции позже. Это не идеальное решение, но так уж устроены распределенные системы стриминга (которые, кстати, масштабируются лучше, чем традиционные системы обработки сообщений, вроде IBM MQ).

Оптимальные методы создания топиков и изменения их конфигурации уже тщательно продуманы за вас, так что не волнуйтесь.

Но! У топиков Pulsar есть то же ограничение!

Пропускная способность для записи зависит от числа партиций, назначенных топику Pulsar, точно так же, как это происходит в топике Kafka, поэтому там тоже придется создавать партиции с запасом. Дело в том, что в каждой партиции записывать можно только в один ledger за раз (а их может быть несколько). Увеличение числа партиций динамически влияет на порядок сообщений, как и в Kafka (порядок нарушается).

У Kafka и Pulsar с масштабированием все отлично. Этого будет более чем достаточно почти в любом сценарии.

Если вам нужен совсем заоблачный масштаб, лучше взять реализацию без ZooKeeper. Так что KIP-500 это самое ожидаемое изменение в Kafka, судя по сообществу и заказчикам Confluent.

Миф 10. В случае аппаратного сбоя Pulsar восстанавливается моментально, а Kafka приходится перегружать данные.

И да, и нет.

Если брокер Pulsar вырубится, ничего не страшного не будет, это правда, но, в отличие от брокера Kafka, он и не хранит данные, а просто выступает в качестве прокси для уровня хранения, то есть BookKeeper. Так что подобные заявления о Pulsar это просто маркетинговый ход. Почему никто не говорит, что бывает, если полетит нода BookKeeper (bookie)?

Если завершить и перезапустить BookKeeper bookie, данные будут точно так же перераспределяться, как и в Kafka. В этом суть распределенных систем с их репликацией и партициями.

Kafka уже предлагает эластичность.

Это важно. Основатель Confluent, Джей Крепс (Jay Kreps) недавно писал об этом: Эластичные кластеры Apache Kafka в Confluent Cloud. В облачном сервисе SaaS, вроде Confluent Cloud, конечный пользователь не думает об аппаратных сбоях. Он ожидает непрерывный аптайм и SLA на уровне 99,xx. С оплатой за потребление пользователь не заботится об управлении брокерами, изменении размеров нод, увеличении или уменьшении кластеров и подобных деталях.

Самоуправляемым кластерам Kafka нужны такие же возможности. Tiered Storage for Kafka это огромное хранилище, с которым данные не хранятся на брокере и восстановление после сбоев происходит почти моментально. Если добавить сюда такие инструменты, как Self-Balancing Kafka (эта фича от Confluent описана в статье по ссылке выше), можно вообще забыть об эластичности в самоуправляемых кластерах.

К сожалению, в Pulsar вы ничего подобного не найдете.

Миф 11. Pulsar справляется с репликацией между кластерами лучше, чем Kafka.

Неправда.

Любая распределенная система должна решать такие проблемы, как CAP-теорема и кворум в распределенных вычислениях. Кворум это минимальное число голосов, которое распределенная транзакция должна получить, чтобы выполнить операцию в распределенной системе. Такой подход позволяет обеспечить согласованность операций.

Задачи по кворуму Kafka поручает ZooKeeper. Даже после реализации KIP-500 и удаления ZooKeeper законы физики не перестанут действовать: проблемы задержки в распределенных системах существуют в таких регионах, как Восточная, Центральная и Западная часть США и даже по всему миру. Скорость света, конечно, впечатляет, но все же имеет ограничения.

Эту проблему можно обойти разными способами, включая использование инструментов репликации в реальном времени, например MirrorMaker 2 в Apache Kafka, Confluent Replicator или Confluent Multi-Region-Clusters. Эти варианты и советы см. в статье Архитектурные шаблоны для распределенных, гибридных, периферийных и глобальных деплоев Apache Kafka.

Вы не найдете универсальное решение, которое обеспечит глобальную репликацию + нулевой простой + нулевую потерю данных. Для самых критически важных приложений Confluent Multi-Region-Clusters предлагает RTO=0 и RPO=0 (нулевой простой и нулевую потерю данных) с автоматическим аварийным восстановлением и отработкой отказа, даже если упадет целый датацентр или облачный регион.

Для таких случаев архитектура Pulsar будет еще сложнее, чем ее базовая версия. Просто для георепликации Pulsar требует дополнительный глобальный кластер Zookeeper, а для больших расстояний это не годится. Обходной путь есть, но от CAP-теоремы и законов физики не уйдешь.

Что с Kafka, что с Pulsar вам нужна проверенная архитектура для борьбы с физикой в глобальных деплоях.

Миф 12. Pulsar совместим с интерфейсом и API Kafka.

Отчасти.

Pulsar предлагает простейшую реализацию с зачаточной совместимостью с протоколом Kafka v2.0.

У Pulsar есть конвертер для базовых элементов протокола Kafka.

В теории совместимость с Kafka выглядит убедительно, но вряд ли это серьезный аргумент для переноса действующей инфраструктуры Kafka в Pulsar. Зачем такой риск?

Мы слышали заявления о совместимости с Kafka и в других примерах, например для гораздо более зрелого сервиса Azure Event Hubs. Почитайте об ограничивающих факторах их Kafka API. Вы удивитесь. Никакой поддержки основных функций Kafka, вроде транзакций (и семантики exactly-once), сжатия или compaction для логов.

Раз, по сути, это не Kafka, существующие приложения Kafka будут вести себя непредсказуемо в таких вот совместимых системах, будь то Azure Event Hubs, Pulsar или другая оболочка.

Kafka vs. Pulsar комплексное сравнение

Выше мы говорили о мифах, которые гуляют по разным статьям и постам. С ними, вроде, все понятно.

Но я обещал, что мы поговорим не только о технических деталях. При выборе технологии важны и другие аспекты.

Рассмотрим три из них: доля на рынке, корпоративная поддержка и облачные предложения.

Доля на рынке у Apache Kafka и Apache Pulsar

Статистика в Google Trends за последние пять лет совпадает с моими личными наблюдениями интерес к Apache Kafka гораздо выше, чем к Apache Pulsar:

Примерно так же выглядит картинка сравнения на Stack Overflow и аналогичных платформах, по числу и размеру поддерживающих вендоров, открытой экосистеме (интеграция инструментов, обертки, вроде Spring Kafka) и подобным характеристикам.

Открытые вакансии еще один индикатор распространения технологии. Для Pulsar их мало, то есть его использует не так много компаний. Убедитесь сами поищите на любом сайте. Если искать по всему миру, для Pulsar вакансий меньше сотни, а для Kafka тысячи. Кроме того, в большинстве вакансий для Pulsar указано, что требуется опыт с Kafka, Pulsar, Kinesis и аналогичными технологиями.

В большинстве случаев такие характеристики важнее для успешного проекта, чем технические детали. В конце концов ваша цель решить определенную бизнес-задачу, правда же?

Раз Pulsar так мало распространен, почему о нем вообще говорят? Во-первых, потому, что независимые консультанты, аналитики и блоггеры (включая меня) должны рассказывать о новых современных технологиях, чтобы привлечь аудиторию. Если честно, люди любят об этом читать.

Корпоративная поддержка для Kafka и Pulsar

Корпоративная поддержка для Kafka и Pulsar существует.

Но все не совсем так, как можно ожидать. Вот несколько вендоров, к которым вы можете обратиться, если решили работать с Pulsar:

• Streamlio (теперь принадлежит Splunk) компания, которая раньше стояла за Apache Pulsar. Splunk пока не объявили о своей будущей стратегии для поддержки пользователей, которые работают над проектами на основе Pulsar. Splunk славится своими популярными аналитическими платформами. Это их основной бизнес (1,8 млрд долларов в 2019 году). Единственное, на что жалуются пользователи, ценник. Splunk активно используют Kafka, а сейчас интегрируют Pulsar в Splunk Data Stream Processor (DSP). Сильно сомневаюсь, что Splunk вдруг увлечется опенсорсом, чтобы поддержать ваш драгоценный проект на базе Pulsar (возможно, чего-то можно ожидать от DSP). Будущее покажет.
• StreamNative основана одним из изначальных разработчиков Apache Pulsar и поддерживает платформу стриминга на основе Pulsar. На июнь 2020 года у StreamNative было 13 (целых 13, да!) сотрудников в LinkedIn. Уж не знаю, хватит этого для поддержки вашего критически важного проекта или нет.
• TIBCO объявили о поддержке Pulsar в декабре 2019 года. За последние годы стратегия у них сместилась с интеграции на аналитику. Пользователи их промежуточного ПО уходят от TIBCO толпами. В отчаянии они приняли стратегическое решение: поддерживать другие платформы, даже если у них нет никакого опыта и никакой связи с ними. Да, звучит как миф, но TIBCO делают то же самое для Kafka. Любопытный факт: TIBCO предлагает Kafka и ZooKeeper в Windows! Такого больше никто не делает. Все знают, это приводит к нестабильности и несогласованности. Но если что, TIBCO помогут вам с Kafka и Pulsar. Зачем вообще сравнивать эти платформы, если можно получить обе у одного вендора, причем даже на Windows, с .exe и bat-скриптами для запуска серверных компонентов:

Вендоров для Kafka больше с каждым днем.

Это очень распространенная на рынке платформа. Лучшее подтверждение поддержка от крупнейших вендоров. IBM, Oracle, Amazon, Microsoft и многие другие поддерживают Kafka и встраивают возможности интеграции с ней в свои продукты.

Окончательное подтверждение этому я получил на конференции Oracle OpenWorld 2019 в Сан-Франциско, где выступал менеджер по GoldenGate (великолепный и очень дорогой инструмент CDC от Oracle). В основном он рассказывал, как GoldenGate станет платформой интеграции данных вообще для всего. Половина выступления была посвящена стримингу, платформе Kafka и тому, что GoldenGate будет обеспечивать интеграцию с разными базами/озерами данных и Kafka в обоих направлениях.

Полностью управляемые облачные сервисы для Kafka и Pulsar

Какие облачные решения доступны для Kafka и Pulsar?

Для Apache Pulsar есть облачный сервис с очень говорящим названием:

Kafkaesque.

Я серьезно. Сами посмотрите [UPD: 17 июня они переименовали KAFKAESQUE в KESQUE. Видимо, поняли, всю комичность ситуации.]

Для Apache Kafka существуют разные предложения на выбор:

• Confluent Cloud (SaaS) полностью управляемый сервис с оплатой по мере использования, круглосуточной доступностью, эластичностью и бессерверными функциями для Apache Kafka и связанной экосистемы (Schema Registry, коннекторы Kafka Connect и ksqlDB для обработки потоков).
• Amazon MSK (PaaS) подготавливает ZooKeeper и брокеры Kafka, а конечные пользователи сами обслуживают их, исправляют баги, устанавливают обновления и т. д. Важный факт: AWS не включает проблемы с Kafka в поддержку и SLA 99,95.
• Azure Event Hubs (SaaS) предоставляет конечную точку Kafka (с проприетарной реализацией) для взаимодействия с приложениями Kafka. Это легко масштабируемое решение с высокой производительностью. Это не вполне Kafka, просто эмуляция, и тут не хватает некоторых важных функций, вроде семантики exactly-once, compaction логов и сжатия. Не говоря уже о дополнительных возможностях, вроде Kafka Connect и Kafka Streams
• Big Blue (IBM) и Big Red (Oracle) предлагают облачные решения для Kafka и соответствующих API. Не знаю, использует их кто-нибудь или нет. Понятия не имею, насколько они хороши, никогда не видел их в деле.
• Много компаний поменьше, вроде Aiven, CloudKarafka, Instaclustr и других.

В общем, про распространенность Kafka и Pulsar на рынке все очевидно.

И все же Apache Kafka или Apache Pulsar?

В двух словах: Pulsar пока здорово отстает от Kafka по зрелости в плане надежности для больших масштабов и обширности сообщества.

И вообще не факт, что Pulsar лучше.

Есть смысл сравнивать их, если вы решили использовать только опенсорс-инструменты. Узнайте, что подойдет лучше именно вам. Не забудьте учесть технические характеристики, уровень зрелости, вендоров, сообщество разработчиков и другие важные факторы. Что вписывается в вашу ситуацию?

Если в Kafka и Pulsar есть не все нужные вам функции, выбирайте Kafka: для нее есть много вендоров и облачных решений. Pulsar, к сожалению, сильно отстает и вряд ли догонит в ближайшем будущем.

Привет! Меня зовут Антон Матренин, я один из организаторов сообщества ArtFlutter. Сегодня мы поговорим об онлайн митапах, платформах для онлайн конференций, стриминговых сервисах и в конце покажу пример настройки собственного онлайн-события.

Все мы привыкли к конференциям, которые проводятся в каком-то модном коворкинге, отеле или на базе офиса компании. Но обстоятельства привели нас к тому, что массовые мероприятия могут проводятся только в онлайне, поэтому у нас возникла идея сделать пробный вебинар, который будет доступен любому человеку по всему миру. К сожалению, опыта в проведении подобных мероприятий у меня не было, пришлось разбираться самостоятельно методом проб и ошибок. Не смотря на то, что технические аспекты выбора той или иной платформы вещания преодолимы, залогом успеха являются спикеры и зрители.

Поиск спикеров и PR

У нас большое комьюнити по Flutter на 700+ человек в телеграмме, поэтому самым эффективным вариантом поиска был прямой контакт с активными участниками группы. Стоит также позаботиться о резерве, потому что всегда есть место форс-мажору и нужно быть готовым поставить кого-то на место выбывшего спикера. Будет большим подспорьем, если у вас в команде организаторов есть такой человек. С одной стороны проще с поиском, с другой ты будешь в резерве, если что на следующий митап попадешь в основу не самый большой козырь на переговорах со спикером. Еще будет круто, если у вас есть возможность организовать символический подарок для спикеров, ведь получить что-то на память всегда приятно.

С пиаром в нашем случае нам помог GDG Kyiv-Center мы предоставили им подробное описание и спустя пару часов появилось событие ArtFlutter Meetup #1. Плюс ко всему прошлись по нескольким смежным телеграмм-каналам с ссылками на событие, разумеется с разрешения администраторов. Вышеперечисленные действия дали нам стабильно 50-60 человек онлайна. Для первого раза результат достаточно неплохой, но если у вас найдется пару интересных рецептов для повышения онлайна делитесь в комментариях!

Выбор формата

Первый вопрос был: а нужен ли нам онлайн? Ведь самый простой вариант это созвониться со спикером в скайпе, сделать запись экрана и выложить полученное видео на YouTube. Однако, любое событие проводится не только для получения ценных знаний, а также для коммуникации зрителей с докладчиком, общение между участниками сообщества и подогрева интереса как у слушателя, так и у докладчика.

Определившись с прямым эфиром я попытался найти платный сервис для проведения митапов, вебинаров и онлайн конференций. Я ожидал от сервиса таких функций:

1. интеграция с YouTube
2. Q&A сессия
3. настраиваемая страница спикера
4. возможность подключения второго (резервного) хоста, на случай разрыва и непредвиденных ситуаций
5. демонстрация экрана
6. настраиваемая музыка во время перерывов
7. нарезка финальной записи на несколько частей по каждому докладчику
8. цена: не более 50$ за один сеанс

Проведя небольшое исследование, я выбрал три варианта: zoom.us, Livestorm, BigMarker.

zoom.us

Цена: $309.98, 500 посетителей, 2 хоста

Zoom был первым сервисом, который хотелось пощупать и применить в действии, поскольку он зарекомендовал себя как стабильный продукт с качественной связью и удобным интерфейсом. При покупке пакета Видео веб-семинар Zoom у вас появляется доступ к дополнительным функциям, такие как: Q&A сессии, интеграция эфира на стриминговые сервисы, удобная панель работы организатора.

Однако есть ряд ограничений: нельзя интерактивно управлять экранами ожидания, невозможно поставить музыку для сглаживания перерывов между докладчиками, высокая стоимость для двоих организаторов.

Livestorm

Цена: 218$, 350 посетителей, 1 хост

Очень высокая цена, учитывая, что в этом тарифном плане есть только один организатор и 350 посетителей. За эту цену вас еще и ограничивают по времени события, которое составляет всего 4 часа. Это вполне достаточно для митапа, но не подойдет для длинной конференции. Плюс ко всему есть много функций, которые бесполезны в нашем случае:

• Email уведомления и приглашения
• Embedded функции для лендингов
• Платные вебинары
• CRM интеграции
• Аналитика

Хорошее all-in-one решение, но абсолютно не ложится в концепцию простого митапа для открытого сообщества, а скорее подходит большим компаниям.

BigMarker

Цена 189$, 500 посетителей, 2 хоста

Основные особенности BigMarker:

• Проведение неограниченного количества вебинаров;
• Демонстрация нескольких экранов;
• Шейринг презентаций;
• Оформление страниц спикера;
• Запись конференций;
• Q&A-сессия в режиме реального времени;
• Интеграция с Youtube.

Возможности платформы были вполне достаточны для наших целей, но платить каждый месяц по 189$ выглядит достаточно большой платой для нашего сообщества, учитывая отсутствия спонсоров и монетизации.

Все вышеперечисленные сервисы не предлагают единоразовое событие за фиксированную цену, а хотят заключить сделку на ежемесячных платежах. Так что если вы планируете проводить 1-2 митапа в месяц скорее всего вам они не подойдут.

Стриминговые сервисы

После неудач с платными платформами я решил использовать стриминговые сервисы напрямую, настроив всю инфраструктуру на своей стороне. На выбор у меня было 2 сервиса: Twitch и YouTube. Twitch как платформа для стриминга очень неплоха и позволяет привлечь больше зрителей, благодаря внутренней системе рекомендаций. С недавнего времени это не просто площадка для игровых стримов, а совокупность различных направлений, включая искусство, музыку, стримы по программированию и обычного общения. Не так давно на твиче проводилась конференция Flutter Week, было интересно посмотреть на организацию похожих ивентов от зарубежных коллег.

YouTube имеет более простую систему для онлайн вещания, однако после стрима можно легко нарезать видео по каждому докладу, которое будет доступно в течении нескольких часов.

Большинство стримеров используют Restream.io замечательная система для одновременного стриминга на большое количество сервисов, включая YouTube и Twitch.

Для первого раза решено было использовать только YouTube как наиболее простой и менее затратный по настройке вариант.

Настройка программы для вещания

После выбора платформы необходимо настроить программу для потокового вещания. Стандартом де-факто является Open Broadcaster Software (OBS). Настройка особого труда не составляет, есть полно ресурсов описывающие подробные шаги по настройке звука, битрейта, интеграции со стриминговыми сервисами.

В этой статье мы коснемся только звуковых дорожек, настройки сцен и переключении между сценами.

1) Настройка звуковых дорожек

Для простейшего митапа достаточно трех звуковых дорожек. Первая ваш микрофон, который используется только стримером и транслирует ваш голос зрителям. Вторая дорожка источник медиа, который представляет из себя подготовленный MP3 файл с музыкой, который включается во время перерывов, в начале и в конце стрима. Любая музыка должна быть свободна от авторских прав, иначе финальное видео удалят с видеохостинга и, возможно, заблокируют аккаунт. Третья дорожка используется для трансляции голоса спикера. По факту, третья дорожка использует звук вашей системы, поэтому заранее надо отключить все уведомления системы и всевозможные посторонние звуки.

При настройке важно учитывать, что с базовой конфигурацией вы не можете слышать звук вашей системы в наушниках, когда транслируете этот самый звук на стрим. Для этого надо создать Multi-Output Device, совместив при этом выход ваших наушников и выход звука на стрим.

Основной микшер аудио показан на рисунке ниже. Во время стрима контролируйте, чтобы уровень громкости не заходил в красную зону и слегка заходил в желтую зону, иначе разные дорожки будут звучать с разной громкостью, раздражая слушателей.

2) Начальная сцена (StartScene)

Начальная сцена появляется сразу после запуска стрима и используется как заставка в перерывах между докладами. Состоит она из картинки на весь экран и медиа файла, который используется как музыкальное сопровождение. После настройки экран будет выглядеть следующим образом:

Важно помнить, что микрофон и звук системы должны быть выключены, а источник медиа включен, иначе музыка будет накладываться на шумы из микрофона и невозможно будет заранее созвониться с докладчиком.

3) SpeakerOneScene и SpeakerTwoScene

После того, как зрители собрались на стриме можно использовать экран первого спикера. Этот экран очень простой и состоит из заранее подготовленной одной картинки. В будущем эта картинка будет использоваться как превью отдельного видео на YouTube.

Переключив на эти экраны не забудьте включить дорожку с вашим микрофоном, чтобы сказать пару вступительных слов. В идеале, докладчик должен уже созвониться с вами и быть готовым начать свое выступление.

4) ShareScene

Большую часть митапа вы будете находиться на сцене с демонстрацией вашего экрана. Для связи можно использовать все, что нравится: Skype, Google Meet, Zoom. Сюда также можно добавить надписи о докладе и спикере, картинки спонсоров и партнеров, фоновые заставки и прочее.

Во время доклада у вас должен быть выключен микрофон, чтобы не было шумов и включена дорожка звука системы. Таким образом зрители будут слышать спикера и видеть его экран.

Также необходимо учитывать, что размер вашего экрана скорее всего не совпадает с размерами, принимаемые стриминговым сервисом, поэтому придется заполнять пустое место либо фоновым изображением, либо менять видео настройки и размер отображаемого полотна.

День митапа

Прежде всего необходимо подготовить инструкцию для стримера, потому что быть режиссером занятие непростое и без определенной подготовки можно быстро растеряться. Для себя я подготовил такую последовательность действий:

Обозначения:

Mic 1 звук микрофона

Mic 2 звук системы

+ включено
выключено

====

запустить стрим

выбран StartScene, Mic 1, Mic 2

проверить, что стрим запущен, музыка играет

ждем 5-10 минут...

позвонить спикеру

выбран SpeakerOneScene, + Mic 1, Mic 2

вступительная речь...

выбран ShareScene, Mic 1, + Mic 2

доклад...

выбран SpeakerOneScene, + Mic 1, Mic 2

объявить о перерыве...

выбран StartScene, Mic 1, Mic 2

ждем 5-10 минут...

позвонить спикеру

выбран SpeakerTwoScene, + Mic 1, Mic 2

представление спикера...

выбран ShareScene, Mic 1, + Mic 2

доклад...

выбран SpeakerTwoScene, + Mic 1, Mic 2

объявить об окончании...

выбран StartScene, Mic 1, Mic 2

Остановить стрим

Рекомендую назначить горячие клавиши на все операции и потренироваться с участниками митапа, чтобы каждый из вас понимал в какой момент времени что нужно делать.

После завершения трансляции видео сразу будет доступно на YouTube. Используя встроенный редактор можно сразу нарезать 2 видео и поставить их в обработку. Через несколько часов эти видео будут доступны на вашем канале.

Что получилось?

Каждый спикер, в качестве поощрения за потраченные усилия, получил небольшую коробочку с футболкой нашего сообщества и стикер пак с логотипами Dart & Flutter.

Подводя итог, можно сделать вывод, что провести онлайн-митап проблемы не составляет, но требует определенной подготовки и усилий в проведении. Если есть бюджет и нет времени разбираться можно использовать платформы, которые заточены на проведение подобных конференций. Если бюджета нет стриминг лучшее решение, которое доступно каждому.

В качестве улучшений к стриму можно использовать различные плагины, например, донаты, вывод активной аудитории в режиме реального времени, вывод комментариев. Также для постоянных стримов вам потребуется отдельная звуковая карта, хороший микрофон, достаточно мощный компьютер и гигабитный интернет канал для передачи картинки высокого качества.

Если вам интересны подобные стримы по Flutter следите за анонсами в нашем Telegram-канале.

Мы планируем делать следующий митап с новыми спикерами и новыми актуальными докладами. Поэтому приглашаем заинтересованные компании стать спонсорами нашего события. У нас есть действительно интересные предложения для партнеров, включая аудиторию нашего канала для вакансий, где многие участники активно ищут работу. По всем вопросам пишите в телеграм: @matreninAnton, @vasilich6107или на почту.

Популярность веб-конференций и направления коммутирования сигналов

Аппаратные устройства

Потоковые видеокоммутаторы

Модель	VR-1HD	VR-4HD	VR-50HD MK II
Краткое описание	Вещательная студия формата подключил и работай.	Полноценная студия стандарта HD в формате компактного устройства.	Расширенная модель, вобравшая мощный функционал студийного микшера с возможностью потоковой трансляции.
Входные интерфейсы	3х HDMI	4х HDMI	4х HDMI, 4х SDI
Выходные интерфейсы	MAIN: 1х HDMI; MONITOR: 1х HDMI; THRU connector: 1х HDMI (from HDMI 3rd); USB: 1x USB (type B);	MAIN: 1x HDMI or RGB/COMPONENT; PREVIEW: 1x HDMI; USB: 1x USB (type B);	2x SDI (PGM OUT, AUX OUT); 3x HDMI OUT (PGM OUT, AUX OUT, MULTI-VIEW OUT); 2x Analog RGB/HD-Component (PGM OUT, AUX OUT); USB: 1x USB (type B);
Микрофонные входы	2 XLR/TRS	4 комбо-разъема XLR/TRS	6 комбо-разъемов XLR/TRS
Линейные входы	1 стереофонический RCA	1 стереофонический RCA + 1 стереофонический миниразъем	2 стереоджековых 1/4" + 2 стереофонических RCA
Дополнительные возможности	Выход USB 3.0 для онлайн трансляции, захвата и выдачи аудио-сигналов	Выход USB 3.0 для онлайн трансляции, захвата и выдачи аудио-сигналов	Выход USB 3.0 для онлайн трансляции, захвата и выдачи аудио-сигналов
Стоимость РРЦ (конец 2020 года)	105'500 руб	224'800 руб	528'900 руб

Модель	ATEM Mini	ATEM Mini Pro	ATEM Mini Pro ISO
Краткое описание	Модель имеет 4хHDMI входа, выходы 1хHDMI и 1хUSB, а также 2х микрофонных входа.	В дополнении к модели mini, модель Pro имеет возможности записи в H.264 на флеш-диски USB, обеспечивать потоковую трансляцию через Ethernet. Имеется многооконный режим (до 4х источников).	В дополнении к модели Pro, модель ISO позволяет вести запись до 5ти отдельных видеопотоков в H.264. Сохранять проектный файл DaVinci Resolve для дальнейшего монтажа.
Видео входы	4х HDMI	4х HDMI	4х HDMI
Видео выходы	1хHDMI 1xUSB	1хHDMI 1xUSB	1хHDMI 1xUSB
Разрешения	Up to 1080p60	Up to 1080p60	Up to 1080p60
*support input standards up to 1080i/p60 **поддерживают автоматическое преобразование форматов на всех входах HDMI
Аудио входы	2х (mic) 3.5mm miniJack (stereo)	2х (mic) 3.5mm miniJack (stereo)	2х (mic) 3.5mm miniJack (stereo)
Multiview	-	+	+
Стриминг	С помощью бесплатного ПО	Через Ethernet порт	Через Ethernet порт
Запись на USB-флеш диски	-	+	+
Стоимость РРЦ (конец 2020 года)	34'790 руб	59'900 руб	91'990 руб

Получается, что для потокового вещания компьютер не нужен, а управление можно настроить хоть с телефона (ПО присутствует), подключив микшер и телефон к точке доступа wi-fi.

Модель	UС9020, UС-9020
Краткое описание	Портативное устройства для микширование многоканального видео и звука с возможностью потоковой трансляции.
Видео входы	1x HDMI (до 4K@60Гц); 2x HDMI (до 1080@60Гц, переключаемые)
Видео выходы	1x Loop-Thru HDMI (до 4K@60Гц); 1 x HDMI (PGM) (до 1080@60Гц); USB 3.0
HDCP	Не поддерживается
Аудио входы	Деэмбедирование из HDMI; 1x микрофонный вход, 6,5 мм (dual mono); 1x линейный вход, RCA
Аудио выходы	Эмбедирование в HDMI; 1x разъем линейного выхода, 3,5 мм (стерео)
Запись на USB-флеш диски	Через USB-порт
Стоимость РРЦ (конец 2020 года)	136'030 руб

Модель	KMU-200
Краткое описание	Устройство все в одном, позволяет переключать, микшировать звук, вести запись и потоковую трансляцию.
Видео входы	1x HDMI 2.0 (up to 3840x2160p@60); 1x HDMI 1.4 with Loop through (up to 1920x1080p@60)
Видео выходы	2x HDMI 1.4 (PGM, AUX) (up to 1920x1080p/i@60)
HDCP	Не поддерживается
Аудио входы	2x XLR(Mic); 2x RCA
Аудио выходы	2x Unbalanced RCA
Запись на SD-карты	Присутствует
Стоимость РРЦ (конец 2020 года)	359'325 руб

Модель	MXC-500
Краткое описание	Микшер с возможностями работы с различными камерами, использовать как 5-и канальный аудиомикшер. Стримить, вести запись на карты SD. И все это в удобном едином корпусе.
Видео входы	4x SDI; 2x HDMI (up to 1920х1080i/p);
Видео выходы	1x SDI (PGM); 2x HDMI (PGM, multiview) (1920x1080i/p);
HDCP	Не поддерживается
Аудио входы	Деэмбедирование из SDI, HDMI; 2x XLR/TRS;
Аудио выходы	Эмбедирование в SDI, HDMI; 2x LINE L и R;
Запись на SD-карты	Присутствует
Стоимость РРЦ (конец 2020 года)	220'000 руб

Заключение