--- title: Проигрыватели и резерв OTT/DVR url: https://doc2.pstreamer.tv/ru/manual/extras/ott_players.html lang: ru product: Perfect Streamer version: 2.0.2.423 --- # Проигрыватели и резерв OTT/DVR > **Важно** > > **Бета-версия 2.1.** Описанное здесь есть только в бета-версии 2.1: она ставится из бета-репозитория и только с лицензией, в стабильной версии 2.0.2 и в демоверсии этого нет. Бета-версия поставляется без гарантий, поддержка — по возможности ([Программа бета-тестирования](beta.md#extras-beta)). Резерв OTT/DVR защищает зрителей OTT-раздачи двумя способами, и от проигрывателя зависит, какие из них ему доступны ([OTT-группы](../webui/reserves.md#webui-fleet-reserves-ott)): - **Переход во время просмотра.** Master-плейлист HLS называет до двух других узлов OTT-группы резервными вариантами. Проигрыватель, который умеет переключаться на резервные варианты, сам уходит на другой узел, когда его узел перестаёт отдавать живое окно, и зритель не выходит из проигрывателя ([Переход зрителей на другой узел](../webui/reserves.md#webui-fleet-reserves-ott-failover)). - **Перенаправление при открытии.** Узел отвечает перенаправлением `302` на другой узел группы, если зритель открывает поток, который здесь не работает, или просит архив за период вне диапазона архива этого узла; пропуски внутри диапазона узел обслуживает сам. Если период не записан ни на одном узле, ответ — `404` (`reserve: no recording for this period`) ([Перенаправление зрителей](../webui/reserves.md#webui-fleet-reserves-ott-redirects)). ## Что получает проигрыватель Узел решает по заголовку 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» ([Переход зрителей на другой узел](../webui/reserves.md#webui-fleet-reserves-ott-failover)). ## Ограничения и советы - **Только одиночные потоки HLS.** В этой бета-версии резервные варианты получают только одиночные потоки, у которых участники на разных узлах берут один источник. Адаптивные наборы и LL-HLS переходить во время просмотра пока не умеют, но перенаправление при открытии у них работает. - **DASH.** Для DASH в этой бета-версии есть только перенаправление при открытии. - **Таймауты hls.js.** Задайте короткие таймауты загрузки плейлиста и сегмента — около одной целевой длительности сегмента, 2–3 секунды: тогда проигрыватель быстро уходит с зависшего узла. - **Схема адреса.** Резервный узел должен быть доступен зрителю той же схемой: странице по HTTPS нужен адрес HTTPS резервного узла. Задайте «Имя хоста» HTTP-сервера каждого узла, на которое выписан его сертификат ([Потоковый HTTP-сервер](../webui/administration.md#webui-http-server)). - **Звук в браузере.** С версии 2.1.0.469 master-плейлист HLS называет настоящий звуковой кодек потока ([Режимы раздачи](../streamer/ott_dvr.md#streamer-ott-modes)); раньше любой канал объявлялся как 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» ([Настройки кодера](../streamer/transcoder.md#streamer-transcoder-encoder)). Приставки, 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](ott_caching.md#extras-ott-cdn-reserve).