Проигрыватели и резерв OTT/DVR

Важно

Бета-версия 2.1. Описанное здесь есть только в бета-версии 2.1: она ставится из бета-репозитория и только с лицензией, в стабильной версии 2.0.2 и в демоверсии этого нет. Бета-версия поставляется без гарантий, поддержка — по возможности (Программа бета-тестирования).

Резерв OTT/DVR защищает зрителей OTT-раздачи двумя способами, и от проигрывателя зависит, какие из них ему доступны (OTT-группы):

• Переход во время просмотра. Master-плейлист HLS называет до двух других узлов OTT-группы резервными вариантами. Проигрыватель, который умеет переключаться на резервные варианты, сам уходит на другой узел, когда его узел перестаёт отдавать живое окно, и зритель не выходит из проигрывателя (Переход зрителей на другой узел).

• Перенаправление при открытии. Узел отвечает перенаправлением 302 на другой узел группы, если зритель открывает поток, который здесь не работает, или просит архив за период вне диапазона архива этого узла; пропуски внутри диапазона узел обслуживает сам. Если период не записан ни на одном узле, ответ — 404 (reserve: no recording for this period) (Перенаправление зрителей).

Что получает проигрыватель

Узел решает по заголовку User-Agent проигрывателя и параметру rsv в адресе master-плейлиста, давать ли ему резервные варианты. Таблица показывает, что узел отдаёт каждому проигрывателю. Ответы узла по каждому правилу User-Agent проверены. Само переключение на резервный узел проверено только в Chrome на Windows (hls.js 1.5, страница по HTTP); на остальных проигрывателях и устройствах оно, как и переход по 302, в этой бета-версии не проверено.

Проигрыватель	Резервные варианты (переход во время просмотра)	Перенаправление 302 (новый зритель, архив)
Safari, iOS, tvOS, Apple TV (AVPlayer)	Да; переключение не проверено	Да; не проверено
ExoPlayer и Media3 (Android, Android TV)	Да; переключение не проверено	Да; не проверено
Браузерные проигрыватели: hls.js, Shaka Player, Video.js	Да, если браузер отправляет заголовки Sec-Fetch-Mode или Sec-Fetch-Dest (современные браузеры по HTTPS). С версии 2.1.0.469 — и без них, например по HTTP: если запрос несёт заголовок Origin или Referer страницы самого узла (ниже). Переключение проверено в Chrome на Windows (hls.js 1.5, по HTTP, без rsv=1); в других браузерах — не проверено	Да; не проверено
Приложения Smart TV на браузерном проигрывателе (Tizen, webOS), Chromecast	Если браузерный движок устройства отправляет заголовки Sec-Fetch, а с версии 2.1.0.469 — и без них, по тому же правилу, что браузеры по HTTP. Не проверено	Да; не проверено
Встроенные проигрыватели Smart TV (AVPlay в Tizen, медиапроигрыватель webOS)	Нет: резервных вариантов не получают, кроме как с rsv=1. Не проверено	Да; не проверено
VLC и LibVLC, проигрыватели на основе ffmpeg, mpv, Kodi, GStreamer, ijkplayer, exteplayer	Нет, даже с rsv=1: работают как раньше	Да. У VLC архив с другого узла проверен; остальные — не проверено
Приставки и проигрыватели без User-Agent	Нет, даже с rsv=1: работают как раньше	Да; не проверено
Собственное приложение оператора	С rsv=1 в адресе master-плейлиста; rsv=0 отключает	Да

Браузерный проигрыватель без заголовков Sec-Fetch (с версии 2.1.0.469). Браузеры отправляют заголовки Sec-Fetch только на адреса HTTPS, поэтому раньше браузерный проигрыватель на странице HTTP резервных вариантов не получал. Теперь запрос без этих заголовков считается браузерным, если в его User-Agent есть Mozilla/, это не запрос диапазона (Range) и не загрузка страницы, и в нём есть заголовок Origin или — для страницы проигрывателя, которую отдаёт сам узел, — Referer с адресом и портом этого узла. Проверено в Chrome на Windows с hls.js 1.5: master-плейлист назвал резерв без rsv=1, а при паузе входа узла проигрыватель перешёл на другой узел. Другие браузеры по HTTP не проверены.

Перенаправление 302 узел отдаёт любому проигрывателю, для HLS, LL-HLS и DASH: это обычное перенаправление HTTP на полный адрес другого узла до начала воспроизведения. Проигрыватели обычно следуют перенаправлениям сами.

Проигрыватели из списка «Нет, даже с rsv=1» при старте или при ответе 404 на плейлист открывают все варианты подряд, поэтому узел никогда не даёт им резервных строк. Проигрыватель, которого нет в таблице и который не похож на браузерный, резервных вариантов тоже не получает; добавьте rsv=1 в адрес, если он умеет ими пользоваться, и проверьте переход на своём проигрывателе. Сколько master-плейлистов узел выдал без резерва из-за проигрывателя, показывает строка «Мастер-плейлисты без резерва» блока «Ключ просмотра OTT» (Переход зрителей на другой узел).

Ограничения и советы

• Только одиночные потоки HLS. В этой бета-версии резервные варианты получают только одиночные потоки, у которых участники на разных узлах берут один источник. Адаптивные наборы и LL-HLS переходить во время просмотра пока не умеют, но перенаправление при открытии у них работает.

• DASH. Для DASH в этой бета-версии есть только перенаправление при открытии.

• Таймауты hls.js. Задайте короткие таймауты загрузки плейлиста и сегмента — около одной целевой длительности сегмента, 2–3 секунды: тогда проигрыватель быстро уходит с зависшего узла.

• Схема адреса. Резервный узел должен быть доступен зрителю той же схемой: странице по HTTPS нужен адрес HTTPS резервного узла. Задайте «Имя хоста» HTTP-сервера каждого узла, на которое выписан его сертификат (Потоковый HTTP-сервер).

• Звук в браузере. С версии 2.1.0.469 master-плейлист HLS называет настоящий звуковой кодек потока (Режимы раздачи); раньше любой канал объявлялся как AAC, и канал со звуком MP2 в браузере не играл.

  • AAC поддерживают все браузерные проигрыватели.

  • MP2: hls.js в Chromium теперь его воспроизводит (проверен только звук); Google Chrome, Edge, Firefox и Safari — не проверено. MP3 — не проверено.

  • AC-3 и E-AC-3: hls.js и Shaka в настольных Chrome и Firefox такой вариант не принимают. Safari и Edge на Windows — не проверено.

  • В LL-HLS и DASH сегменты несут звук только AAC или AC-3: звука MP2, MP3 или E-AC-3 там нет совсем.

  Надёжнее всего для браузерных зрителей — дорожка AAC в канале или транскодер.

• VLC и другие проигрыватели без резервных вариантов открытый просмотр на другой узел не переносят. Когда вход узла останавливается, VLC доигрывает свой буфер, останавливается и только при новом открытии получает 302 на другой узел; в проверке это заняло около 40–50 секунд. Перенаправление к архиву другого узла в VLC проверено.

• Чересстрочное видео в браузере. Браузерные проигрыватели (hls.js и подобные на MSE) ненадёжно декодируют чересстрочное H.264 с кодированием полей (PAFF, MBAFF) — так обычно идут вещательные SD 576i и HD 1080i. Воспроизведение через несколько секунд останавливается с ошибкой декодирования (PIPELINE_ERROR_DECODE); так было, например, в Chrome на Windows с каналом 576i H.264 Main, а VLC тот же канал показывал нормально. Для зрителей в браузере дайте каналу прогрессивную копию через транскодер с настройкой «Deinterlace» (Настройки кодера). Приставки, Smart TV и VLC воспроизводят чересстрочное видео как обычно.

  Чересстрочный канал видно в статистике потока: в поле «Формат» после частоты стоит i, например 1920x1080@50i (у чересстрочного видео это частота полей, вдвое больше кадровой), у прогрессивного — p. При включённом «Глубоком анализе» то же показывает строка «Тип развёртки» блока «Паспорт видеокодека»: 2 — чересстрочная, 1 — прогрессивная. У H.264 признак i ставится, когда поток допускает кодирование полей, даже если кодер на деле кодирует только кадры.

• Ошибки декодирования в своём проигрывателе. hls.js 1.5 при ошибке декодирования переходит на резервный адрес, как при отказе узла, а элемент воспроизведения после этого остаётся неисправным. Обрабатывайте ошибки медиа вызовом hls.recoverMediaError(), а если не помогло — hls.swapAudioCodec() и снова hls.recoverMediaError(), с небольшим ограничением числа попыток. Такой переход не считайте в своей статистике отказом узла.

• Субтитры после перехода остаются на исходном узле.

• Кеш и CDN перед узлами: 8.1. Резерв OTT/DVR и CDN.