--- title: Players e a reserva OTT/DVR url: https://doc2.pstreamer.tv/pt/manual/extras/ott_players.html lang: pt-BR product: Perfect Streamer version: 2.0.2.423 --- # Players e a reserva OTT/DVR > **Importante** > > **Versão beta 2.1.** O que está descrito aqui existe apenas na versão beta 2.1: ela é instalada a partir do repositório beta e somente com uma licença; a versão estável 2.0.2 e a versão de demonstração não têm isso. A versão beta é fornecida sem garantias, e o suporte é prestado na medida do possível ([Programa de testes beta](beta.md#extras-beta)). A reserva OTT/DVR protege os espectadores da entrega OTT de duas formas, e depende do player quais delas estão disponíveis para ele ([Grupos OTT](../webui/reserves.md#webui-fleet-reserves-ott)): - **Troca durante a reprodução.** A playlist master HLS indica até dois outros nós do grupo OTT como variantes de reserva. Um player que sabe comutar para variantes de reserva passa sozinho para outro nó quando o seu nó deixa de servir a janela ao vivo, e o espectador não sai do player ([Troca dos espectadores para outro nó](../webui/reserves.md#webui-fleet-reserves-ott-failover)). - **Redirecionamento na abertura.** O nó responde com um redirecionamento `302` para outro nó do grupo se o espectador abre um fluxo que não está funcionando aqui ou pede o arquivo de um período fora do intervalo do arquivo deste nó; as lacunas dentro do intervalo o próprio nó atende. Se o período não estiver gravado em nenhum nó, a resposta é `404` (`reserve: no recording for this period`) ([Redirecionamento dos espectadores](../webui/reserves.md#webui-fleet-reserves-ott-redirects)). ## O que o player recebe O nó decide, pelo cabeçalho User-Agent do player e pelo parâmetro `rsv` no URL da playlist master, se lhe dá variantes de reserva. A tabela mostra o que o nó entrega a cada player. As respostas do nó foram verificadas para cada regra de User-Agent. A comutação para o nó de reserva em si só foi testada no Chrome no Windows (hls.js 1.5, página por HTTP); nos demais players e dispositivos, ela, assim como a troca por `302`, não foi testada nesta versão beta. | Player | Variantes de reserva (troca durante a reprodução) | Redirecionamento `302` (novo espectador, arquivo) | | --- | --- | --- | | Safari, iOS, tvOS, Apple TV (AVPlayer) | Sim; comutação não testada | Sim; não testado | | ExoPlayer e Media3 (Android, Android TV) | Sim; comutação não testada | Sim; não testado | | Players de navegador: hls.js, Shaka Player, Video.js | Sim, se o navegador enviar os cabeçalhos `Sec-Fetch-Mode` ou `Sec-Fetch-Dest` (navegadores modernos por HTTPS). A partir da versão 2.1.0.469, também sem eles, por exemplo por HTTP: se a requisição levar o cabeçalho `Origin` ou `Referer` de uma página do próprio nó (abaixo). Comutação testada no Chrome no Windows (hls.js 1.5, por HTTP, sem `rsv=1`); em outros navegadores, não testada | Sim; não testado | | Aplicativos de Smart TV com player de navegador (Tizen, webOS), Chromecast | Se o motor de navegador do dispositivo enviar os cabeçalhos `Sec-Fetch` e, a partir da versão 2.1.0.469, também sem eles, pela mesma regra dos navegadores por HTTP. Não testado | Sim; não testado | | Players integrados de Smart TV (AVPlay no Tizen, media player do webOS) | Não: não recebem variantes de reserva, a não ser com `rsv=1`. Não testado | Sim; não testado | | VLC e LibVLC, players baseados em ffmpeg, mpv, Kodi, GStreamer, ijkplayer, exteplayer | Não, nem com `rsv=1`: funcionam como antes | Sim. No VLC, o arquivo de outro nó foi testado; os demais, não testados | | Set-top boxes e players sem User-Agent | Não, nem com `rsv=1`: funcionam como antes | Sim; não testado | | Aplicativo próprio do operador | Com `rsv=1` no URL da playlist master; `rsv=0` desativa | Sim | **Player de navegador sem cabeçalhos Sec-Fetch** (a partir da versão 2.1.0.469). Os navegadores só enviam os cabeçalhos `Sec-Fetch` para endereços HTTPS, por isso antes um player de navegador em uma página HTTP não recebia variantes de reserva. Agora, uma requisição sem esses cabeçalhos é considerada de navegador se o seu User-Agent contém `Mozilla/`, se não é uma requisição de intervalo (`Range`) nem um carregamento de página, e se ela traz o cabeçalho `Origin` ou — para a página do player servida pelo próprio nó — `Referer` com o endereço e a porta deste nó. Testado no Chrome no Windows com hls.js 1.5: a playlist master indicou a reserva sem `rsv=1`, e, com a entrada do nó em pausa, o player passou para outro nó. Outros navegadores por HTTP não foram testados. O nó entrega o redirecionamento `302` a qualquer player, para HLS, LL-HLS e DASH: é um redirecionamento HTTP comum para o endereço completo de outro nó antes do início da reprodução. Os players costumam seguir os redirecionamentos sozinhos. Os players da lista «Não, nem com `rsv=1`», na inicialização ou ao receber uma resposta `404` para a playlist, abrem todas as variantes uma após a outra, por isso o nó nunca lhes dá linhas de reserva. Um player que não está na tabela e que não parece um player de navegador também não recebe variantes de reserva; acrescente `rsv=1` ao URL se ele souber usá-las, e teste a troca no seu player. Quantas playlists master o nó entregou sem reserva por causa do player é mostrado pela linha «Playlists mestres sem reserva» do bloco «Chave de visualização OTT» ([Troca dos espectadores para outro nó](../webui/reserves.md#webui-fleet-reserves-ott-failover)). ## Limitações e recomendações - **Somente fluxos HLS individuais.** Nesta versão beta, só recebem variantes de reserva os fluxos individuais cujos membros em nós diferentes usam a mesma origem. Os pacotes adaptativos e o LL-HLS ainda não sabem trocar de nó durante a reprodução, mas o redirecionamento na abertura funciona para eles. - **DASH.** Para o DASH, nesta versão beta, existe apenas o redirecionamento na abertura. - **Tempos limite do hls.js.** Defina tempos limite curtos para o carregamento da playlist e do segmento — cerca de uma duração-alvo de segmento, 2–3 segundos: assim o player sai rapidamente de um nó travado. - **Esquema do endereço.** O nó de reserva deve estar acessível ao espectador pelo mesmo esquema: uma página por HTTPS precisa de um endereço HTTPS do nó de reserva. Defina o «Nome do anfitrião» do servidor HTTP de cada nó como o nome para o qual o seu certificado foi emitido ([Servidor HTTP de streaming](../webui/administration.md#webui-http-server)). - **Áudio no navegador.** A partir da versão 2.1.0.469, a playlist master HLS indica o codec de áudio real do fluxo ([Modos de distribuição](../streamer/ott_dvr.md#streamer-ott-modes)); antes, qualquer canal era declarado como AAC, e um canal com áudio MP2 não tocava no navegador. - O AAC é suportado por todos os players de navegador. - MP2: o hls.js no Chromium agora o reproduz (só o áudio foi testado); Google Chrome, Edge, Firefox e Safari: não testado. MP3: não testado. - AC-3 e E-AC-3: o hls.js e o Shaka no Chrome e no Firefox de desktop não aceitam essa variante. Safari e Edge no Windows: não testado. - No LL-HLS e no DASH, os segmentos só levam áudio AAC ou AC-3: áudio MP2, MP3 ou E-AC-3 simplesmente não existe neles. O mais confiável para espectadores em navegador é uma faixa de áudio AAC no canal ou um transcodificador. - **O VLC e outros players sem variantes de reserva** não transferem uma reprodução em andamento para outro nó. Quando a entrada do nó para, o VLC reproduz o seu buffer até o fim, para e só em uma nova abertura recebe o `302` para outro nó; no teste, isso levou cerca de 40–50 segundos. O redirecionamento para o arquivo de outro nó foi testado no VLC. - **Vídeo entrelaçado no navegador.** Os players de navegador (hls.js e semelhantes baseados em MSE) decodificam de forma pouco confiável o H.264 entrelaçado com codificação de campos (PAFF, MBAFF) — é assim que costumam chegar os canais de radiodifusão SD 576i e HD 1080i. Após alguns segundos, a reprodução para com um erro de decodificação (`PIPELINE_ERROR_DECODE`); foi o que aconteceu, por exemplo, no Chrome no Windows com um canal 576i H.264 Main, enquanto o VLC exibia o mesmo canal normalmente. Para espectadores em navegador, dê ao canal uma cópia progressiva por meio de um transcodificador com a configuração «Deinterlace» ([Configurações do codificador](../streamer/transcoder.md#streamer-transcoder-encoder)). Set-top boxes, Smart TVs e o VLC reproduzem vídeo entrelaçado normalmente. Um canal entrelaçado pode ser identificado nas estatísticas do fluxo: no campo «Formato», depois da frequência vem `i`, por exemplo `1920x1080@50i` (no vídeo entrelaçado, é a frequência de campos, o dobro da de quadros); no progressivo, `p`. Com a «Análise profunda» ativada, o mesmo é mostrado pela linha «Tipo de varrimento» do bloco «Passaporte do codec de vídeo»: 2 — entrelaçado, 1 — progressivo. No H.264, o indicador `i` é colocado quando o fluxo admite codificação de campos, mesmo que o codificador, na prática, codifique apenas quadros. - **Erros de decodificação no seu próprio player.** O hls.js 1.5, ao encontrar um erro de decodificação, passa para o endereço de reserva como em uma falha do nó, e o elemento de reprodução continua defeituoso depois disso. Trate os erros de mídia chamando `hls.recoverMediaError()` e, se não adiantar, `hls.swapAudioCodec()` e de novo `hls.recoverMediaError()`, com um pequeno limite no número de tentativas. Não conte essa troca como falha do nó nas suas estatísticas. - **As legendas** permanecem no nó original após a troca. - **Cache e CDN** à frente dos nós: [8.1. Reserva OTT/DVR e CDN](ott_caching.md#extras-ott-cdn-reserve).