Учебное видео на слабых сетях

Кратко

Чаще всего курс бросает тот, у кого худшее соединение, поэтому охват – задача инженеров, а не авторов контента. На медленной, дорогой или нестабильной сети один час видео в 720p может съесть заметную долю месячного пакета на лимитном тарифе. Решают проблему четыре рычага, и серьёзному продукту нужны все: адаптивный битрейт для записанных уроков (качество само снижается до уровня, который выдерживает канал), режимы для слабой сети в live-занятиях (нижний слой видео, затем аудио со слайдами, затем только аудио), скачивание для офлайн-просмотра в мобильном приложении (скачать при связи, посмотреть и отправить прогресс позже) и кодек, который реально декодирует дешёвый телефон учащегося. Разница в цифрах огромная: час урока – это примерно 1,1 ГБ в 720p, около 340 МБ в 360p и порядка 11 МБ в виде речевого аудио. Этот стократный разброс и отделяет «доучился» от «бросил». Технологии при этом самые обычные: HLS, MPEG-DASH, аудиокодек Opus, WebRTC.

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

Если курс нормально работает только на офисном Wi-Fi, вы незаметно отсекли тех, кому гибкое дистанционное обучение нужнее всего: людей на мобильном интернете и лимитных тарифах, жителей сёл и малых городов, пассажиров поездов дальнего следования, вахтовиков и сотрудников удалённых объектов. Статья написана для L&D-директора, основателя EdTech-стартапа, методиста или продакт-менеджера, который решает, сколько вкладывать в охват и что просить у инженеров. Разберём четыре рычага – адаптивное видео для записанных уроков, плавную деградацию live-занятий, офлайн-скачивание и выбор кодека – с цифрами для оценки каждого и стандартами, на которых их строят. Сетевые механизмы подробно описаны в разделах Фора Софт Видеостриминг и Видеокодирование; здесь речь о продуктовом решении: куда тратить бюджет, что это даёт и каких учащихся вы в итоге удержите.

Слабая сеть – это нормальная сеть

«Слабая сеть» – это сразу четыре проблемы, которые обычно приходят вместе. Низкая полоса: канал пропускает мало данных в секунду (её измеряют в килобитах или мегабитах в секунду, kbps / Mbps). Высокая задержка: каждый запрос долго идёт туда и обратно (измеряется в миллисекундах, мс). Потери пакетов: часть данных не доходит, их приходится пересылать или маскировать. Прерывистая связь: канал пропадает совсем и возвращается – в идущем поезде, в аудитории в подвале, у перегруженной вышки в посёлке. Пятый фактор не технический, но решающий: лимитный и дорогой трафик. Каждый мегабайт, потраченный на ваш курс, кто-то оплатил вместо чего-то другого.

Как раз о нём забывают команды из хорошо подключённых крупных городов. За их пределами слабый или пропадающий сигнал – обычное дело: сёла и малые города, трассы и железные дороги, вахтовые посёлки и удалённые промышленные объекты, где работает линейный персонал, – та самая аудитория, ради которой корпоративное обучение и переводят в онлайн. Добавьте лимиты: детские SIM-карты школьников, корпоративные симки с пакетом, который оплачивает работодатель, роуминг у тех, кто учится из-за рубежа. Отдельная ловушка – хостинг: крупнейший зарубежный видеохостинг в России замедлен с лета 2024 года, его смотрят через VPN [5], и урок, встроенный оттуда, на слабом канале просто не запустится.

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

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

Рычаг 1. Адаптивный битрейт для записанных уроков

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

Удобно представить это как лестницу. Каждая ступень – полная версия урока в своём разрешении и битрейте, скажем 240p, 360p, 480p, 720p, 1080p, и плеер стоит на той, которую сеть тянет прямо сейчас. Когда полоса падает, плеер за секунду-две переходит на версию попроще, и урок продолжается – в меньшем разрешении, но без обрыва; когда полоса восстанавливается, плеер поднимается обратно. Набор ступеней называют лестницей битрейта. Подбор числа ступеней и их битрейтов – отдельное ремесло, оно разобрано в разделах о кодировании (per-title лестницы битрейта) и стриминге (разбор ABR).

За этим стоят два открытых стандарта. HLS (HTTP Live Streaming, интернет-стандарт RFC 8216) использует мастер-плейлист, где каждая версия качества описана как отдельный Variant Stream, и клиент переключается между ними, когда меняются условия сети [2]. MPEG-DASH (стандарт ISO/IEC 23009-1) делает то же через несколько Representation внутри Adaptation Set [3]. Оба адаптивны потому, что клиент сам измеряет пропускную способность и заполнение буфера и сам переключает ступени; логика переключения разобрана в статьях Фора Софт про ABR.

Для охвата на слабой сети важнее всего нижняя ступень. Многие команды строят лестницу от 480p до 1080p, а 480p всё ещё требует около мегабита в секунду – слишком много для перегруженной вышки в посёлке. Настоящая нижняя ступень (240p или 360p на несколько сотен kbps) – это то, что вообще позволяет смотреть урок на самом слабом соединении. Даже примерная лестница в руководстве Apple по HLS начинается с 416×234 на 145 kbps и 640×360 на 365 kbps в H.264 [7]. Типичная ошибка – тестировать только на быстрой офисной сети, где плеер не опускается до нижней ступени, и не заметить, что её нет.

Где хранить лестницу – тоже вопрос охвата. Если видео лежит на готовой платформе (российские компании, уходя с зарубежных сервисов, переносят видеобиблиотеки на Kinescope, Boomstream, Facecast и Yandex Cloud Video [15]), проверьте, какая там нижняя ступень и можно ли её настроить. Если лестницу собираете сами, раздавайте её через CDN с узлами в России: например, Yandex Cloud CDN кеширует медиаконтент на геораспределённых серверах ближе к учащемуся [13].

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

Считаем трафик

Здесь всё решают цифры. Объём данных – это битрейт, умноженный на время. Для одного часа видео:

• 720p на ~2,5 Mbps: 2,5 Mbps × 3 600 секунд = 9 000 мегабит ÷ 8 = 1 125 мегабайт ≈ 1,1 ГБ в час [9].
• 360p на ~0,75 Mbps: 0,75 × 3 600 = 2 700 мегабит ÷ 8 = 337 мегабайт ≈ 0,34 ГБ в час [9].
• Только аудио, речь, кодек Opus на 24 kbps: 24 kbps × 3 600 = 86 400 килобит ÷ 8 = 10 800 килобайт ≈ 11 МБ в час [1].

Получается, что один и тот же часовой урок весит примерно 1,1 ГБ, 340 МБ или 11 МБ в зависимости от способа доставки – разброс около 100×. Сравните с лимитным тарифом: если в месячном пакете учащегося 5 ГБ, одна HD-лекция на 1,1 ГБ съедает пятую часть пакета, версия в 360p – втрое меньше, а аудиоверсия почти незаметна. Эта арифметика и есть довод в пользу каждого рычага ниже: каждый удешевляет урок для учащегося, не выталкивая его из курса. (Как те же расходы выглядят со стороны платформы, разобрано в статьях Масштабирование доставки: CDN, транскодинг и стоимость при больших объёмах и Модель стоимости платформы обучения.)

Рычаг 2. Режимы для слабой сети в live-занятиях

Живое занятие сложнее записанного урока: видео создаётся и доставляется в реальном времени, заранее его не забуферизуешь. Стандартная технология здесь – WebRTC (Web Real-Time Communication, браузерный стандарт для живого аудио и видео), и на слабой сети она деградирует в заданном порядке, а не зависает. Устройство протокола описано в разборе WebRTC от Фора Софт; здесь – что даёт учащемуся каждый шаг.

Первый шаг – адаптивное качество видео, аналог лестницы битрейта для live. Благодаря simulcast или масштабируемому видеокодированию (SVC) медиасервер SFU (Selective Forwarding Unit, пересылает потоки между участниками) может отправлять учащемуся с плохим каналом слой с меньшим разрешением или частотой кадров, а остальным – полный, причём без перекодирования [12]. Когда полоса учащегося падает, SFU просто пересылает ему меньше слоёв: картинка становится мельче или дёрганее, но не застывает. Механика описана в статье Simulcast и SVC в SFU, а управление перегрузкой – в оценке полосы в WebRTC.

Второй шаг защищает поток, без которого занятия нет: голос преподавателя. Аудио весит ничтожно мало по сравнению с видео, и кодек Opus (аудиостандарт WebRTC, RFC 6716) создан как раз для таких условий. Opus работает в диапазоне от 6 до 510 kbps и меняет битрейт на лету без перезапуска сессии, подстраиваясь под сеть пакет за пакетом [1]. Спецификация называет оптимальные битрейты для речи: 8–12 kbps для узкополосной, 16–20 kbps для широкополосной и 28–40 kbps для полнополосной [1]. Для плохих каналов в нём есть два механизма. Встроенная упреждающая коррекция ошибок (FEC) повторяет важный фрагмент речи с низким битрейтом в следующем пакете, чтобы одна потеря не оставила пропуска. Прерывистая передача (DTX) в паузах отправляет лишь один пакет раз в 400 мс и экономит трафик [1]. Подробнее об аудио – в разборе кодека Opus.

Третий шаг – последний рубеж: аудио со слайдами, затем только аудио. Когда канал не тянет даже нижний слой видео, хорошо сделанный виртуальный класс перестаёт передавать изображение с камеры и оставляет голос плюс общий слайд или доску. Они обновляются только при смене слайда и почти ничего не стоят. Если не хватает и этого, учащегося удерживает в уроке один голос на паре десятков kbps. Этот принцип называют плавной деградацией: вместо застывшего чёрного экрана учащийся всегда получает следующий, более лёгкий режим, в котором урок продолжается.

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

Рычаг 3. Скачивание для офлайн-просмотра

Иногда связь не медленная, а прерывистая или её нет вовсе: учащийся в дороге, полевой сотрудник между объектами, студент, у которого вечером дома есть Wi-Fi, а утром в электричке нет сети. Для них рычаг – скачивание офлайн: забрать урок, пока есть связь, и посмотреть позже без сети. Это стандартный приём мобильных медиаприложений, и платформы дают для него готовые компоненты: например, в библиотеке Android Media3 есть менеджер загрузок, который докачивает файлы в фоне даже при закрытом приложении [10].

Офлайн-просмотр ставит вопрос, важный именно для учебного продукта: как учитывать прогресс, накопленный без связи? Ответ – стандарт учебных записей xAPI (Experience API). Он фиксирует каждое учебное событие как короткое утверждение, например «Мария завершила модуль 3». Утверждение – небольшой фрагмент данных, поэтому приложение может хранить их на устройстве, пока нет сети, и отправить пачкой в хранилище учебных записей (LRS), когда связь вернётся [6]. Учащийся смотрит урок в электричке, события копятся на телефоне, а когда связь появляется, записи синхронизируются и дашборд обновляется так, будто человек всё время был онлайн. Есть и требование не инженерного характера: LRS хранит персональные данные учащихся, а сбор и хранение ПДн граждан РФ в базах за пределами России запрещены (ч. 5 ст. 18 152-ФЗ) [14], поэтому хранилище, куда уходит очередь, должно стоять в российском контуре. Как точно фиксировать события просмотра видео, разобрано в статье Трекинг видео через xAPI, а офлайн-стратегия в целом – в статье Офлайн и обучение при слабой связи.

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

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

Рычаг 4. Кодек и компромиссы качества

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

В 2026 году выбирают из трёх кодеков, и чем выше эффективность, тем уже поддержка устройств. H.264 (AVC), утверждённый в 2003 году, наименее эффективен, но декодируется почти на любом устройстве и в любом браузере [8]. H.265 (HEVC) примерно вдвое эффективнее (то же качество примерно при половине битрейта), и аппаратное декодирование для него есть на большинстве устройств примерно с 2017 года [8]. AV1, кодек без лицензионных отчислений, ещё примерно на 30–50% эффективнее H.265, но аппаратно декодируется в основном на устройствах, выпущенных примерно после 2020 года [8]. Подробное сравнение – в гиде по выбору кодека раздела о кодировании.

В чём ловушка. Учащийся на слабой сети очень часто ещё и пользуется старым дешёвым телефоном, а в таком телефоне может не быть аппаратного декодера эффективного кодека. Выпустите курс только в AV1 – и самый эффективный файл не запустится на устройстве, которому он нужнее всего, или будет декодироваться программно, сажая батарею и подтормаживая. Правильный для охвата ответ обычно такой: предлагать эффективный кодек и держать версию в H.264 как универсальный запасной вариант. Это та же логика, что и с нижней ступенью лестницы ABR: эффективный кодек, который телефон не декодирует, ничего не экономит, а просто отсекает учащегося.

Готовый план охвата

Соберём рычаги в конкретный курс: 40-часовая видеопрограмма для сотрудников с разной связью, от офиса в областном центре до вахтового посёлка. Записанные уроки раздаются лестницей HLS/DASH от 240p (около 300 kbps) до 1080p через CDN с узлами в России, в H.265 с запасной версией в H.264, чтобы видео шло даже на самом дешёвом телефоне. Live-занятия идут через WebRTC с simulcast и при проблемах с каналом переходят на аудио со слайдами, а затем на голос Opus на ~24 kbps. Мобильное приложение скачивает любой урок по Wi-Fi и складывает xAPI-утверждения в очередь на синхронизацию с LRS в российском контуре. Итог в трафике: учащийся, у которого есть только мобильный интернет, пройдёт все 40 часов в 360p примерно за 40 × 0,34 ГБ ≈ 13,6 ГБ или будет заниматься с live-группой в режиме аудио со слайдами за ничтожную долю этого объёма. В 720p та же программа обошлась бы в 44 ГБ, и для учащегося на лимитном тарифе курс был бы просто закрыт. Охват не прикручивают в конце: это четыре решения, которые принимают в самом начале.

Частые ошибки

Эти сбои всплывают, как только курс сталкивается с реальной сетью.

Тестирование только на быстром Wi-Fi. Самая частая причина, по которой нижней ступени нет, а на слабой сети всё ломается. Перед каждым релизом проверяйте продукт на искусственно замедленном канале (большинство браузеров умеют имитировать 3G).

Лестница битрейта без нижней ступени. Если лестница начинается с 480p, ей всё ещё нужен ~1 Mbps; учащийся с более слабым каналом получит бесконечную буферизацию, а не видео похуже. Всегда добавляйте настоящую ступень 240p/360p [2][3][7].

Хостинг, недоступный учащемуся. Урок, встроенный с замедленного зарубежного хостинга, не спасёт никакая лестница [5]. Держите видео на российской платформе или в своём облаке с CDN в России [13][15].

Отключение субтитров «ради экономии трафика». Субтитры весят несколько килобайт, тысячные доли от видео, и больше всего помогают именно на слабой сети: когда видео встало, урок можно продолжать по тексту. Кроме того, независимо от сети их требует WCAG 2.1 (критерии 1.2.2 и 1.2.4), на котором построен российский ГОСТ Р 52872-2019 [4]. Подробнее – в статье Субтитры, транскрипты и аудиоописание.

Только один эффективный кодек. Доставка только в AV1 или только в HEVC отсекает старые дешёвые устройства, которых особенно много у пользователей слабых сетей. Держите запасную версию в H.264 [8].

Нет офлайн-режима для аудитории с прерывистой связью. Если учащиеся теряют связь из-за самого характера работы или дороги, «только стриминг» им не подходит: нужны скачивание и синхронизация [6][10].

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

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

Фора Софт с 2005 года разрабатывает ПО для видеостриминга, real-time-связи на WebRTC и OTT-доставки. В обучении на слабых сетях сложность редко в каком-то одном рычаге: трудно свести все четыре в один продукт, где охват обеспечивается автоматически, а не ручной настройкой. Выбор между готовым и заказным решением здесь вполне конкретный. Готовый плеер даст базовую адаптивную лестницу, но почти не позволит управлять нижней ступенью, порядком деградации live, офлайн-скачиванием с синхронизацией и запасным кодеком для дешёвых устройств. Заказная разработка позволяет настроить всё это под реальные сети и телефоны ваших учащихся, но и ответственность за качество инженерии ложится на вас. Мы помогаем командам решить, как далеко стоит заходить продукту, а затем строим слой доставки так, чтобы учащийся с худшим соединением всё равно доучился. Тот же опыт стриминга, связи в реальном времени и адаптивной доставки мы применяем в продуктах для видеоконференций, OTT, телемедицины и видеонаблюдения.

Главное

• Чаще всего теряют учащегося с самой слабой сетью; охват – задача инженерии, а не контента.
• Час урока – это ~1,1 ГБ в 720p, ~340 МБ в 360p и ~11 МБ в виде аудио: разброс в 100 раз.
• Записанное видео: адаптивная лестница (HLS/DASH) с настоящей нижней ступенью 240p/360p и раздачей с узлов в России.
• Live-занятия: деградируйте плавно – нижний слой видео, затем аудио со слайдами, затем голос Opus.
• Офлайн-скачивание с очередью xAPI-утверждений сохраняет прогресс учащихся с прерывистой связью; LRS – в России.
• Держите запасную версию в H.264: у учащегося со слабой сетью часто старый дешёвый телефон.

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

• Видеообучение в формате mobile-first
• Офлайн и обучение при слабой связи
• Масштабирование доставки: CDN, транскодинг и стоимость при больших объёмах