Учавтствую в разработке образовательной платформы, где ученики, в том числе, могут смотреть записи прошедших занятий. Видеозвонок проходит в Яндекс Телемосте, бот записывает занятие, сохраняет его в WebM и передаёт файл на backend. После этого запись становится доступна ученику в личном кабинете.

Заметили проблему: длинные видео нормально воспроизводились с начала, но при перемотке примерно на 20 минут вперёд плеер надолго зависал. Браузер активно грузит данные, буфер заполняeтся, но воспроизведение не начинается.

Начинаем с фронта. Проверил плеер, MIME-тип и настройки предварительной загрузки. Нашел ошибку с определением WebM, исправили, но основная проблема осталась.

Идем в бекенд, смотрим на HTTP Range-запросы. После перемотки браузер запрашивает весь остаток файла. Попробовали ограничить ответы чанками по 50 МБ. Запросы стали меньше, но UX почти не изменился: браузер просто последовательно загружал несколько чанков.

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

Решение - добавить в бота этап финализации видео. После завершения записи WebM проходит remux через FFmpeg без перекодирования.

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

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