Языковая школа: 500 ГБ видеоуроков и свой стриминг вместо закрытых плейлистов

MAATRIX

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

Почему закрытый плейлист — это не защита, а её видимость

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

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

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

Что именно теряет школа при таком раскладе

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

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

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

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

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

Базовая раскладка для архива с постепенным пополнением:

/srv/video/
  masters/        # оригиналы после записи, до конвертации
  hls/
    course-a/
      lesson-01/
        playlist.m3u8
        seg-000.ts
        seg-001.ts
        ...
  transcode-queue/ # временная папка для ffmpeg-джобов

Оригинал урока (обычно mp4 или mkv прямо с записывающего софта) попадает в masters/, затем конвертируется в HLS — набор коротких сегментов плюс плейлист-манифест. HLS удобен тем, что его поддерживает браузерный плеер без сторонних плагинов и, что здесь важнее, каждый сегмент можно отдавать отдельно проверенным пользователям, а не файл целиком одной ссылкой.

Для одного урока в разумном качестве (720p достаточно для языковой школы — важна читаемость текста на экране и чёткость речи, не кинематографичная картинка) команда конвертации выглядит так:

ffmpeg -i lesson-01.mp4 \
  -c:v libx264 -crf 22 -preset veryfast \
  -c:a aac -b:a 128k \
  -hls_time 6 -hls_playlist_type vod \
  -hls_segment_filename "hls/course-a/lesson-01/seg-%03d.ts" \
  hls/course-a/lesson-01/playlist.m3u8

Раздачу сегментов делает nginx с модулем secure_link — он проверяет подпись в URL и время жизни ссылки на каждый запрос сегмента, а не только при открытии страницы:

location /hls/ {
    secure_link $arg_md5,$arg_expires;
    secure_link_md5 "$secure_link_expires$uri secret-key-here";

    if ($secure_link = "") { return 403; }
    if ($secure_link = "0") { return 410; }

    root /srv/video;
    add_header Cache-Control no-store;
}

Плейлист-манифест .m3u8, который получает плеер на странице, генерируется на лету бэкендом школы под конкретного залогиненного ученика — с уже подписанными ссылками на сегменты именно того курса, к которому у него есть оплаченный доступ. Так закрывается пробел закрытого плейлиста: ссылка привязана не к «видео вообще», а к сессии конкретного человека и живёт ограниченное время.

Кто и что может смотреть: модель доступа

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

Уровень ученика. Каждый залогиненный ученик видит только те курсы, за которые у него есть активная оплата в базе — обычной таблице вида student_id / course_id / paid_until. Просроченная оплата автоматически убирает доступ, без ручной возни с отзывом ссылок.

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

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

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

Сколько места и какого сервера это требует

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

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

Для хранения мастер-файлов без привязки к конкретному провайдеру подойдёт S3-совместимая система вроде MinIO, поднятая на своём сервере — подробно про установку разобрано в статье про MinIO на VPS, если школа хочет разнести «горячую» раздачу и «холодное» архивное хранение по разным серверам.

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

Перенос существующей библиотеки без паузы в продажах

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

1. Пилотный курс. Взять один не самый популярный курс, прогнать через конвертацию в HLS, настроить раздачу и проверить весь путь ученика: логин, оплата, воспроизведение, истечение ссылки.
2. Параллельный период. Новые записи сразу заливаются на свой сервер, старые остаются на прежней площадке до полного переноса — ученики старых курсов ничего не замечают.
3. Постепенный перенос архива. По одному-два курса в неделю, начиная с самых востребованных, чтобы быстрее снять риск утечки там, где он дороже всего. Пакетный ffmpeg-скрипт по всей папке экономит время — конвертация запускается очередью, а не вручную для каждого урока.
4. Отключение старой площадки только после проверки. Не удалять исходники, пока не подтверждено, что все ученики получили доступ на новой системе и хотя бы один цикл оплаты прошёл без нареканий.

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

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

Частые вопросы