Всем привет! Новый выпуск нашего «Вестника» по ML и дата-аналитике получился очень насыщенным и разносторонне полезным. Во-первых, сразу несколько объемных ликбезов по LLM – на английском языке, но в нашей сфере по-другому никак. Зато есть очень толковый русскоязычный текст про актуальные подходы к ELT – нашел здесь, на Хабре. Еще много полезностей для любителей рыночных отчетов, красочных сборок инструментов и так далее. Точно обогатитесь парочкой говорящих скринов.

Еще больше полезных текстов по DataOps и MLOps, а также целое комьюнити на почти 1,5К человек — в Telegram-сообществе «MLечный путь».

Воспользуйтесь навигацией, чтобы выбрать интересующий вас блок:

→ Теория
→ Мнение
→ Практика
→ Обзор рынка
→ Инструменты
→ Видео

Теория

All You Need to Know to Build Your First LLM App

Большая статья на Medium (осторожно, количество бесплатно просматриваемых статей ограничено) для тех, кто хочет создать собственную LLM. Выглядит как хорошо проиллюстрированный мини-учебник для тех, кто уже понимает базовые вещи. Большое количество аспектов разложено по полочкам и со схемами. Есть даже примеры кода. Можете попробовать добавить в нее свой контекст и использовать на благо бизнеса.

Intro To LLMOps

Еще один пример образовательного контента по LLM. На сайте Arize AI появился новый курс по LLMOps, который можно освоить за несколько часов. Для новичков и тех, кому нужно более глубокое погружение, не подойдет. Но для золотой середины, владеющей нужной математикой, — самое то. Пока в нем три раздела:

• эмбединги, сокращение размерностей, механизмы внимания и т.д.),
• LLMOps for Developers (Prompt Engineering, Langchain и evaluation),
• LLMs in production (Deployment, metrics, anomaly detection).

Emerging Architectures for LLM Applications

В блоге Andreessen horowitz снова годный контент. На этот раз ребята представили понятную схему со стеком приложений для работы с LLM и разобрали ее по кусочкам. Отлично для систематизации знаний и определения белых пятен в работе с LLM.

Актуальные подходы к ETL. Или EL-T? Технологический разбор

Классный разбор от ребят из «Инфосистемы Джет» про то, куда, как и в каком порядке можно поставить в аналитическую систему наши любимые Extract, Transform, Load. Теорию разложили на практике, приведя в пример проект, который они реализовали для финансовой компании. Читается интересно и даже на русском языке!

Data Warehouses: The Undying Titans of Information Storage

Если вы еще не разобрались с понятием DWH, дайте шанс этому тексту. Подробный и качественный материал, охватывающий историю появления, борьбу и последующее единение с Data Lake, а также альтернативные подходы к хранению данных.

The Great Data Mesh Debate: Will It Sink or Swim?

Текст подтверждает, что Data Mesh-подход — это не столько про техническую реализацию, сколько про изменения в менеджменте и процессах. Автор рассматривает основные принципы и сложности при внедрении необходимых практик. Правда, ответа на вопрос «Утонет Data Mesh или нет», заявленный в заголовке, в тексте я так и не нашел.

Data Products: Strategic Data for AI and Machine Learning

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

Мнение

What Does GPT-3 Mean For the Future of MLOps

В блоге Neptune, как обычно, классная статья. На этот раз — с обсуждением использования языковых моделей в рамках MLOps. Текст — расшифровка Q&A-сессии нескольких специалистов, можно послушать в виде подкаста. Получилось достаточно комплексно рассмотреть влияние LLM на дальнейшее развития инструментов и принципов production ML.

The Golden Age of Open Source in AI Is Coming to an End

Название статьи говорящее: кажется, будущее настоящих Open Source-моделей печально. Статистика из статьи оптимизма не добавляет — достаточно посмотреть на некоторые данные, собранные автором. С другой стороны, каждый хочет заработать на своем интеллектуальном труде. Ну и вопрос финансирования разработок никуда не уходит. Чтобы разрабатывать Open Source серьезного уровня, необходимы ресурсы.

Можно наблюдать стремительное падение свободных лицензий на использование моделей.

Pros and Cons of Multi-Step Data Platforms

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

Основные вызовы при их построении:

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

Практика

Кейс внедрения Dbt в «Детском Мире»

В этот раз кейс один, но зато есть очень любопытный. Руководитель Big Data-платформы в «Детском мире» рассказал об опыте внедрения инструмента Dbt. В целом, стек у компании интересный: Zeppelin, Airflow в Kubernetes, Gitlab, Spark.

Обзор рынка

Machine Learning Operations Market UPD 16 June 2023

Актуальная версия отчета по рынку MLOps. Понятно, что оценки каждого агентства отличаются и единого правильного способа не существует, но самое интересное в таких ответах — выводы и рассуждения. Так, нам обещают мировой CAGR (совокупный среднегодовой темп роста) — 38,5%. Также из отчета видно, что тренд на on-prem есть не только в России, но и в мире. Это печально.

State of data 2023

Ребята из Airbyte опросили 886 респондентов и выкатили отчет о состоянии рынка аналитики данных. Итоги оформлены стильно, но некоторые визуализации спорные и трудно читаются. Если интересны топы инструментов в разных категориях, вам будет любопытно. В отчете также можно найти данные по самым популярным YouTube-каналам, подкастам и сообществам.

В категории оркестраторов лидирует self-hosted Airflow.

The State of Data Engineering 2023

В дополнение к предыдущему тексту — landscape инструментов для дата-инжиниринга и некоторые мысли о сфере от lakeFS. Сильных изменений в сравнении с предыдущим отчетом я на заметил, но, если вы с ним не знакомы, будет полезно. Для развлечения составители решили уточнить у ChatGPT, как бы он оценил статус дата-инжиниринга в 2023 году в 50 словах.

All the Nvidia news announced by Jensen Huang at Computex

В одной небольшой новости сведены все важные анонсы Nvidia с выставки Computex. Особенно ужасает DGX GH200. Теоретический объем видеопамяти — 144 ТБ. Даже подумать страшно, сколько это будет стоить.

Инструменты

MLOps Landscape in 2023: Top Tools and Platforms

Neptune собрала собственный список крутых инструментов и платформ для MLOps. Не очень понятно, почему в списке нет ClearML — награду в этом году платформа получила, а в топ не попала. При этом MosaicML в перечне есть. Какова логика выбора составителей — нет ответа.

How to Deploy an AI Model in Python with PyTriton

Лично я очень ждал этого события. Не конкретно появления питоновской библиотеки для Triton, а в целом — любой верхнеуровневой либы. С ванильным Triton разбираться то еще удовольствие, хотя по возможностям работы с GPU я аналогов не знаю. Теперь есть повод для массовой волны изучения и добавления в свой production. Мы в команде тоже изучим, когда появится время, и расскажу — может, даже здесь, на Хабре. Говорят, что работать с ней так же просто, как с Flask.

Announcing Motherduck: hybrid execution scales DuckBD from your laptop into the cloud

На рынке облачных аналитических платформ прибыло — состоялся релиз MotherDuck. Внутри все основано, что следует из названия, на DuckDB. Обещают serverless, notebook-like UI, нативную работу с S3 и прочие «blazing fast». Доступ пока по инвайтам, будет интересно понаблюдать за публичным релизом.

26 Data Catalogs – From Open Source To Managed

Большой каталог с каталогами! В списке и проприетарные, и с открытым кодом. Есть довольно распространенные Amundsen, DataHub и Castor, но, признаюсь, большинство названия вижу первый раз. Так что есть к чему присмотреться и что дополнительно изучить.

Видео

Faster LLM Inference: Speeding up Falcon 7b (with QLoRA adapter)

Продолжительность: 18 минут

Нашел интересный YouTube-канал по AI-разработку. Уже даже актуальные модели разбираются, объяснения вполне понятные — прояснил для себя несколько моментов. Вдохновился и тоже поднял Falcon 7B. При моих настройках модель заняла в памяти 15 Гб и вполне прилично отвечала на базовые запросы. На русском можно ничего не спрашивать — я проверил 🙂

NEW “Orca” Open-Source Model

Продолжительность: 19 минут

У меня от этого видео мурашки по коже. Автор разбирает статью сотрудников Microsoft, которые частично критикуют ChatGPT, но при этом предлагают новый подход к обучению моделей. В частности, пользоваться «чатом» в качестве промежуточного звена для поэтапного обучения — от простого к сложному. Метрики получаемой модели при меньшем количестве параметров удивляют. Очень советую посмотреть, если вы research supervisor или вокруг этого.

Introduction to MLOps at the Edge

Продолжительность: 46 минут

VP по продукту и дизайну в компании barbara рассказывает про особенности организации MLOps для Edge-устройств, а в конце показывает свой продукт. По некоторым аспектам продукта есть вопросы, но механики работы с моделями можно подсмотреть. Больше понравилась первая часть про концептуальные аспекты и кейсы. Еще один вариант, который можно сравнить с KubeEdge.

MLOps в билайн: как катить машинное обучение в production силами DS

Продолжительность: 36 минут

Новый кейс с опытом построения ML-систем в отечественной компании — только на этот раз в формате видео. Head of Data Science в «Билайне» рассказывает, как они внедряли MLOps-процессы, с чего начали, с какими проблемами столкнулись.

Привет, Хабр! Сегодня хотим представить подборку книг, которые было бы полезно прочитать любому программисту. Многие из них, вероятно, вами уже прочитаны, но если нет, рекомендуем ознакомиться. В подборке 7 книг — конечно, это субъективный выбор. Но если у вас есть любимые книги по разработке, которые вы можете рекомендовать, расскажите о них в комментариях, пожалуйста.

Карьера программиста. 6-е издание (2023)

Автор: Гейл Лакман Макдауэлл

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

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

Издание подходит и новичкам, и опытным разработчикам, у которых не слишком большое количество собеседований на карьерном пути. Такое бывает частенько, так что не пропустите «Карьеру программиста».

Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих

Автор: Адитья Бхаргава

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

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

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

 Современный подход к программной архитектуре

 Авторы: Нил Форд, Марк Ричардс

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

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

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

Чистая архитектура. Искусство разработки программного обеспечения

Автор: Роберт Мартин

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

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

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

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

Паттерны проектирования API

 Автор: Джей Гивакс

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

Книга пригодится широкому кругу читателей, рассчитана она, скажем так, на подготовленного новичка.

Математические алгоритмы для программистов

Автор: Пол Орланд

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

Во-первых, это методы линейной алгебры для проведения матричных вычислений.

Во-вторых, методы исчисления для простого физического моделирования.

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

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

Современная программная инженерия. ПО в эпоху эджайла и непрерывного развёртывания

Автор: Дэвид Фарли

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

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

Опыт при прочтении этой книги не особо важен — любой читатель может найти для себя что-то интересное и нужное.

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

25 мая 2022 года в Рунете появился отечественный магазин приложений RuStore. В каталоге первой версии стора были представлены 100 приложений — в основном банковские и государственные продукты, которые были необходимы пользователям ежедневно. Для разработчиков с момента запуска был доступен личный кабинет для загрузки новых сервисов и игр на витрину.

Но история RuStore началась ещё в марте. В команде было 30 человек, которым в жёсткий срок нужно было выкатить MVP магазина мобильных приложений. Для пользователей нужно было предоставить:

• поиск приложений;

• скачивание и обновление;

• добавление приложений разработчиками.

Засучив рукав, команда приступила к работе.

Магазин приложений — что это?

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

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

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

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

Где взять приложения

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

С первыми разработчиками мы вместе проходили весь путь от установки до запуска, параллельно обрабатывая баги и ошибки. Модераторы вручную проверяли заявки, заносили название APK, проверяли безопасность с «Касперским», делали скриншоты и принимали решение о допуске на витрину.

Процесс проверки загружаемых APK через сервисы «Касперского» на тот момент не был автоматизирован. Несмотря на то, что у нас был белый список разработчиков, мы всё равно вручную обрабатывали каждое приложение. После проверки информация передавалась в ИБ-департамент.

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

Что в имени тебе моём… и в дизайне

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

Параллельно шла работа над брендингом. Магазин можно было назвать «Полка», «VK Store», «VK Depot» или «Киоск». Всего было придумано 12 названий, но в итоге решили остановиться на RuStore. Мы исследовали, как пользователи и разработчики воспринимают разные названия. Оказалось, что «store»/«стор» — понятный и узнаваемый термин для магазина приложений, а «Ru» — его отличительный признак. Получилось универсальное название, которое, к тому же, легко находится в поисковике.

В качестве фирменного шрифта взяли VK Sans — для скорости и сохранения преемственности при запуске. Но на сайте и в приложении к этому времени уже использовали Roboto как основной шрифт.

Общую форму фирменного знака заимствовали из логотипа VK: квадрат с углами, закруглёнными по суперэллипсу. А потом экспериментировали, что может быть внутри этой формы.

В итоге остановились на стопке из трёх приложений, которая отражает главную ценность RuStore — контент. Успели заодно потестить и другие цветовые схемы.

День Х

К моменту запуска у нас уже было готовое приложение RuStore, лендинг для его загрузки, консоль разработчика и табличка для администратора и модератора.

Уже через месяц после запуска на витрине было доступно более тысячи приложений, RuStore установлен на устройства более 500 тысяч раз, а количество скачиваний превысило 1,1 млн. Можно сказать, что мы попали в потребности аудитории.

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

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

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

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

А что сейчас?

Сегодня RuStore — это более 8 тысяч приложений и 10 миллионов пользователей. Всего чуть больше, чем за год приложение существенно изменилось, в «RuStore Консоли» появилось множество инструментов для разработчиков, поддерживает в актуальном состоянии полноценный Help.

Также в этом году в RuStore появились:

• адаптация витрины для планшетов и TV;

• монетизация для самозанятых;

• новые API по загрузке приложений и работе с отзывами;

• новые SDK;

• возможность для загрузки своих приложений иностранным разработчикам;

• тёмная тема;

• RuStore TV;

• и другие функции.

А еще у нас есть Телеграм канал c новостями и чат для разработчиков, где вы можете задавать свои вопросы по интеграции и инструментам, делиться мыслями и идеями друг с другом, просить совета у коллег и общаться с командой RuStore 🙂

Наша рубрика «Где работать в IT» — это интервью с интересными IT-компаниями. Представители индустрии делятся подробностями о рабочих процессах, отвечают на вопросы о найме, условиях, командах и технологиях. 

В этом выпуске мы расскажем вам о команде разработки СУБД, а также платформы управления и мониторинга баз данных Tantor (OOO «ТАНТОР ЛАБС», входящее в ГК «Астра»).

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

→ оценить работодателя

Обо всех процессах в команде Tantor нам подробно рассказали:

О компании

Tantor — бренд российской СУБД, а также платформы управления и мониторинга баз данных. Разработчик — OOO «ТАНТОР ЛАБС», входит в группу компаний «Астра» с 2022 года.

Оценка ГК «Астра» на Хабр Карьере в 2022 году — 4,77 из 5. Самые высокие оценки сотрудников компания получила за интересные задачи, адекватную зарплату, отношения с коллегами, связь с топ-менеджментом, современные технологии, карьерный рост, признание результатов труда и за то, что компания делает мир лучше. Профиль «Астры» на Хабр Карьере.

Об условиях работы

Какой сложился рабочий график и как относитесь к переработкам в вашей компании?

Виктория, директор по развитию:

У нас гибкое начало рабочего дня. Кто-то — сова, кто-то — жаворонок. Мы не ограничиваем сотрудников рамками. Переработки бывают, но только при острой необходимости или при желании сотрудника сделать быстрее и больше. Главное — не довести себя до выгорания к моменту, когда действительно нужно будет выложиться.

Также в компании есть поддерживаемая база знаний и процедура Knowledge sharing (обмен знаниями). С этими инструментами можно решить некоторые вопросы и не беспокоить коллег во время отпуска или выходных. 

Какие бытовые условия ждут нового сотрудника на рабочем месте: мебель, техника, тип помещения, искусственное или естественное освещение, дополнительные удобства в офисе?

Виктория, директор по развитию:

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

Алексей, коммерческий директор: 

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

Есть ли возможность удаленной работы?

Алексей, коммерческий директор:

Можно работать в удаленном режиме, гибридном и в офисе. На выбор несколько локаций в Москве. Доступность офиса от метро — 30 метров, от МЦК — 500 метров. 

Рустам, старший инженер поддержки:

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

Александра, HR-менеджер:

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

Какой социальный пакет получают сотрудники?

Александра, HR-менеджер:

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

Какие бонусы, премии и компенсации предусмотрены в компании?

Виктория, директор по развитию:

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

Александра, HR-менеджер:

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

Какие есть перспективы для образования и личного развития у сотрудников?

Вадим, генеральный директор:

Сейчас команда активно растет, и до конца года нас будет уже 80 человек. Но, к сожалению, на рынке не очень много специалистов, которые разбираются в C и PostgreSQL одновременно. Поэтому мы взяли на себя миссию привлечь в мир СУБД больше людей. Для этого команда Tantor участвует в организации PostgreSQL Dev Bootcamp, на который привлекает молодых специалистов. И если у кого-то так же, как и у нас, есть желание передавать опыт и обучать стажеров, то в команде вам будут рады.

Наша команда участвует в международных конференциях по PostgreSQL.

Рустам, старший инженер поддержки: 

Работа в компании достаточно динамичная, и новые знания мы получаем практически каждый день. Что-то изучаем самостоятельно, а какие-то вещи узнаем от более опытных коллег. Здесь не получится сидеть с утра до вечера с «чай печенька макать». Плюс ко всему можно пройти дополнительное внешнее обучение, если обосновать необходимость. 

Александра, HR-менеджер:

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

О найме

Во сколько этапов проходит наём? И что ожидает соискателя?

Александра, HR-менеджер:

Обычно этапа два: первичная встреча с HR-менеджером, на которой оцениваются мягкие навыки и минимальная техническая часть; вторая встреча — общение с командой. Чаще всего это лид и технический директор. Но есть команды, в которых общается только лид. Case-by-case, как говорится.

Михаил, директор по архитектуре решений:

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

Илья, разработчик:

Процесс найма предполагает два этапа: с рекрутером и техническим директором. На собеседовании ожидают услышать достижения на других проектах и представление о C и Linux.

Даете ли вы тестовое задание кандидатам? Как все устроено?

Виктория, директор по развитию:

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

Алексей, коммерческий директор:

Лучшее тестовое задание — это установить наши продукты и рассказать о впечатлениях от использования. 

Как отличается подход к найму в зависимости от позиции и стека?

Рустам, старший инженер поддержки:

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

Алексей, коммерческий директор:

С учетом специфики IТ-индустрии в первую очередь интересно, как кандидат вольется в команду. Даже отсутствие каких-то навыков не столь важно, как умение находить контакт с коллегами. Поэтому все собеседования индивидуальны.

Какая фраза кандидата на собеседовании точно заставит вас выкинуть его резюме?

Рустам, старший инженер поддержки:

От кандидатов, которые приходят к нам на интервью, не хотелось бы услышать пренебрежение в сторону отечественных операционных систем и других разработок. Те продукты, которыми мы все привыкли пользоваться, не сразу стали топовыми. Прошли годы, прежде чем они достигли определенного уровня. У Astra Linux есть все шансы встать на одну ступень с самыми популярными на текущий день операционными системами. Также и у СУБД Tantor есть все возможности стать лидирующим продуктом на рынке. И не только в России. А вот если кандидат готов вкладываться вместе с командой в развитие продукта, то нам по пути.

Виктория, директор по развитию:

«Мне это не особо интересно, а вы сколько платите?».

Илья, разработчик:

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

Кого последнего вы уволили и почему?

Алексей, коммерческий директор:

Я еще никого не увольнял, и, надеюсь, не придется.

Виктория, директор по развитию:

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

Как происходит онбординг нового сотрудника?

Михаил, директор по архитектуре решений:

У нас есть постоянно поддерживаемый Onboarding checklist (план адаптации) со списком задач, которые новый сотрудник должен завершить за время испытательного срока. Каждому новичку предоставляется buddy (наставник) из отдела, который будет помогать в выполнении задач, но не делать их за сотрудника.

Алексей, коммерческий директор:

Полный фарш! Начиная с наличия наставника, телеграм-чатов, тестовых заданий, заканчивая непосредственной помощью по мере выполнения задач.

Виктория, директор по развитию:

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

О команде

Какая методология разработки у вас используется и почему? 

Виктория, директор по развитию:

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

Алексей, коммерческий директор:

Стараемся все документировать в Jira и на корпоративном портале, чтобы не переписывать по сто раз.

Каковы размеры и структуры команд?

Александра, HR-менеджер:

В компании ООО «ТАНТОР ЛАБС» несколько департаментов: разработка, сопровождение, а также архитектура и автоматизация решений. Разработкой занимается порядка 25 человек. В сопровождении работает около 10 человек, в департаменте архитектуры и автоматизации — тоже примерно 10. На данный момент размер команды — порядка 50 сотрудников, но мы постоянно растем и до конца года планируем расшириться до 80 человек. 

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

Виктория, директор по развитию:

Исходя из опыта, уровня компетенций и навыков. Джуниор — решение мелких и в основном типовых задач; уровень самостоятельности — низкий. Мидл — решение крупных задач и разработка предложений в части выбора технологических решений; уровень самостоятельности — высокий. Сеньор — влияние на ход проекта, участие в разработке архитектурных решений; технический лидер направления.

Алексей, коммерческий директор:

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

Кто чаще возглавляет команды: продуктовый специалист или технический?

Вадим, генеральный директор:

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

Как часто люди меняют команды?

Виктория, директор по развитию:

На текущий момент мы на стадии активного роста. Кейсов со сменой команды нет. 

Рустам, старший инженер поддержки:

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

Что важнее: софт-скилы или хард-скилы?

Вадим, генеральный директор:

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

Как много собраний у вас проводится? Есть ли особые подходы к ним?

Александра, HR-менеджер:

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

Как вы боретесь с выгоранием сотрудников?

Александра, HR-менеджер:

HR-служба развивает спортивные комьюнити, чтобы коллеги могли переключаться. У нас есть киберспортивные команды по CS:GO и Dota 2, теннисный спорт, корпоративный футбол, волейбол, баскетбол. А сообщество бегунов объединяет коллег из разных городов. Спорт для нас — это хороший способ выплеснуть эмоции, усталость и зарядиться бодростью.

Виктория, директор по развитию:

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

Рустам, старший инженер поддержки:

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

Михаил, директор по архитектуре решений:

Внимательно следим и слушаем мнения сотрудников. Пока не было случаев в команде.

Какие языки, фреймворки и библиотеки используются на проекте?

Александра, HR-менеджер:

В зависимости от команды стек отличается. Для ребят из департамента архитектуры и автоматизации решений важно разбираться в технологиях практик DevOps: Terraform, Ansible, Docker и других. Особое внимание уделяется облачным технологиям. Разработчикам СУБД важно знать C / C++. Для тех, кто создает прикладное ПО, приветствуется знание Go. Frontend-разработчики пользуются Angular и Typescript. Для тестировщиков в приоритете знания JavaScript с Cypress. Для работы со скриптами и различной автоматизации используются Python, Bash и Shell. А так как наша компания работает с базами данных и является частью ГК «Астра», то специалисты должны разбираться еще в PostgreSQL и Linux.

Что вы можете рассказать об архитектуре проектов?

Илья, разработчик:

СУБД Tantor — это PostgreSQL с нашими фичами и расширениями. Мы скачиваем исходный код с GitHub, добавляем собственные наработки с помощью патчей, проверяем на различных операционных системах с помощью Docker. В итоге получаем установочный пакет, который выдаем клиенту, а он его устанавливает и затем с помощью платформы Tantor подключаемся к нему для администрирования и мониторинга.

Какая у вас принята политика код-ревью?

Илья, разработчик:

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

Михаил, директор по архитектуре решений:

Как часть процесса Knowledge sharing, коллеги просматривают код друг друга. Как правило, минимум раз в неделю или по завершенности задачи, сотрудник представляет проделанную работу, включая написанный код, всей команде. В процессе презентации особое внимание уделяется качеству кода, а также соответствию Industry Best Practices. Отдельно происходит код-ревью в процессе работы для инженеров с начальным опытом. Для каждого нового инженера выделяется ментор, который будет помогать и проверять задачи.

Как тестируется код?

Илья, разработчик:

Мы пишем регрессионные тесты. В PostgreSQL есть утилита (pg_regress), которая создает временный кластер, где создаются и тестируются SQL-запросы, расширения и функции бэкенда PostgreSQL.

Михаил, директор по архитектуре решений:

Мы ответственны за проведение автоматических тестов перед переводом артефактов в репозитории для использования в рабочей среде.

Как устроен процесс документации и ведения базы знаний на проектах?

Алексей, коммерческий директор:

База знаний наполняется вводными данными с пилотных проектов. Там мы выявляем первичные вопросы и формируем правильные ответы.

Рустам, старший инженер поддержки:

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

Михаил, директор по архитектуре решений:

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

Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

Виктория, директор по развитию:

Не более 5%. Продукт достаточно молодой (старт разработки — 2019 год), рефакторингом команда занимается регулярно. 

Михаил, директор по архитектуре решений:

Continuous improvement — одна из основных частей ITIL и других методологий управления IT. Мы находимся в постоянном процессе соответствия наилучшим практикам IT-индустрии.

Приветствую! 

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

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

Дисклеймер: Все описанные в статье действия — исключительно мой индивидуальный опыт.
Я не являюсь заслуженным и признанным специалистом ни в сфере стрим‑технологий, ни в сфере IT, поэтому решения применялись максимально простые, топорные и в меру надежные.
Главное условие состояло в том, чтобы я смог это сделать сам с минимальным участием извне, и чтобы я смог это воспроизвести без помощи. Возможно, некоторые вещи сделаны либо крайне нерационально, либо избыточно сложно, но это работает.
«Если это тупо, но работает — это не тупо.»

Я искренне стараюсь не растекаться мыслью по древу, но в то же время пытаюсь вести повествование так, чтобы были понятны мои выводы и причины принятия определенных решений. Одну из тем, а именно распределение нагрузки на отдельные потоки и ядра процессора, а так же на отдельные GPU я намеренно не стал включать, поскольку эта ветвь эволюции оказалась тупиковой в моей задаче и развивать её не имеет смысла. Пока что…
В статье я буду двигаться по пути размышлений и действий, к которым эти размышления привели и которые я предпринимал в процессе. Местами я буду перескакивать во времени и в последовательности ради удобства повествования. Прошу мне это простить. =)

Идея

В 2020 году, когда всё и все были закрыты на карантин, мне очень захотелось вернуться к реализации проекта, вдохновленного некогда популярным EarthCAM. Когда мы все были ограничены в перемещениях – было очень приятно иметь возможность поглазеть хотя бы через цифровые глаза на окружающий мир. Естественно, я не стал замахиваться на весь мир. Решил начать со своего Жилого Комплекса на окраине Москвы. 

Идея была простая (а простота – это надёжность) – разместить несколько камер в жилом комплексе на разных домах и транслировать картинку в сеть, чтобы соседи могли видеть, что происходит в жилом комплексе, в соседних дворах и переулках не покидая дом.
Я вспомнил, что ранее интересовался вопросом, тема была мне более-менее близка (ох как же я ошибался), интерес к проекту разгорелся с новой силой, и я взялся за работу.

Аналогичные проекты, которые мне удавалось найти с похожей концепцией и идеей:

• See Jackson Hole https://www.youtube.com/@Seejh
  Очень уютный проект инсталяторов CCTV в небольшом городке

• LarryRos  https://www.youtube.com/@LenskLR
  Приятный проект с камерами в небольшом городе в глубинке

• Mobotix Webcams Russia https://www.youtube.com/@msbud2
  Санкт-Петербург, этим всё сказано

• EarthCam  https://www.youtube.com/@earthcam
  Неповторимый оригинал

• NYC Timescape, человек который снимает таймлапс длиной в 30 лет, и который недавно обзавёлся онлайн трансляцией
  https://www.youtube.com/@NYCTimescape

• Легендарный — San Francisco FOG Cam https://www.fogcam.org/

• И, разумеется, первый и самый важный проект профессоров из Кембриджа — камера наблюдения за кофеваркой! (Классику нужно знать!)

Да, и годовой таймлапс я уже тоже успел снять. Он есть на канале проекта на Youtube. Качество получилось так себе, но сам факт меня не может не радовать. Много ли таймлапсов длиной в год вообще снято? Вот именно =)

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

Начало

«Хочу транслировать уличные камеры 24х7»

Задачи: 

• Непрерывная трансляция видео с CCTV камер на какую-либо платформу.

• Обязательная возможность интеграции в эти трансляции некоторой графики (плашки, заглушки, возможно рекламные интеграции, возможно интеграция иного контента)

• Возможность мониторинга в реальном времени состояния трансляции и состояния системы

• Обеспечение быстрого развертывания софта на базе компьютера с WIN10 и GPU Nvidia (объяснюсь по этому поводу ниже)

• Организация непрерывности получения видеопотока с камер или минимизация времени простоя

• Минимизация ограничений с точки зрения выбора IP камер уличного видеонаблюдения

• Максимизация количества транслируемых камер внутри одной физической машины

• Минимальное количество и сложность оборудования в местах размещения камер

Кандидаты

Забегая вперед — скажу, что я выбрал OBS Studio. Почему — рассказано в одном из следующих пунктов статьи.

Глобально было два варианта:

• Программное кодирование видео

• Аппаратное кодирование видео

Разница более менее интуитивно понятна — это просто вопрос подхода. Далее следует разъяснение:
Видеокодер – это ПО или отдельное устройство, которое преобразовывает видеоконтент в цифровой формат для потоковой передачи на целевую платформу. Далее следует гугловское видео о том, что такое видеокодер (энкодер).

Существует множество как программных (ПО), так и аппаратных решений. В гайде Google по трансляциям есть целый список. Эти приложения и устройства одобрены, а значит протестированы, Youtube’ом и, что более важно, широко используются среди стримеров.

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

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

Среди кандидатов были и другие решения, помимо OBS Studio.

Например Raspberry Pi устройства и аналогичные мини-компьютеры, или же просто аппаратные кодировщики видео. От них я был вынужден отказаться либо в силу необходимости изучать «Линукс для чайников», либо в силу полной немощности этих мини-пк в области решаемых задач.

Дополнительная причина отказа от взаимодействия с RASPBERRY будет логической ссылкой на причины выбора определенной архитектуры проекта. Это пункт «Железо» в статье.

TLDR: В общем и целом — оказалось экономически не выгодно использовать Raspberry Pi. Каждая отдельная коробка в месте размещения камеры — стоит денег, принимающий сервер нужно собрать, обслуживать и содержать, в итоге вместо 1 устройства в месте размещения (камера) и 1 сервера на моей стороне, получается по 2 устройства в каждом месте размещения (камера и Raspberry) и два сервера у меня (сервер принимающий RTMP потоки от Raspberry и непосредственно транслирующий видео-контент на платформу сервер). Далее я расшифрую сказанное рассказывая об архитектуре.

Что касается софта: разумеется, я гарантирую, в комментариях сейчас появится человек из неповторимой и прекрасной секты группы FFMPEG-Enthusiast:

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

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

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

В качестве третьего варианта я рассматривал довольно интересное решение DATARHEI | Restreamer.  Практически идеальный вариант, но он не умеет в оверлеи типа плашек Donation Alerts, и самое плохое — он кривой. Все что может в нем навернуться и упасть — падает. Он нестабилен, он лагает, он плохо работает и так далее. Даже с учетом его преимуществ — он все равно постоянно рушится и стрим может скоропостижно закончиться в любой момент. Хотя его достоинств я не отрицаю.

Так же среди решений я натыкался на множество разнообразного NVR софта типа BlueIRIS. Многие, кто слышал или видел мой проект задавали мне вопрос: «Ты что, пытаешься сделать из Youtube’a облачный видеорегистратор, да еще и бесплатный??»

Нет. Совсем нет. Это возможность просто и быстро дать доступ неподготовленным людям к камерам, которые показывают, что вокруг них происходит, не более того. Задача видеорегистратора — обеспечение безопасности. Здесь же задача другая. Хотя, врать не буду, несколько раз мои камеры помогали решить спорные ситуации, попадавшие в их поле зрения. Несколько спорных ситуаций с ДТП решились в пользу наших соседей благодаря наличию видео и возможности без проблем эти видео получить и отсмотреть.

Я все же я склоняюсь к тому, что мой проект — это не попытка сэкономить на полноценном NVR с рашаренным доступом к потоку с камер, а все таки бродкастерский проект.

Что значит NVR?
NVR — это сокращение от Network Video Recorder. Устройство является частью системы пересылки и хранения видеоинформации, получаемой с IP-камер.

Платформа

Здесь изначально, еще в 2020-м году, был выбран Youtube. Безальтернативно, увы.

Плюсы: 

• Бесконечные трансляции

• Неограниченное количество одновременных трансляций на одном канале (мой рекорд 24 одновременных стрима, рекорд который я видел лично – это 54 одновременных стрима.

• Удобство для пользователей 

• Практически идеальный плеер

• Два сервера (для основного и резервного потока)

• Удобная, хоть и не идеальная, система мониторинга трансляций

• Неограниченное ничем количество пользователей, смотрящих трансляцию.

Недостатки:

• Битрэйт, а значит и качество, трансляции ограничены 6.000 кбит/с, но для трансляции CCTV камеры — этого более чем достаточно.

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

• Бесконечные трансляции дают возможность просмотреть только последние 12 часов в плеере. (То есть тут уже точно ни о каком бесплатном облачном NVR сервисе из Youtube’a не идёт речь).

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

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

Главная сложность: Обязательная непрерывность транслируемого видеопотока.
Если видеопоток не будет поступать достаточно долго (по разным данным от 4 до 6 часов), то трансляция будет завершена автоматически со стороны Youtube.

И более того, это справедливо для «запланированных трансляций». Если использовать дефолтную опцию «Начать трансляцию» и запускать простую «трансляцию» сразу – то она завершится чуть ли ни через считанные минуты после того, как перестанет поступать видеопоток.

Как сделать:
Есть официальный гайд от Youtube | Google на эту тему, дублировать его здесь я не буду, т.к. он может устареть еще до публикации статьи.

Если кратко:

1. Регистрация аккаунта Google, его верификация, начальная его настройка.

2. Создание и оформление Youtube канала, получение разрешения на проведение трансляций на Youtube канале.

3. Переход в творческую студию, создать «Трансляцию».

4. Пункт «Управление» -> «Запланировать трансляцию».

5. Создать ключ потока трансляции и дать ему понятное имя.

6. Вставить ключ трансляции в видеокодере и запустить трансляцию в нем (что это такое — я расскажу далее).

7.  Запустить запланированную трансляцию в панели управления Youtube, когда в нее начнет попадать видеопоток по ключу.

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

Поздравляю, у вас теперь идет трансляция, которая (хочется верить) не закончится скоропостижно.

Железо

Здесь пойдет разговор как раз про выбор архитектуры.

В сущности, есть два варианта:

1. Камеры, которые имеют на борту RTMP-encoder и транслируют поток на целевую площадку сами.

2. Камеры не имеют на борту RTMP-encoder’a. Видеопоток с камер забирается сервером и уже на сервере кодируется и отправляется на платформу.

От идеи транслировать видео напрямую с камер я отказался сразу.

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

Мои первые потуги в этой области были очень забавными. Трансляция длиной 2,5 часа, потом целых 300 часов, а потом аженно 1500 часов без перерыва. Но каждый раз обрывалось все скоропостижно и внезапно, увы. Приходилось начинать заново. 

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

По части железа — собирал свой «чудо-сервак» из того, что было. Для меня главнее и важнее было выбрать не само железо, а выполнение условия на старте: использование среды Windows поскольку я испытываю полное Linux-бессилие. Поэтому все варианты с Raspberry Pi были отброшены незамедлительно. С рядом других (врать не буду, довольно ожидаемых, и неожиданных в то же время х_х) нюансов в части железа я столкнулся уже позже, и вот почему.

У нас есть камера, сервер и Youtube. Пройдёмся по процессу по шагам:

• Камера снимает происходящее и кодирует видеопоток в кодек h.264.

• Сервер забирает видеопоток с камеры при помощи протокола RTSP (в таком варианте IP камеры отдают видеопоток в большинстве случаев)

• Сервер декодирует видеопоток, накладывает на него некую графику, оверлеи, плашки или что либо другое, рендерит получившуюся картинку.

• Сервер кодирует видеопоток тем же кодеком h.264 для трансляции на Youtube  и отправляет по ключу трансляции видеопоток на сервер Youtube’а при помощи RTMP протокола.

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

Изначально я использовал процессор AMD FX8320 + GTX 550Ti. Видеокарта была нужна только для ускорения рендеринга «сцены», а для декодирования входящего видеопотока и кодирования исходящего видеопотока в стрим использовался процессор, но низкая производительность и высокий нагрев вынудили меня начать смотреть в сторону GPU Decode/Encode, то есть декодирования и кодирования видеопотока при помощи видеокарты.
Процессор AMD FX8320 не позволял декодировать более 4-х входящих RTSP потоков в FullHD/30 кадров в секунду. GTX 550Ti невозможно использовать для HW Decode/Encode видео в принципе. Она старовата для таких фокусов.

Nvenc и Nvdec

В то же время почти все GPU Nvidia, после момента времени, получили на борту аппаратные модули кодирования и декодирования видео, известные как NVENC (Nvidia Encoder) и NVDEC (Nvidia Decoder). Разные модели имею разные возможности в этой части.
На сайте Nvidia Developer по ссылке можно ознакомиться с матрицей возможностей видеоадаптеров NVIDIA в этой части: Video Encode and Decode GPU Support Matrix

На этом же Dev портале мне удалось найти информацию о производительности видеоадаптеров в задаче encode/decode в «кадрах в секунду». К несчастью, 99% тестов GPU проводимых обзорщиками никак не затрагивает тему NVENC и NVDEC, поэтому мы знаем всё о FPS в играх, и ничего о производительности в каких-либо других задачах.

Согласно информации из документации NVidia, условная RTX 3090 может декодировать 742 кадра в секунду в разрешении 1080Р(4:2:0, 8 bit) при помощи своего аппаратного NVDEC модуля.

Кодировать кодеком NVENC эта же видеокарта может 810 кадров в секунду в самом низком пресете качества. Все данные взяты из ресурса NVIDIA DOCS HUB по ссылке: NVIDIA Video Codec SDK v12.

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

Итак, процесс выглядит следующим образом:

• Модуль NVDEC декодирует полученный видеопоток

• Основные вычислительные блоки обрабатывают изображение и рендерят финальную картинку

• Модуль NVENC кодирует исходящий видеопоток в трансляцию

Дальше – максимально упрощенная математика на очень абстрактном уровне:
Один стрим – это 30 кадров в секунду декодирования и 30 кадров в секунду кодирования потока. Согласно данным из таблицы о возможностях GPU Nvidia серии 3000 — можно предположить, что одна RTX 3090 в состоянии обеспечить 24 стрима одновременно в разрешении 1080p и частоте кадров 30 к/с.

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

Что касается остального железа:

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

На данный момент используется Intel Core i7 4770k. Вся машина потребляет ровно 100 ватт/ч в рабочем режиме уже более полутора лет.

Оперативная память — тоже не является проблемой. Стоят 4 модуля по 4 Gb обычной оперативки DDR3. 16 гигабайт хватает за глаза. Каждый отдельный инстанс трансляции употребляет не более 500 мб оперативной памяти.

Материнская плата: Любая материнка с поддержкой WoL (Wake On Lan) для возможности удаленного включения в случае нужды и возможностью установки Power State, чтобы при потере электроснабжения — компьютер включался сам при возвращении питания.

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

Если вы планируете оставлять сервер дома без присмотра — обязательно удостоверьтесь в его безопасности! Халатность может привести к пожару!
Это не шутки!

На данный момент актуальный сетап, который я использую – это домашний «сервер»:

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

Одна — ранее была составной частью банкомата и работает до сих пор скорее «вопреки», а не «благодаря».

Вторая — Omny A55N28. Отличная железка, высокое качество, широкий угол. Правда за несколько лет эксплуатации я допустил ужасные ошибки, которые привели к повреждению этой камеры, и теперь она тоже «страдалец».

Видеопоток обеих камер, который я забираю — получаю через RTSP.

• Разрешение 1920х1080

• Частота кадров 30 к/сек

• Битрейт 8000 кбит/сек

Софт

Выбор видеоэнкодера

В качестве софта была выбрана простая и удобная OBS Studio, в настоящий момент это OBS ver. 29.1.3. (Указана последняя версия, для которой всё вышеописанное тестировалось и проверено на предмет работоспособности).

Что из себя представляет OBS. Это программный видеомикшер и видеоэнкодер. Как раз то, что мне нужно. Минимальные сложности, максимум функционала. Отличная поддержка, прекрасное и обширное комьюнити и так далее.
Из плюсов: 

• OBS – это полноценный полнофункциональный программный видео-микшер. Этот пункт полностью закрывает задачу в части обеспечения возможности интеграции дополнительного контента внутрь трансляции в любой момент.

• OBS поддерживает «ключи» при запуске. То есть ей можно задать параметры, с которыми она будет запускаться, например сразу при запуске приложения будет запускаться трансляция, приложение будет сворачиваться в трэй, будет отключаться превью для экономии ресурсов и так далее. Описание этих параметров и их способ применения я описывал в одной из предыдущих статей и обязательно распишу эту деталь здесь.

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

Кодирование видеопотока

В моём Гранд-Плане была идея о 24 видео потоках трансляции на одном сервере.
К сожалению, бюджет проекта колеблется около нуля, а потребительская линейка GPU NVIDIA, которые являются пределом доступного для меня железа на этом проекте позволяют обрабатывать не более 3-х, а с недавнего времени благодаря широкому жесту от NVidia — 5 потоков кодирования видео одновременно.

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

Способ простой: Патч 1337 Nvidia NVENC and NvFBC patches for Windows Nvidia drivers.
Гуглится прямо по этому текстовому запросу, но вот ссылка на всякий случай (ссылка на софт под WIN).

Сначала скачиваете подходящую версию драйвера, потом патч-тул, потом сам патч драйвера.

Патчите драйвер — вуаля! Более подробная инструкция на страничке проекта на GitHub.

Теперь количество потоков кодирования ограничено только возможностями GPU.

Подготовка и настройка софтверной части

Для себя я определил три ключевых проблемы в этой области:

1. Периодические рандомные падения и вылеты OBS, 

2. Периодические перебои с энергоснабжением,

3. Временные перебои с интернет-подключением

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

Мне было необходимо создать систему, в которой трансляция не прерывается, а в случае, если это происходит — восстанавливается всё самостоятельно, поскольку всё время, которое я проводил эксперименты над проектом, пришлось на карантин 2020 года — я, постоянно находясь дома, вынужденно и непрерывно мониторил состояние «DIY‑сервера», не отвалился ли интернет, не упала ли OBS, не вырубилось ли питание, и так по кругу. В случае, когда происходило падение OBS или вырубался сервер — приходилось ручками запускать OBS, выбирать нужные сцены, забивать настройки трансляций и запускать их снова и снова.

В какой-то момент мне это капитально надоело и встал вопрос, либо свернуть проект, либо всё-таки вспомнить, что сейчас 21-й век и всё, что приходится делать более 2-х раз — можно и нужно автоматизировать.

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

Итак, задачи: Запуск двух инстансов (копий) OBS Studio со своими конфигурациями. Автоматизация запуска OBS при перезагрузке сервера. Автоматизация перезапуска OBS в случае краша или зависания приложения.

Добавление источника видео в OBS, сборка «сцены», создание профиля трансляции

Добавление источника

На базовом уровне для того, чтобы получить видео с IP камеры в OBS нужно сделать всего 2 действия:

1. Открыть OBS

2. Добавить в доке Sources (Источники) — Media Source

Чтобы добавить сетевой источник видео, а именно IP Камеру — нужно снять галочку с чекбокса “Локальный файл” и вставить ссылку на поток камеры.
В общем виде ссылка выглядит так: rtsp://login:password@192.168.1.222:554/1/1
Ссылка на RTSP поток камеры может отличаться в зависимости от модели камеры.
Общий смысл простой: протокол, логин, пароль, @(at) далее IP адрес камеры, далее порт 554 — это стандартный RTSP порт, и далее выбор канала и потока внутри камеры. По умолчанию первый поток — является основным. Если камера расположена в вашей локальной сети — всё взлетит мгновенно.

Если камера расположена в другой сети — вам нужно убедиться, что на камеру проброшен 554-й порт для получения от нее видеопотока и проброшен 80-й порт (или 443-й если того требует камера) для доступа к ее WEB интерфейсу. Возвращаясь назад к выбору архитектуры — это одна из причин. Чаще всего обеспечить доступ из WAN к камере проще, чем поставить на месте её размещения дополнительную коробку RASPBERRY PI для того, чтобы она перегоняла RTSP в RTMP, а потом ставить у себя RTMP сервер, чтобы принимать поток от камеры.
Об этом я писал в части статьи про архитектуру и причины отказа от ряда альтернативных решений задачи.

Сцены

Теперь подробнее поговорим о сборке сцены и о том что это такое.

Сцена — это набор материалов (картинки, видео, музыка, анимации). Всё, из чего состоит итоговая, финальная картинка, которую вы транслируете — это и есть сцена.
В приложении можно заранее собрать несколько «Сцен», как в театре, буквально, для того, чтобы производить глобальные изменения в транслируемой картинке нажатием одной кнопки. Но это тема для отдельной статьи.

Сама сцена состоит из «Источников», они же «Инпуты» или «Сурсы/Сорсы». Они расположены во второй вкладке нижней Док‑Панели.

Это сам контент, который мы послойно добавляем в нашу сцену и собираем финальную картинку. Здесь могут быть видео, фото, анимации, захват окна приложения, захват игры, трансляция получаемого по ссылке медиа‑контента, практически всё, что угодно. Эти самые источники можно свободно перемещать по холсту, и трансформировать. Не забывайте, что логика «Слоёв» здесь тоже работает, поэтому слой, который ниже — будет и визуально «под» теми слоями, которые выше.

Итак, вы добавили нужный источник видео-потока, а именно камеру, в свою сцену.
Сцена собрана. Теперь нужно её сохранить и на всякий случай экспортировать.

В верхней части окна нажимаем: «Scene Collection‑ Rename» и задаём сцене имя, например «CAM1SC» (Камера 1 Коллекция сцен).

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

Теперь о профилях трансляции.

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

Все эти параметры записываются в отдельный «Профиль». Их так же можно экспортировать в виде папки и сохранить в надежное место. Итого я создал профиль, который называется CAM1PROFILE.

По умолчанию все эти настройки хранятся по адресу ниже, но позже мы это изменим.
C:\Users\Username\AppData\Roaming\obs-studio.
В подпапке «basics» — профили и сцены
В самой папке есть глобальный файл global.ini, в котором содержатся настройки самого приложения. А в том числе и:

• Размер окна

• Положение док-панелей

• Настройки рендерера приложения (Direct3D 11 или Open GL) (Это тема для отдельной статьи, если эта будет одобрена к публикации и возникнет необходимость объяснить, что это и зачем это).

• Задержка и количество попыток переподключения в случае потери соединения с интернетом.

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

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

Настройки кодирования видео-потока

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

Остановлюсь не нескольких важных деталях:

Ранее я упоминал о том, что перешел на GPU-кодирование видео, поэтому в качестве кодировщика выбираю, очевидно, NVENC H.264.
На данный момент есть альтернативные варианты GPU-энкода. Например кодировщик AV-1 в видеокартах INTEL. отличный вариант с точки зрения качества конечного видео.

Пресет качества P1 (Самое низкое качество, самая высокая скорость кодирования) я выбрал по двум причинам:
1. Экономия ресурсов
2. Отсутствие необходимости использовать более высококачественный пресет.
Источник видео — не самая хорошая IP камера и получаемый от нее поток очень мало теряет в качестве даже на самом низком пресете. Разумеется, если ресурсы позволяют — можете выбрать более высококачественный пресет.

Строка GPU отвечает за выбор видеокарты, которая будет использоваться для кодирования видео.

Важная оговорка: речь именно про кодирование видео. В диспетчере задач это будет отображено как VIDEO ENCODE! Если вы таким способом запускаете множество потоков кодирования — следите за уровнем загрузки кодировщика. В случае перегрузки — OBS выдаст предупреждение «Кодировщик перегружен».

Загрузка видеокарты в секции «3D» в диспетчере задач — это именно рендеринг сцены.
Если будет необходимо — раскрою эту тему в отдельной статье.

Параметры запуска

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

Полный список этих параметров находится в Wiki по OBS
Ссылка: https://obsproject.com/wiki/Launch-Parameters
Теперь я вернусь на один логический шаг назад, к разделению потоков трансляции и использованию нескольких копий OBS одновременно.

Создание нескольких копий (инстансов) OBS одновременно

Чтобы создать несколько экземпляров, которые не будут зависеть друг от друга — ранее я использовал только параметр запуска  “—multi”, который по сути просто пропускает окно подтверждения при запуске второй и следующих копий OBS и делал копии установочных папок с OBS, а также пронумеровал EXE файлы как obs64(n).exe для каждого инстанса, где n является номером инстанса и его же уникальным id для отслеживания в системе.

Проблема заключалась в том, что часть важных параметров приложения находилась в общей папке WINDOWS C:\Users\Username\AppData\Roaming\obs-studio, в том числе подпапка с коллекцией сцен (это «что мы стримим»), папка профилей кодирования («куда и как мы стримим») и, самое главное, файл global.ini. Как я уже упоминал ранее — этот файл отвечает за глобальные настройки конфигурации приложения.

Сама OBS подтягивает последние настройки из последнего успешного запуска.

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

Теперь я использую более практичный вариант – Portable Версию приложения.
Для этого нужно скачать zip архив с актуальной версией приложения OBS на GITHUB, или установить приложение в любую удобную папку. Для себя я сделал следующим образом:
В корне диска создал папку “OBS” внутри неё создал папку OBS_«№», где №- это номер инстанса (копии) приложения, внутри установочной папки приложения нужно создать файл: portable_mode.txt

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

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

В директории config\obs-studio\basic– будет две папки, одна со сценами, вторая с профилями кодирования. Об этой части я писал выше. Файл global.ini тоже будет внутри папки config.

ВАЖНО! Обязательно нумеруйте папки с инстансами OBS и exe файл этого инстанса соответственно! Нужда в нумерации exe файла не исчезла. Это самый простой способ идентификации отдельных инстансов в системе. Я называю папки OBS_номер_инстанса и obs64(номер_инстанса).exe.

В эту же папку вы можете установить все необходимые для вашего проекта плагины, которые будут использоваться. Все настройки плагинов будут ассоциированы только с тем инстансом OBS, в который они установлены. Файлы конфигурации этих плагинов так же будут внутри папки инстанса. Проверено для одного из самых полезных в моём случае плагинов —  Advanced Scene Switcher.

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

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

Далее вы создаете файл с расширением .bat, в котором прописываете адрес директории отдельных инстансов и их параметры запуска. Например:

Мы транслируем 12 разных уличных камер в 12 разных трансляций на Youtube.
У каждой камеры свой ip адрес, и к ним ведут разные ссылки на их поток, а это отдельная настройка источника контента в сцене (Media Source), соответственно в каждом инстансе будет своя сцена, со своим источником (Media Source) который забирает в инстанс свою камеру.
Так же напомню, что у каждой трансляции свой ключ потока, который записан в Profile – профиль кодирования. Я буду упоминать об этом, чтобы эта информация зафиксировалась, и вы помнили, где какой пул параметров записан.

Нам нужно, чтобы:
Инстанс OBS#1 был запущен из директории C:\OBS\OBS_1\bin\64bit с помощью файла obs64(1).exe, с профилем кодирования CAM1_Profile и сценой CAM1SC, так же нужно, чтобы трансляция запускалась сразу после запуска инстанса, и инстанс сворачивался в трэй (лоток), а не в панель задач, и так же должно быть пропущено окно подтверждения при запуске множества копий OBS Studio.

Чтобы реализовать этот функционал есть 2 варианта:  

• Прописать в ярлыке OBS нужные параметры.

• Создать «.BAT» файл с небольшим скриптом, который будет запускать OBS с нужными нам параметрами. Забегая вперед — этот вариант наиболее предпочтителен в нашем случае.

Создаём текстовый файл. Открываем любым редактором и пишем в нем следующий текст:

cd "C:\OBS\OBS_1\bin\64bit"
start obs64(1).exe --profile "CAM1PROFILE" --collection "CAM1SC" --startstreaming --multi --minimize-to-tray
exit

Упрощенные для понимания комментарии для тех, кто совсем не понимает, что делаем на этом этапе.

@Echo off — сделает невидимым выполнение всех следующих команд.
cd "C:\OBS\OBS_1\bin\64bit" — в кавычках ваш путь к «exe» файлу OBS
start obs64(1).exe — команда для запуска OBS.

ВАЖНО! В моем случае мне пришлось переименовать EXE файл для упрощения идентификации процесса в системе на последнем этапе. Если вы будете таким образом запускать только 1 копию OBS — можете убрать цифру в скобках и оставить просто obs64.exe. 
Если вы не будете запускать другую копию OBS — всё это не имеет смысла, т.к. OBS запускается с последними настройками, которые были до краша/вылета/падения. В Вашем случае достаточно просто перейти на следующий пункт гайда и сразу забросить в упомянутую в нем папку ярлык OBS.

Расшифровка остальных параметров запуска:

Теперь, сохраняем текстовый файл, называем его «OBS_Stream_Camera_1» и меняем ему расширение на «.bat». Когда вы кликните дважды на этот файл, то OBS запустится с именно с этими параметрами. 

Проделываете всю процедуру второй раз для второго комплекта настроек.

Во втором BAT файле указываете второй комплект сцена+профиль.

Для того, чтобы реализовать последний этап, заранее переименуйте в двух папках двух отдельных инстансов OBS exe-файлы как OBS64(1).exe и OBS64(2).exe. В каждом bat’нике ссылайтесь на свой exe’шник, находящийся в своей папке. 

Теперь у вас есть два .bat файла, которые обращаются каждый к своему exe файлу OBS внутри своей папки. Каждый для своего инстанса OBS. У каждого свой профиль с ключом потока и набор источников.

Автоматизация запуска OBS при перезагрузке сервера

Этот этап крайне простой и крайне короткий.

Нажимаем Win+R.
Откроется окно «Выполнить».

Пишем там команду: 

shell:common startup

Откроется папка внутри Windows с расположением:

С:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

В эту папку необходимо поместить оба BAT файла, которые были созданы на предыдущем шаге.

Теперь при запуске системы будет происходить выполнение этих BAT’ников, и следовательно — запуск двух инстансов OBS с заранее прописанной конфигурацией. Согласно содержимому BAT файлов — трансляция так же будет начинаться незамедлительно.
При необходимости — можно добавить задержку.

Автоматизация перезапуска OBS при вылете приложения

Для этого нам понадобится сделать, в сущности, всего лишь 2 действия:

1. Создать 2 Watchdog’а в виде BAT файлов, которые будут проверять выполняется ли условие: есть ли в системе работающий процесс с участием файлов obs64(1).exe и obs64(2).exe, для этого мы как раз и переименовали exe’шники ранее. Так, в системе будет отображаться два отдельных приложения с соответствующими названиями. OBS64(1).exe — для первого инстанса OBS, который кодирует 1-ю трансляцию, и OBS64(2).exe — для второго инстанса OBS, который кодирует 2-ю трансляцию. Простейший способ идентификации нужного инстанса в системе без необходимости вычленять process id и прочих сложностей.

2. Автоматизировать запуск BAT файлов Watchdog’и по расписанию через планировщик задач Windows.

Первый этап

Создаем текстовый файл со следующим текстом:

Set ProcessName=obs64(1).exe
TaskList /FI "ImageName EQ %ProcessName%" 2>nul|Find /I "%ProcessName%">nul||(
Start "" "С:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\OBS_Stream_Camera_1.bat"
)

Сохранитесь и измените расширение файла на «.bat».

Краткий комментарий:

Set ProcessName=obs64(1).exe — здесь указано имя процесса, который мы отслеживаем.
Start "" "С:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\OBS_Stream_Camera_1.bat" — здесь мы указываем какой BAT файл запускать в случае, если искомый процесс не обнаружен в системе.

Создайте второй bat файл, который будет мониторить второй exe’шник OBS и ссылаться на запуск второго bat’ника под второй инстанс трансляции.

Назовите bat’ники Watchdog_1 и Watchdog_2, например. Я обозвал их так для удобства.
Сохраните их в ту же папку с названием, например WATCHDOGS в папке для всего проекта OBS в корне диска.

Второй этап

Жмём «Win+R»

В поле ввода вбиваем:

taskschd.msc — Откроется окно планировщика Windows. 

Жмем «Создать задачу…»

Вводим имя, например Watchdog.

Описание — по вкусу. Можете оставить комментарий, чтобы не забыть.

Переключатель в положение «Выполнять только для пользователей вошедших в систему» и «Выполнить с наивысшими правами».

Переходим во вкладку «Триггеры». Жмем «Создать».

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

Переходим во вкладку «Действия». Жмем «Создать».

Здесь мы выбираем сначала Watchdog_1.bat, потом жмем «ОК», и добавляем второе действие, запуск Watchdog_2.bat.

Теперь переходим во вкладку «Параметры».

Выставляем такие параметры. Жмем «ОК».

Теперь раз в час будут запускаться два скрипта, которые проверяют, запущена ли OBS или нет. Если одна или обе копии OBS не запущены — то скрипты это увидят и запустят соответствующие bat’ники для запуска OBS с нужным набором Профиль+Сцены.

Могу вас поздравить, если вы всё сделали правильно — всё будет успешно работать. В моём случае всё сработало довольно просто и легко. 

Проверки и тесты показали, что сервер работает успешно, в случае обрывов электричества или вылетов OBS восстанавливается самостоятельно. 

Автоматизация отключения OBS в случае зависания процесса obs64.exe

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

Это место — Глухое зависание процесса obs64.exe.

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

Дисклеймер: Несмотря на то, что проблема рандомных зависаний OBS существует, во время тестов мне стоило огромных трудов заставить OBS зависнуть. Живучая зараза, как оказалось.

Проблема:

OBS наглухо зависла, процесс в состоянии «Не отвечает». Трансляция, вероятнее всего, тоже не идет. Очевидное решение – принудительно завершить задачу, запустить трансляцию заново и ждать следующего повторения.

Решение:

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

1. Убеждаемся в том, название exe файла OBS позволяет его однозначно идентифицировать в системе, например так, как это сделал я: OBS64(1).exe и OBS64(2).exe.

2. Создаем WatchDog BAT-файл со скриптом, смысл которого таков:
   «Если приложение с именем OBS64(1).exe в статусе «Не отвечает» — убиваем процесс.»

3. Автоматизируем запуск этого BAT файла по расписанию через Планировщик Windows.

4. Не забываем подключить и автоматизировать запуск еще одного BAT-файла, который будет проверять, запущено ли приложение OBS64(1).exe, и если не запущено — будет стартовать его самостоятельно.

Первый этап

Создадим текстовый файл.
В нём пишем следующий текст:

@echo off
taskkill /im obs64(1).exe /FI "Status eq NOT RESPONDING" /f
exit

Кратко о содержимом:

@Echo off — аргумент, чтобы на экран не выводилась командная строка
taskkill — собственно то, что нам и требуется сделать, убить процесс.
/im — образ, приложение, которое мы ищем.
/FI — фильтр, которым мы проверяем условие. В нашем случае: Статус равно «Не отвечает».
/f — параметр Форсированного выхода из приложения, предотвращает все диалоговые окна при закрытии приложения, максимально быстрый и жесткий выход. Обязательно использовать его, чтобы скрипт не встал на диалоге «А вы действительно хотите выйти из приложения??»
exit — выход.

Сохраняем документ, переименовываем его. Я, например назвал файл: NotResponding_Watchdog.bat

Второй этап

Теперь переходим в предыдущую часть статьи, и полностью проходим Этап 2.

Вам просто нужно автоматизировать запуск этого BAT-файла по расписанию, раз в, скажем, 15 минут. Желательно выстроить последовательность в планировщике Windows так, чтобы Таск-Киллер запускался за 5 минут до того, как запускается WatchDog процесса. То есть:

Таск-Киллер убивает зависшую OBS, а через 5 минут второй скрипт, увидев, что OBS не запущена — запускает её согласно условиям из предыдущей статьи.
В целом – можно в этот же скрипт проинтегрировать шаг «Запуск нужного инстанса OBS, в случае если процесс был убит», но я уже не помню достоверно, почему я решил оставить более простой вариант.

Автоматизация переподключения OBS Studio к камере, в случае потери видеопотока

Проблема: 

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

Размышления:

В целом эта проблема связана с нюансами трансмиссии видео через UDP и TCP. Поскольку актуальная версия OBS поддерживает возможность настройки FFMpeg параметров источника видеосигнала – эту задачу, вроде как, по заверениям гуру, можно решить прописав корректные настройки FFMPEG декодера видеопотока в настройках Media Source.

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

Решение:

В качестве решения задачи, по совету сообщества OBS- я применил плагин Advanced Scene Switcher. Ссылка на GitHub

Этот плагин дает обширные возможности для автоматизации и самое главное -решает мою задачу в 3 клика.

Задачи:

1. Установить плагин в папки каждого инстанса OBS

2. Настроить детектирование потери видеопотока с камеры

3. Задать действие, которое будет выполняться в случае потери видео

Постараюсь кратко пройти эти пункты.

1. Открываем окно плагина в OBS

   

2. Переходим во вкладку “MACRO”

   

3. Создаём макрос с удобным для понимания названием:

   

4. Создаем условие для макроса. Суть условия:
   Если Видео из Источника «Камера 1» Не изменяется

   

5. Создаем правило, которое будет выполняться при соблюдении условия:
   Суть правила такова, что в случае выполнения условия – настройки источника MEDIA SOURCE будут обновляться, что вызовет переподключение к потоку камеры. Возможно есть более правильный способ, но иные варианты в моём случае не сработали.

   

6. Выставляем время проверки условия максимальное, которое возможно для снижения нагрузки, и жмем START. Так же убеждаемся, что параметр On Startup of OBS стоит “Start the scene switcher if it was running”, чтобы он запускался автоматически в случае перезапуска OBS. После этого Автоматика будет делать всё за вас.

   

Теперь раз в N-миллисекунд будет проверяться условие из макроса. Я выставил 9999.
Если картинка на видео источнике застынет или будет показывать черный экран – настройки источника обновятся и поток с камеры перезапустится.
При желании можно добавить вывод уведомления об этом.

Финал

Это моя первая статья на Хабре, и несмотря на то, что IT специалистом я и не являюсь, я уверен, что эта статья найдёт свою аудиторию. Для меня было важно записать все этапы и шаги, которые я сделал, чтобы тем, кто прочтёт статью не пришлось долго и нудно собирать разрозненные клочки информации в сети по крупицам. Здесь собраны 3,5 года жизни моего Pet-project’a и я доволен результатом. Более того, я считаю, что этой информацией стоит поделиться с сообществом.

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

В целом – задача решена. Степень автоматизации процессов на сервере, транслирующем видео с камер наблюдения в сеть достаточна для моей задачи и моих целей. Теперь я надеюсь на расширение проекта и увеличение пула камер. Неравнодушные к проекту товарищи, друзья и сочувствующие помогли собрать немного донатов на покупку камер.
В дальнейшем, как я писал выше, буду пытаться купить RTX 3060 и расширить возможности.
На данный момент – полтора года эфира на Youtube. Трансляция, которая идет сейчас — запущена 12 января 2022 года, спустя несколько дней после несостоявшегося пожара, который я упоминал в статье.

Если у вас есть вопросы или уточнения – готов обсудить в комментариях.

Ссылка на проект

Ссылка на канал в ТГ, куда я пишу время от времени про приключения этого проекта:
https://t.me/nashservachokluchi (Не реклама, просто заметки, которые я писал в большей степени для себя в процессе работы, чтобы не забыть что-то важное).

Спасибо, что уделили время прочтению этого «научного труда» =)