Запись живых занятий и постобработка для каталога

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

Кратко

Живое занятие и его запись – два разных продукта. Если считать их одним, каталог курса заполняется видео, которое никто не смотрит. Сама запись – простая часть: вы выбираете между одним сведённым файлом, где комната сохранена такой, какой была, и отдельными треками участников, которые можно перемонтировать позже, а файл за вас пишет медиасервер. Сложная и ценная часть – постобработка: обрезать лишнее, перекодировать запись в адаптивный пакет, довести живые автосубтитры до стандарта для записи, разметить главы и подключить трекинг, чтобы запись давала данные о просмотрах и завершении, как любое другое учебное видео. В статье – весь пайплайн по шагам: выбор режима записи, требования доступности к записи, 152-ФЗ, расчёт стоимости в рублях и вопрос «строить или купить».

Зачем это читать

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

Сначала разделите две задачи

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

Разделять их стоит из-за экономики. Запись – в основном решённая задача: медиасервер, который уже ведёт живое занятие, запишет файл одним вызовом API. Постобработка и есть продукт: на неё приходится почти вся стоимость и почти всё качество. Сырая запись относится к видео в каталоге так же, как отснятый материал к готовому фильму, и разрыв в усилиях тот же.

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

Почему записать WebRTC не так просто

Полезно понимать, почему нельзя просто «сохранить поток». Живое занятие на WebRTC – это не один аккуратный видеофайл, а набор отдельных медиапотоков: каждая камера, каждый микрофон, демонстрация экрана. Они приходят мелкими пакетами без фиксированной частоты кадров, часть пакетов теряется, а часы у участников расходятся. Готового файла, который можно просто забрать, нет. Медиасервер либо сохраняет каждый поток отдельно как есть, либо декодирует все потоки, выравнивает их по общей временной шкале и заново кодирует результат в формат, который откроет обычный плеер. Первым путём идёт открытый Janus: он пишет каждый поток в свой файл .mjr, а утилита постобработки затем переупаковывает его в проигрываемый формат без перекодирования (Janus, Recordings, документация).

Оба пути требуют центрального процесса, поэтому запись почти всегда делают на сервере, а не в браузере ученика. Браузерная запись пропадает, как только ноутбук закрыли, у него отвалился Wi-Fi или кончилась память, а серверный рекордер – надёжный процесс под вашим контролем. Для занятия, которое будут пересматривать, серверная запись – вариант по умолчанию, и дальше статья исходит из него.

Нажмите, чтобы увеличить

Главное решение: композит или по трекам

Серверная запись бывает двух видов, и выбор между ними – первое настоящее решение. Угадаете – остальной пайплайн пойдёт гладко; ошибётесь – придётся переснимать курсы, которые переснять уже нельзя.

Запись композитом

Композитная запись сохраняет комнату такой, какой её видели участники: преподаватель, слайды, галерея лиц, раскладка, – и сводит всё в один готовый видеофайл. Технически это выглядит так: безголовый браузер (браузер на сервере без экрана) открывает веб-страницу с комнатой, а сервер записывает эту страницу. LiveKit, популярный open-source медиасервер реального времени, называет это room composite egress: комната рендерится в Chrome по настраиваемому веб-макету, запись привязана к жизненному циклу комнаты и сама останавливается, когда занятие заканчивается (LiveKit, Egress overview, официальная документация).

Плюс – простота. Вы получаете один готовый к воспроизведению файл, который выглядит так же, как занятие. Инженеры, встраивавшие запись в WebRTC-продукты, отмечают: с композитным потоком всё просто, вопрос только в том, где его хранить и как защитить (WebRTC.ventures, Adding Recording to Your WebRTC Application).

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

Запись по трекам

Потрековая запись устроена наоборот: видео и аудио каждого участника сохраняются отдельными файлами – преподаватель на одном треке, демонстрация экрана на другом, каждый ученик на своём. В LiveKit для этого есть track egress (каждый трек экспортируется отдельно, видео без перекодирования) и participant egress (видео и аудио одного участника сохраняются вместе) (LiveKit, Egress overview, официальная документация).

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

Минус – дополнительный шаг. Отдельные треки не станут видео, которое можно смотреть, пока что-то не сведёт их по общей шкале времени; в композитном режиме эту сборку за вас сделали заранее. Сборка – это инженерная работа и вычисления, за которые надо платить. Классический профессиональный приём – писать сырые треки во время звонка и собирать потом – даёт максимум контроля над монтажом, но и пайплайн требует самый сложный (WebRTC.ventures).

Нажмите, чтобы увеличить

На практике выбирают так. Если запись – это документ (подтверждение, что занятие было, повтор для пропустивших), пишите композитом и не усложняйте. Если запись – продукт (флагманское видео курса, которое будет работать годами), пишите по трекам, чтобы потом смонтировать чистовую версию для каталога. Многие зрелые платформы делают и то и другое: композит – для мгновенного повтора, треки – в фоне, для будущей чистовой версии. Например, auto egress в LiveKit при создании комнаты может включить и композитную запись, и запись каждого опубликованного трека (LiveKit, Egress overview).

Коротко о том, как создаётся файл

Писать рекордер с нуля не нужно, да и незачем. Медиасервер записывает занятие, подключаясь к нему как особый невидимый участник. В LiveKit рекордер входит в комнату как участник типа EGRESS, подписывается только на нужные треки и кодирует результат в файл или живой поток с помощью открытого медиафреймворка GStreamer (LiveKit, Egress overview). Писать он может сразу готовый MP4 или сегменты HLS – нарезанный формат для адаптивного стриминга по запросу. Вывод для неинженера: запись – вопрос настройки и бюджета, а не исследовательский проект. Механику записи на уровне протокола и мост от живой WebRTC-сессии к HLS разбирает раздел «Видеостриминг» – запись WebRTC и мост к HLS; здесь мы остаёмся в контексте обучения.

# Концептуально: запустить композитную запись комнаты при старте занятия.
# Иллюстрация, а не дословный вызов SDK.
egress.start_room_composite(
    room="algebra-101-2026-06-20",
    layout="speaker-focus",       # макет фиксируется в записи
    output={"type": "hls", "segments": "s3://catalog/algebra-101/"}  # S3-совместимое хранилище в РФ
)

Постобработка: как запись становится видео для каталога

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

1. Обрезать лишнее

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

2. Перекодировать в адаптивный пакет

Один файл в высоком разрешении – плохой способ отдавать видео по запросу ученикам с разными устройствами и сетями. Стандартная практика – транскодирование: запись перекодируют в несколько уровней качества и нарезают в адаптивный пакет, чтобы плеер каждого ученика сам выбирал уровень, который тянет его соединение. Это та же техника адаптивного стриминга, что и в других разделах Learn, и заново объяснять её здесь не будем. Выбор кодека и лестницы качества – в разделе «Кодирование видео», экономика доставки по запросу и мульти-CDN – в статье масштабирование доставки: CDN, транскодинг и стоимость при больших объёмах. Для обучения важно одно: запись занятия не готова к каталогу, пока не упакована для адаптивного воспроизведения, потому что быстрый оптоволоконный интернет есть далеко не у всех учеников.

Транскодирование можно построить самим (FFmpeg в своём облаке) или отдать российской видеоплатформе. Kinescope, Boomstream, Facecast и Yandex Cloud Video принимают файл и сами готовят его к доставке. По документации у Kinescope есть DRM, водяные знаки, API и автосубтитры, у Yandex Cloud Video – хранилище, CDN, SDK-плеер, автосубтитры, таймкоды и доступ по токену (DRM не заявлен). Корпоративные видеотеки переезжают на такие платформы с зарубежных сервисов: по отраслевому обзору, только в Kinescope за восемь месяцев 2025 года перенесли 100 тыс. видео. Публичные зарубежные видеохостинги для закрытого каталога не годятся: часть из них в России доступна только через VPN, а хранить ПДн учащихся в зарубежных базах запрещено (подробнее – в разделе о 152-ФЗ ниже).

3. Субтитры по стандарту *записи*, а не эфира

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

Международный стандарт доступности Web Content Accessibility Guidelines (WCAG) 2.1, на котором построен и российский ГОСТ Р 52872-2019, по-разному подходит к живым и записанным медиа. Живые субтитры – это критерий 1.2.4 Captions (Live), уровень соответствия AA. Запись относится к записанным медиа, и для неё действуют критерий 1.2.2 Captions (Prerecorded), уровень A, и, что важно, критерий 1.2.5 Audio Description (Prerecorded), уровень AA, у которого нет аналога для эфира (W3C, WCAG 2.1, критерии 1.2.2, 1.2.4, 1.2.5). Субтитры к записи должны быть точными, синхронными и передавать значимые неречевые звуки; сырые живые автосубтитры с ошибками до этой планки не дотягивают. Отсюда шаг постобработки: взять расшифровку эфира как черновик, вычитать её и выпустить чистые синхронные субтитры, а для уровня AA добавить аудиоописание значимого визуального контента.

Движок распознавания речи – российский облачный (Yandex SpeechKit, SaluteSpeech) или открытая модель вроде Whisper на своих серверах – разобран в статье автоматические субтитры для учебного видео; здесь задача – довести его результат до стандарта записи. Голос учащихся в записи – их персональные данные, поэтому зарубежные API распознавания на этом шаге не подходят. Прямого федерального требования субтитровать учебное видео, по нашим данным, нет: ГОСТ Р 52872-2019 добровольный, если заказчик не включил его в техническое задание. Но ст. 79 273-ФЗ требует для учащихся с ОВЗ специальных условий обучения, включая сурдоперевод, а запись без субтитров для глухого ученика – просто недоступный урок. Подробно о доступности – в статье WCAG 2.1 AA и ГОСТ Р 52872-2019 для учебного видео.

Нажмите, чтобы увеличить

4. Разбить запись на главы

Часовая лекция без внутренней структуры неудобна для повторного просмотра: ученику нужен один раздел, а он вслепую перематывает. Главы решают проблему: это именованные метки, которые делят шкалу времени на сегменты с быстрым переходом. Стандартный для веба способ их передать – файл WebVTT (формат W3C Web Video Text Tracks): трек глав – обычный текст, по блоку на главу (интервал времени и название), а плеер превращает его в кликабельные метки (W3C, WebVTT: The Web Video Text Tracks Format). Главы – не украшение: с ними пересмотр становится навигацией, а не линейной перемоткой. В учебном каталоге они ещё и показывают в аналитике, как ученики пересматривают материал и к каким сложным местам возвращаются. Подробнее о главах, транскриптах и поиске – в статье главы, транскрипты и поиск внутри видео.

5. Подключить ИИ, но с оглядкой

Два шага постобработки уже обычно автоматизируют: разметку глав и конспект. Языковая модель находит по транскрипту смены темы и предлагает границы и названия глав, а редактор их правит. Схема «сначала модель, потом человек» заметно экономит время на каждом видео. Та же модель может написать конспект и список ключевых тезисов для страницы каталога. В России для этого берут GigaChat, Alice AI в Yandex AI Studio или открытую модель на своих серверах; в Yandex Cloud Video таймкоды заявлены как функция платформы. Отправлять транскрипты с ПДн учащихся в API зарубежных ИИ-сервисов нельзя по той же причине, что и при распознавании речи. И честная оговорка: ИИ-главы и конспекты – черновик, а не готовая публикация. Качество суммаризации и многоязычность разобраны в статье суммаризация лекций и учебные материалы. Для продукта остаётся решить одно: публиковать результат модели без присмотра (для контента, по которому оценивают учеников или который обязателен по регламенту, лучше не стоит) или пропускать его через быструю проверку человеком.

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

Видео в каталоге не должно быть «мёртвым»: оно должно отдавать те же учебные данные, что и любой другой материал курса. Стандарт для подробной записи поведения зрителя – xAPI Video Profile, профиль Experience API (xAPI), который поддерживает ADL. Он определяет конкретные утверждения для видео: initialized, played, paused, seeked, completed и terminated; плеер отправляет их в Learning Record Store по ходу просмотра (ADL, xAPI Video Profile). Это намного больше, чем флаг «played» у обычного плеера: видно, какие фрагменты пересматривали, где ученики бросали просмотр и что пропускали. Как отправлять эти утверждения, разбирает статья трекинг видео через xAPI Video Profile, а как читать полученные цифры – основы метрик обучения. Главное для каталога: ещё на этапе постобработки решите, что значит «завершено» для записанного занятия, и отправляйте это событие осознанно. Здесь и возникает самая частая путаница во всей теме.

Типичные ошибки в пайплайне записи

«Просмотрено 100% – значит, завершено». Не обязательно. Один ученик оставит запись играть в фоновой вкладке и дойдёт до 100%, ничего не усвоив; другой посмотрит 80% и сдаст тест. Задайте правило завершения сознательно – процент просмотра, проверочный тест или и то и другое – и отправляйте утверждение xAPI completed по этому правилу. Не позволяйте полосе прогресса плеера незаметно решать, усвоен ли материал. Это самая частая ошибка измерений в e-learning, и начинается она в пайплайне записи.

«Живые субтитры подойдут и для записи». Не подойдут. Как сказано выше, живые субтитры закрывают WCAG 1.2.4, а для записи нужны 1.2.2 и 1.2.5, которых одни автосубтитры не обеспечивают. Курс с сырыми автосубтитрами – плохой опыт для ученика, а если заказчик включил ГОСТ Р 52872-2019 в техническое задание, то ещё и несоответствие ТЗ.

«Композит перемонтируем потом». Не получится. Композитная запись – уже сведённое видео с постоянным макетом. Если есть хоть какой-то шанс, что понадобится перемонтаж или другой макет, писать нужно было по трекам. Задним числом это решение не исправить.

«Запись бесплатна». Нет. При композитной записи безголовый браузер работает как полноценный серверный участник всё занятие; эти вычисления стоят денег, а одновременные записи умножают расходы. Хранение и особенно доставка добавляют к счёту ещё. Цифры – в разделе о стоимости ниже.

«Нажал „запись“ – и курс готов». Сырая запись, которая начинается со слайда ожидания, без глав, чистых субтитров, адаптивного пакета и трекинга, – ещё не видео для каталога, а исходник. Продукт – это пайплайн постобработки.

Запись с учащимися – это персональные данные

Изображение, голос и имя учащегося в записи – его персональные данные, так что запись занятия подпадает под 152-ФЗ. Для продуктовой команды отсюда следуют четыре инженерных требования.

Отдельное согласие. С 01.09.2025 согласие на обработку ПДн оформляется отдельно от иных документов (ч. 1 ст. 9 152-ФЗ в ред. 156-ФЗ), поэтому галочка «согласен с офертой» запись не покрывает. За несовершеннолетнего согласие по общим правилам даёт законный представитель. Технически это значит: интерфейс показывает, что идёт запись, а статус согласия каждого участника хранится вместе с записью.

Хранение в России. С 01.07.2025 ч. 5 ст. 18 152-ФЗ запрещает сбор, запись и хранение ПДн граждан РФ с использованием баз данных за пределами России. Рекордер, хранилище записей, транскодирование, распознавание речи и видеоплатформа должны работать в российском контуре: в своём ЦОДе, в российском облаке или на российской видеоплатформе.

Защита от утечек. Каталог записей с учащимися – лакомая цель. За утечку ПДн юрлицо по ст. 13.11 КоАП платит от 3–5 млн ₽ (до 10 тыс. записей) до 10–15 млн ₽ (свыше 100 тыс.), за повторную – от 1 до 3% выручки, но не меньше 20 млн ₽ и не больше 500 млн ₽. Доступ к записям выдавайте по токену и правам, а не по открытой ссылке: например, Yandex Cloud Video заявляет доступ по токену, Kinescope и Boomstream – DRM и водяные знаки.

Никакой скрытой биометрии. Если захочется добавить к записям распознавание лиц – для учёта посещаемости или идентификации, – это уже биометрия: ст. 11 152-ФЗ требует письменного согласия, а с 2023 года работа с биометрией идёт через ЕБС по 572-ФЗ. Такую функцию проектируют отдельно, а не добавляют в пайплайн записи «заодно».

Сколько это стоит: пример расчёта

Посчитаем на реалистичном примере. Возьмём 60-минутное занятие, записанное композитом в 720p с битрейтом около 1,5 мегабита в секунду (Мбит/с). Запись пойдёт в каталог, и в итоге её посмотрят 500 учеников.

Размер записи. Битрейт, умноженный на длительность, даёт размер файла. Считаем в одних единицах:

1,5 Мбит/с × 3 600 секунд = 5 400 мегабит
5 400 мегабит ÷ 8 = 675 мегабайт ≈ 0,66 ГБ сырой записи 720p

Транскодирование в адаптивный пакет. Перекодирование, скажем, в четыре уровня качества (от 1080p до 360p) с нарезкой почти удваивает объём хранения по сравнению с одним файлом:

0,66 ГБ × ~1,8 (адаптивная лестница) ≈ 1,2 ГБ хранения на час занятия

Цены ниже – ориентировочные порядки, чтобы показать логику, а не тарифы конкретного провайдера; российские облака (Yandex Cloud, VK Cloud, Selectel, Cloud.ru) и видеоплатформы публикуют свои прайсы, сверяйтесь с ними.

Хранение. Объектное хранилище стоит ориентировочно порядка 2 ₽ за ГБ в месяц:

1,2 ГБ × 2 ₽ ≈ 2,4 ₽ в месяц за хранение одного часа занятия
Каталог на 500 часов: 500 × 1,2 ГБ = 600 ГБ × 2 ₽ ≈ 1 200 ₽ в месяц

То есть хранение почти ничего не стоит. Деньги уходят на доставку. Исходящий трафик сети доставки контента (CDN) стоит ориентировочно порядка 7,2 ₽ за ГБ. Если каждый из 500 учеников посмотрит версию 720p (~0,66 ГБ):

500 учеников × 0,66 ГБ = 330 ГБ трафика
330 ГБ × ~7,2 ₽ ≈ 2 400 ₽ на доставку одной записи 500 зрителям

Вычисления на запись. Рекордер на безголовом браузере занимает серверное время на всю длительность занятия: ориентировочно порядка 0,85–1,7 ₽ за минуту композитной записи, то есть примерно 50–100 ₽ за 60-минутное занятие.

Итог: записать и хранить каталог дёшево, а доставка при большой аудитории – постоянная статья расходов, и растёт она с просмотрами, а не с часами записи. Поэтому экономике доставки, CDN и выбору кодека, который экономит каждый байт, посвящены отдельные материалы: статья масштабирование доставки: CDN, транскодинг и стоимость и раздел «Кодирование видео». Закладывайте бюджет на просмотры, а не на записи.

Какие инструменты реально подойдут

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

Если коротко: быстрее всего к работающей записи приводят готовая платформа или LiveKit (open-source, разворачивается в российском облаке). Собственный пайплайн на mediasoup даёт полный контроль над макетом композита, субтитрами и трекингом, но всё это придётся построить. Выбор между ними – то самое решение «строить или купить», к которому раздел постоянно возвращается, и зависит оно от того, насколько качество каталога и трекинг отличают ваш продукт.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Фора Софт с 2005 года делает системы видео реального времени, стриминга и видео по запросу, а пайплайн записи живых занятий находится ровно на их пересечении: захват WebRTC, серверная запись и адаптивная доставка по запросу с учебным трекингом. Выбор «строить или купить», с которым мы помогаем командам, вполне конкретен. Готовая функция записи запускается быстро и подходит для внутреннего архива повторов. Собственный потрековый пайплайн окупается, когда запись – флагманский продукт каталога, который надо перемонтировать, точно субтитровать, разбить на главы и связать через xAPI с вашей аналитикой. Мы работаем в e-learning, видеостриминге, OTT и видеоконференциях, поэтому нас обычно зовут, когда запись должна быть вещательного качества, давать измеримые учебные данные и при этом целиком работать в российском контуре. Иногда правильный ответ – «возьмите готовую видеоплатформу», и тогда мы так и скажем.

Главное

• Живое занятие и его запись – два разных продукта; записать просто, ценность создаёт постобработка.
• Композит прост и окончателен; запись по трекам можно редактировать, но нужен этап сборки.
• К записи применяются более строгие требования: субтитры для записанных медиа (WCAG 1.2.2) и аудиоописание (1.2.5). Живые субтитры до них не дотягивают.
• Обрезайте, перекодируйте в адаптивный пакет, вычитывайте субтитры, размечайте главы и подключайте xAPI на каждой записи.
• «Просмотрено 100%» не равно «завершено»: определяйте и отправляйте завершение осознанно.
• Запись с учащимися – это ПДн: отдельное согласие, хранение и обработка только в России, доступ по токену.
• Запись и хранение дёшевы; доставка растёт с просмотрами и занимает основную часть расходов.

Что читать дальше

• Трекинг видео через xAPI Video Profile: что захватывать
• WCAG 2.1 AA и ГОСТ Р 52872-2019 для учебного видео
• Эталонная архитектура живого обучения: полная картина