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

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

Во Frisbee эту задачу решает FrisbeeTube — видеохостинг, встроенный в платформу корпоративных коммуникаций.

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

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

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

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

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

Теперь перейдем к внутреннему устройству.

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

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

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

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

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

Для пользователя процесс максимально простой. Загрузка организована через специального FrisbeeTube-бота.

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

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

После публикации видео оказывается в веб-интерфейсе FrisbeeTube. Там можно смотреть материалы, работать с плейлистами и взаимодействовать с контентом.

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

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

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

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

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

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

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

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

После обработки три версии видео загружаются в S3-хранилище. Но на этом работа с роликом не заканчивается.

Следующий этап — извлечение смысла из самого видео.

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

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

После этого LLM обрабатывает транскрипцию и формирует данные, которые помогают ориентироваться в содержимом ролика:

• краткое описание;
• тайм-коды ключевых фрагментов.

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

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

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

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

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

Здесь находится еще одна важная часть архитектуры FrisbeeTube. Поскольку отдельной административной панели нет, видеосервис должен постоянно понимать, что происходит в мессенджере. Для этого используется event-driven архитектура и Kafka.

FrisbeeTube подписывается на события, которые происходят в Frisbee. Система отслеживает изменения состава групп, пользователей и самих групп. Например:

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

Сущности Frisbee зеркалируются в FrisbeeTube, хотя внутри видеосервиса они могут называться иначе. Это позволяет поддерживать соответствие между двумя системами автоматически.

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

В качестве базы данных FrisbeeTube используется Postgres, тогда как в самом Frisbee применяется Cassandra. Главный принцип при этом остается неизменным: плейлист в FrisbeeTube соответствует группе в мессенджере.

Интеграция работает не только в направлении «Frisbee → FrisbeeTube».

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

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

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

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

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

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

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

Так свой видеохостинг постепенно превращается из системы хранения в инструмент работы со знаниями.

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

FFMPEG активно использует CPU, поэтому производительность видеопроцессора напрямую влияет на скорость подготовки роликов. Для быстрой конвертации мы ориентируемся примерно на 12 ядер CPU. При этом система способна работать и на конфигурации с 4 ядрами — конкретные требования зависят от количества пользователей и интенсивности загрузки видео.

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

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

FrisbeeTube разрабатывался как собственный сервис, а не как интеграция готового публичного видеохостинга.

Это дало возможность заложить архитектуру непосредственно под сценарии корпоративного использования.

В основе сервиса — Java 25 и Spring Boot 4. Архитектура рассчитана на горизонтальное масштабирование, поэтому система может использоваться как в компаниях со средним количеством сотрудников, так и в крупных организациях с высокой активностью пользователей.
При этом основными инженерными задачами оказались не отдельные технологии сами по себе. Самое сложное — связать две системы так, чтобы пользователь воспринимал их как единое пространство.

Пользователь Frisbee и пользователь FrisbeeTube должны оставаться одной сущностью. Группа в мессенджере должна соответствовать плейлисту. Изменение прав в одном месте должно отражаться в другом.

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

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

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

Но за этим простым сценарием находится целая цепочка сервисов:

загрузка → обработка FFMPEG → оптимизация видео и звука → создание нескольких версий → S3-хранилище → транскрибация → очередь задач → LLM → описание и тайм-коды → оформление → публикация в группе.

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

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