Reproductores y reserva OTT/DVR

Importante

Versión beta 2.1. Lo que se describe aquí solo existe en la versión beta 2.1: se instala desde el repositorio beta y solo con una licencia; la versión estable 2.0.2 y la versión de demostración no lo incluyen. La versión beta se suministra sin garantías y el soporte se presta en la medida de lo posible (Programa de pruebas beta).

La reserva OTT/DVR protege a los espectadores de la distribución OTT de dos maneras, y cuáles de ellas están al alcance de un reproductor depende de este (Grupos OTT):

• Cambio durante la reproducción. La playlist master HLS designa hasta dos nodos más del grupo OTT como variantes de respaldo. Un reproductor capaz de cambiar a variantes de respaldo pasa por sí mismo a otro nodo cuando su nodo deja de servir la ventana en vivo, y el espectador no sale del reproductor (Paso de los espectadores a otro nodo).

• Redirección al abrir. El nodo responde con una redirección 302 a otro nodo del grupo si el espectador abre un flujo que aquí no funciona o pide el archivo de un periodo fuera del rango de archivo de este nodo; los huecos dentro del rango los atiende el propio nodo. Si el periodo no está grabado en ningún nodo, la respuesta es 404 (reserve: no recording for this period) (Redirección de los espectadores).

Qué recibe el reproductor

El nodo decide, según la cabecera User-Agent del reproductor y el parámetro rsv de la dirección de la playlist master, si le da variantes de respaldo. La tabla muestra lo que el nodo sirve a cada reproductor. Las respuestas del nodo se han comprobado para cada regla de User-Agent. El propio cambio al nodo de respaldo solo se ha comprobado en Chrome en Windows (hls.js 1.5, página por HTTP); en los demás reproductores y dispositivos, al igual que el paso mediante 302, no se ha comprobado en esta versión beta.

Reproductor	Variantes de respaldo (cambio durante la reproducción)	Redirección 302 (espectador nuevo, archivo)
Safari, iOS, tvOS, Apple TV (AVPlayer)	Sí; el cambio no se ha comprobado	Sí; no se ha comprobado
ExoPlayer y Media3 (Android, Android TV)	Sí; el cambio no se ha comprobado	Sí; no se ha comprobado
Reproductores de navegador: hls.js, Shaka Player, Video.js	Sí, si el navegador envía las cabeceras Sec-Fetch-Mode o Sec-Fetch-Dest (navegadores modernos por HTTPS). Desde la versión 2.1.0.469, también sin ellas, por ejemplo por HTTP: si la solicitud lleva la cabecera Origin o Referer de una página del propio nodo (más abajo). El cambio se ha comprobado en Chrome en Windows (hls.js 1.5, por HTTP, sin rsv=1); en otros navegadores, no se ha comprobado	Sí; no se ha comprobado
Aplicaciones de Smart TV con reproductor de navegador (Tizen, webOS), Chromecast	Si el motor de navegador del dispositivo envía las cabeceras Sec-Fetch y, desde la versión 2.1.0.469, también sin ellas, con la misma regla que los navegadores por HTTP. No se ha comprobado	Sí; no se ha comprobado
Reproductores integrados de Smart TV (AVPlay en Tizen, reproductor multimedia de webOS)	No: no reciben variantes de respaldo, salvo con rsv=1. No se ha comprobado	Sí; no se ha comprobado
VLC y LibVLC, reproductores basados en ffmpeg, mpv, Kodi, GStreamer, ijkplayer, exteplayer	No, ni siquiera con rsv=1: funcionan como antes	Sí. En VLC se ha comprobado el archivo desde otro nodo; en los demás, no se ha comprobado
Decodificadores y reproductores sin User-Agent	No, ni siquiera con rsv=1: funcionan como antes	Sí; no se ha comprobado
Aplicación propia del operador	Con rsv=1 en la dirección de la playlist master; rsv=0 lo desactiva	Sí

Reproductor de navegador sin cabeceras Sec-Fetch (desde la versión 2.1.0.469). Los navegadores envían las cabeceras Sec-Fetch solo a direcciones HTTPS, por lo que antes un reproductor de navegador en una página HTTP no recibía variantes de respaldo. Ahora una solicitud sin estas cabeceras se considera de navegador si su User-Agent contiene Mozilla/, no es una solicitud de rango (Range) ni la carga de una página, y lleva la cabecera Origin o, en el caso de la página de reproductor que sirve el propio nodo, Referer con la dirección y el puerto de este nodo. Comprobado en Chrome en Windows con hls.js 1.5: la playlist master designó el respaldo sin rsv=1 y, al pausar la entrada del nodo, el reproductor pasó a otro nodo. Otros navegadores por HTTP no se han comprobado.

El nodo sirve la redirección 302 a cualquier reproductor, para HLS, LL-HLS y DASH: es una redirección HTTP normal a la dirección completa de otro nodo antes de que empiece la reproducción. Los reproductores suelen seguir las redirecciones por sí mismos.

Los reproductores de la lista «No, ni siquiera con rsv=1» abren todas las variantes una tras otra al arrancar o cuando reciben un 404 a la playlist, por lo que el nodo nunca les da líneas de respaldo. Un reproductor que no figura en la tabla y no parece de navegador tampoco recibe variantes de respaldo; añada rsv=1 a la dirección si sabe usarlas y compruebe el cambio en su reproductor. Cuántas playlists master ha servido el nodo sin respaldo por causa del reproductor lo muestra la fila «Listas maestras sin respaldo» del bloque «Clave de visualización OTT» (Paso de los espectadores a otro nodo).

Limitaciones y consejos

• Solo flujos HLS individuales. En esta versión beta solo reciben variantes de respaldo los flujos individuales cuyos miembros en distintos nodos toman una misma fuente. Los conjuntos adaptativos y LL-HLS aún no saben cambiar durante la reproducción, pero la redirección al abrir sí funciona para ellos.

• DASH. Para DASH, en esta versión beta solo existe la redirección al abrir.

• Tiempos de espera de hls.js. Configure tiempos de espera cortos de carga de playlist y de segmento, de alrededor de una duración objetivo de segmento, 2–3 segundos: así el reproductor abandona rápidamente un nodo bloqueado.

• Esquema de la dirección. El nodo de respaldo debe ser accesible para el espectador con el mismo esquema: una página por HTTPS necesita una dirección HTTPS del nodo de respaldo. Configure en el servidor HTTP de cada nodo el «Nombre de host» para el que se ha emitido su certificado (Servidor HTTP de streaming).

• Audio en el navegador. Desde la versión 2.1.0.469, la playlist master HLS indica el códec de audio real del flujo (Modos de difusión); antes cualquier canal se declaraba como AAC, y un canal con audio MP2 no se reproducía en el navegador.

  • Todos los reproductores de navegador admiten AAC.

  • MP2: hls.js en Chromium ya lo reproduce (solo se ha comprobado el audio); Google Chrome, Edge, Firefox y Safari, no se ha comprobado. MP3, no se ha comprobado.

  • AC-3 y E-AC-3: hls.js y Shaka en Chrome y Firefox de escritorio no aceptan esa variante. Safari y Edge en Windows, no se ha comprobado.

  • En LL-HLS y DASH los segmentos solo llevan audio AAC o AC-3: allí no hay en absoluto audio MP2, MP3 ni E-AC-3.

  Lo más fiable para los espectadores en navegador es una pista AAC en el canal o un transcodificador.

• VLC y otros reproductores sin variantes de respaldo no trasladan a otro nodo una reproducción ya abierta. Cuando la entrada del nodo se detiene, VLC reproduce su búfer hasta el final, se detiene y solo al volver a abrir recibe un 302 a otro nodo; en la prueba esto llevó unos 40–50 segundos. La redirección al archivo de otro nodo se ha comprobado en VLC.

• Vídeo entrelazado en el navegador. Los reproductores de navegador (hls.js y similares basados en MSE) decodifican de forma poco fiable el H.264 entrelazado con codificación de campos (PAFF, MBAFF), que es como suelen llegar los canales de difusión SD 576i y HD 1080i. Al cabo de unos segundos, la reproducción se detiene con un error de decodificación (PIPELINE_ERROR_DECODE); así ocurrió, por ejemplo, en Chrome en Windows con un canal 576i H.264 Main, mientras que VLC mostraba el mismo canal con normalidad. Para los espectadores en navegador, dé al canal una copia progresiva mediante un transcodificador con el ajuste «Deinterlace» (Ajustes del codificador). Los decodificadores, los Smart TV y VLC reproducen el vídeo entrelazado con normalidad.

  Un canal entrelazado se reconoce en las estadísticas del flujo: en el campo «Formato», tras la frecuencia figura i, por ejemplo 1920x1080@50i (en el vídeo entrelazado es la frecuencia de campos, el doble de la de cuadros), y en el progresivo, p. Con el «Análisis profundo» activado, lo mismo indica la fila «Tipo de barrido» del bloque «Pasaporte de códec de vídeo»: 2, entrelazado; 1, progresivo. En H.264 el indicador i se pone cuando el flujo admite la codificación de campos, aunque en la práctica el codificador solo codifique cuadros.

• Errores de decodificación en su propio reproductor. Ante un error de decodificación, hls.js 1.5 pasa a la dirección de respaldo como si el nodo hubiera fallado, y el elemento de reproducción queda después averiado. Gestione los errores de medios llamando a hls.recoverMediaError() y, si no basta, a hls.swapAudioCodec() y de nuevo a hls.recoverMediaError(), con un pequeño límite de intentos. No cuente ese cambio como fallo del nodo en sus estadísticas.

• Los subtítulos permanecen en el nodo de origen después del cambio.

• Caché y CDN delante de los nodos: 8.1. Reserva OTT/DVR y CDN.