Incidencias de reproducción OTT: checklist para reunir evidencias

Checklist para reproducir, clasificar y documentar fallos de vídeo OTT sin confundir síntomas de red, formato, decodificación o protección.

Qué hace útil un informe de incidencia

Un fallo de reproducción se puede investigar cuando el informe permite repetirlo o acotar dónde ocurre. «El vídeo no funciona» no distingue un problema de acceso, red, playlist, segmento, decodificación, licencia o dispositivo. Registra el contenido, el momento, el entorno, la acción realizada y la evidencia disponible antes de atribuir una causa.

Esta checklist organiza la primera recogida de datos. No sustituye los registros del servicio, la documentación del reproductor ni una revisión de seguridad y privacidad.

1. Captura el contexto sin pedir datos innecesarios

Registra solo lo necesario para investigar el recorrido. Evita incluir contraseñas, claves, tokens completos o datos personales que no formen parte del diagnóstico.

Identificador de incidencia:
Fecha, hora y zona horaria:
Contenido o canal:
URL o identificador técnico:
Punto temporal aproximado:
Acción que desencadena el fallo:
Resultado esperado:
Resultado observado:
Mensaje o código exacto:
Aplicación o navegador y versión:
Dispositivo y sistema operativo:
Tipo de conexión:
Cuenta o perfil de prueba autorizado:
Frecuencia: siempre, intermitente o una vez:

Añade una captura o un registro solo si conserva el momento y el contexto. Un vídeo de pantalla sin hora, versión o contenido identificable puede mostrar el síntoma y seguir siendo insuficiente para reproducirlo.

2. Clasifica el fallo por la etapa observada

El estándar HTML mantiene estados de red y disponibilidad para los elementos de audio y vídeo, y diferencia errores por interrupción, red, decodificación y fuente no admitida. Esas categorías ayudan a ordenar la evidencia, pero el código del navegador no identifica automáticamente la causa raíz de toda la cadena.

Fuente: WHATWG, HTML Living Standard — Media elements, actualización de 20 de julio de 2026.

3. Comprueba playlists y segmentos cuando el recorrido usa HLS

La RFC 8216 describe playlists maestras y de medios, segmentos y rendiciones. Para una incidencia HLS, conserva qué playlist se abrió, qué variante seleccionó el reproductor y cuál fue la última solicitud correcta antes del fallo. Si hay cambios de codificación, tiempo o pista, comprueba también que las discontinuidades estén señaladas como exige el perfil utilizado.

No publiques URLs firmadas ni claves dentro del ticket. Si la dirección contiene credenciales temporales, conserva una referencia segura o una versión redactada junto al identificador de la solicitud.

Fuente: IETF, RFC 8216: HTTP Live Streaming, agosto de 2017.

4. Separa la entrega de datos de su incorporación al buffer

Media Source Extensions permite que JavaScript genere flujos para un elemento multimedia y sustenta casos como el streaming adaptativo. La especificación distingue errores de red y decodificación al terminar un flujo, y define condiciones que pueden producir errores al añadir datos al buffer.

En una investigación web, registra por separado:

• si la solicitud llegó a completarse;
• si el segmento se incorporó al buffer;
• si apareció un error de análisis o decodificación;
• si el fallo coincide con un cambio de representación, pista o discontinuidad;
• si el mismo contenido se reproduce con otra combinación admitida.

Fuente: W3C, Media Source Extensions, Recomendación de 17 de noviembre de 2016.

5. Trata el contenido cifrado como una etapa distinta

Encrypted Media Extensions define una API común para descubrir, seleccionar e interactuar con sistemas de protección de contenido. No define un DRM concreto ni resuelve por sí misma autenticación o autorización.

Si el contenido protegido falla, evita resumirlo como «error de vídeo». Anota si el problema surge al detectar capacidades, crear la sesión, intercambiar el mensaje de licencia, actualizar claves o iniciar la reproducción. Conserva el mensaje exacto de forma sanitizada y compáralo con un contenido de control autorizado.

Fuente: W3C, Encrypted Media Extensions, Recomendación de 18 de septiembre de 2017.

6. Usa telemetría del cliente solo si está disponible y definida

Common Media Client Data (CMCD) permite que un reproductor adjunte información estructurada sobre la sesión y la reproducción a las solicitudes de objetos multimedia. DVB documenta usos como análisis de logs, monitorización, optimización y localización de fallos, y contempla identificadores de sesión, estado del buffer y señales de inanición del buffer.

CMCD es opcional. Su presencia, claves y transporte dependen de la implementación. Antes de utilizarlo en un diagnóstico, documenta qué reproductores lo emiten, qué campos se recogen, dónde se conservan y cómo se protege la información. La ausencia de CMCD no demuestra que no haya ocurrido un fallo.

Fuente: DVB BlueBook C109, Commercial Requirements for the Use of CMCD in DVB-I, julio de 2024.

7. Compara controles que cambien una sola variable

Utiliza controles para reducir el espacio de búsqueda:

• mismo contenido en otro dispositivo admitido;
• otro contenido con el mismo perfil técnico;
• misma aplicación en otra red disponible para la prueba;
• pista alternativa del mismo contenido;
• tramo anterior y posterior al punto de fallo;
• contenido protegido y no protegido, cuando el caso lo permita.

Cambia una variable cada vez y registra el resultado. Una coincidencia temporal orienta la investigación, pero no prueba causalidad. Si el fallo es intermitente, conserva también los intentos correctos.

La matriz de requisitos para apps Smart TV ayuda a definir combinaciones de dispositivo y versión. Para incidencias de entrega y origen, consulta los criterios de CDN de vídeo y streaming sin asumir que toda parada procede de la red.

Plantilla de escalado

Resumen reproducible:
Primera y última hora observada:
Alcance confirmado:
Contenidos afectados y controles correctos:
Dispositivos y versiones:
Etapa donde aparece el síntoma:
Última operación correcta:
Primera operación fallida:
Códigos y mensajes sanitizados:
Registros disponibles y su fuente:
Hipótesis comprobadas:
Hipótesis abiertas:
Responsable actual:
Siguiente prueba y criterio de cierre:

Checklist antes de cerrar

• La incidencia incluye hora, zona, contenido, entorno y acción.
• El mensaje o código se conserva de forma literal y sanitizada.
• Se distingue acceso, manifiesto, entrega, buffer, decodificación y protección.
• Hay al menos un control útil o se explica por qué no puede ejecutarse.
• Las hipótesis están separadas de los hechos observados.
• No se han incluido secretos ni datos personales innecesarios.
• La siguiente prueba tiene responsable y criterio de cierre.
• La resolución indica qué evidencia demuestra que el fallo ya no se reproduce.

Para integrar estas pruebas en un criterio previo a lanzamiento, utiliza la matriz de validación OTT. Si necesitas revisar un incidente concreto, comparte con Fractal Media un resumen sin credenciales; el alcance técnico deberá confirmarse con la evidencia disponible.

Fuentes y revisión

Revisión editorial: 7 de octubre de 2026. La clasificación y las plantillas son una metodología de trabajo. Las fuentes describen estados y mecanismos técnicos; ninguna permite diagnosticar una causa concreta sin observar el caso.

• WHATWG: HTML Living Standard — Media elements, actualización de 20/07/2026.
• IETF: RFC 8216, HTTP Live Streaming, agosto de 2017.
• W3C: Media Source Extensions, 17/11/2016.
• W3C: Encrypted Media Extensions, 18/09/2017.
• DVB: BlueBook C109 sobre CMCD, julio de 2024.