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).

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):

• 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ó).

• 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).

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ó).

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).

• Á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); 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). 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.