Cuáles son las opciones de transmisión de HTML5 (y por qué “MP4 Streaming” está fuera de la lista)?

Nuestros clientes a menudo nos preguntan si nuestro servidor puede hacer “transmisión de mp4 a HTML5”. En el 99% de los casos, no entienden de qué están hablando. Sin embargo, no es justo culparlos. La terminología confusa, la complejidad técnica y la abrumadora variedad de formas de transmitir videos en la web, hacen que cualquiera pueda confundirse.

En este artículo, intentaremos aclarar de una vez por todas la confusión. Le diremos qué tipos de transmisión HTML5 hay, cuáles son buenos y por qué, por el amor de Dios, no puedes decir “transmisión mp4”.

Glosario

El video HTML5 es cuando pones una etiqueta <video>en tu página web y le configuras un src determinado. La transmisión de HTML5 es lo mismo, pero cuando src apunta no a un archivo de video completo, sino a una transmisión de video en constante actualización. Por ejemplo, YouTube hace video HTML, Twitch hace streaming HTML5.

A la etiqueta <video> no le importa cómo se forma o transmite la transmisión, ni si el navegador podrá reproducirla. Solo le importa que src apunte a cualquier flujo de video. Técnicamente hablando, la especificación HTML5 no dice nada sobre qué protocolos, transportes o códecs deben usarse con el video HTML5.

El protocolo define cómo las partes comunicantes intercambian datos para recibir datos. Las dos partes son casi siempre un cliente y un servidor, siendo el cliente el que inicia la comunicación. La transmisión puede fluir del servidor al cliente (reproducción de video) o del cliente al servidor (transmisión). Incluso cuando una supercomputadora monstruosa petaFLOPS se conecta a una pequeña cámara IP, la supercomputadora es el cliente y la cámara es el servidor.

Un protocolo suele implicar al menos el comando Reproducir (“iniciar reproducción”), pero puede haber otros como pausar, continuar, retransmitir, adelantar, etc.

Ejemplos de protocolos: RTSP, RTMP, HTTP, HLS, IGMP.

Transporte, también conocido como contenedor de transporte o como simplemente contenedor, define cómo se empaqueta el video comprimido en bytes para su transmisión por cable de una parte a otra (usando algún protocolo).

Algunos ejemplos de contenedores son MPEG-TS, RTMP, RTP.

Ten en cuenta que RTMP es tanto un protocolo como un transporte. Esto se debe a que la especificación de RTMP describe cómo deben interactuar las partes que se comunican para que fluya la transmisión de video (es decir, el protocolo) y cómo se debe empaquetar el video (es decir, transportar). Aunque este no es siempre el caso. Por ejemplo, el protocolo RTSP utiliza transporte RTP.

Codec en realidad significa muchas cosas, pero en nuestro caso es simplemente una forma de comprimir video sin procesar. Los códecs tratan de comprimir el video antes de la transmisión, los transportes tratan de enviar el video comprimido a través de un protocolo en particular. La mayoría de los servicios de transmisión no se ocupan de la compresión a nivel de códec y solo funcionan con protocolos y transportes.

Ejemplos de códigos: h264, aac, mp3.

Debido a que la palabra códec puede significar muchas cosas relacionadas, es fácil confundirse. Por ejemplo, H.264 es un estándar para comprimir grandes fotogramas de video en una pequeña cantidad de bytes, libx264 es una biblioteca de compresión de video que usa este estándar, y también hay un software epónimo para Windows que decodifica h264 y lo reproduce en la pantalla.

En resumen, la especificación HTML5 no describen protocolos, transportes ni códecs. Es por eso que los desarrolladores de navegadores son libres de elegir qué combinaciones admitir. Todas estas combinaciones diferentes se denominan “transmisión de HTML5”.

Sin embargo, existen combinaciones compatibles con la mayoría de los navegadores. Veamos los más prometedoras.

HLS

HLS es video comprimido h264 con audio comprimido aac o mp3, transportado con MPEG-TS. La transmisión se divide en fragmentos descritos en las listas de reproducción m3u8 y se transmite a través de HTTP. HLS admite transmisiones de velocidad de bits múltiples, Live/VOD. HLS es en general bastante simple pero a la vez complejo, por lo que se comporta de manera diferente en diferentes dispositivos.

HLS fue desarrollado por Apple e inicialmente solo funcionaba en Safari en iOS y Mac. Incluso ahora, Safari para Windows no puede reproducir HLS. Sin embargo, a día de hoy casi todos los STB y dispositivos Android pueden hacerlo.

No obstante, existe un problema grave con la compatibilidad con HLS en reproductores de terceros. En cierto punto, sus desarrolladores abandonaron el estándar de Apple para entregar múltiples pistas de audio y agregaron todo lo que hay en MPEG-TS normal: video mpeg2, audio mpeg2, etc. Por eso, debes proporcionar diferentes formatos de lista de reproducción para diferentes reproductores.

MPEG-DASH

MPEG-DASH generalmente es un video comprimido h264/h265 con audio aac transportado con mp4, o vp8/vp9 transportado con WebM. Sin embargo, el estándar no está vinculado a ningún códec, protocolo o transporte en particular. Al igual que con HLS, la transmisión se puede dividir en partes, pero aquí es opcional. En lugar de listas de reproducción, MPEG-DASH utiliza manifiestos MPD en formato XML.

MPEG-DASH es similar a HLS en muchos aspectos. Puede ser incluso más popular, ya que gigantes como YouTube y Netflix lo han estado usando durante años y es un medio muy popular para entregar contenido.

La ventaja de MPEG-DASH es que es compatible de forma nativa en la mayoría de los navegadores a través de MSE (lea a continuación). Ni siquiera tiene una implementación basada en Flash, lo que lo convierte en HTML5 puro y sin concesiones.

MPEG-DASH es definitivamente la transmisión HTML5 pura del futuro.

MSE

Cuando finalmente quedó claro que Flash estaba desapareciendo (después de lo que parecieron cientos de intentos fallidos), nos vimos cara a cara con la pregunta de qué reemplazaría a Flash. Sería genial tener una forma de reproducir un video en un navegador tan fácilmente como nos lo permite Flash, y con una calidad comparable.

Durante mucho tiempo, Flash ha tenido un conveniente mecanismo para reproducir varios tipos de video llamado appendBytes. Funciona así: El código propio del cliente obtiene los fotogramas de un video comprimido, los empaqueta en un contenedor acordado (con Flash es flv) y los coloca en un reproductor. Lo importante es que el protocolo y el transporte se implementan con el código del cliente que se esta ejecutando en el navegador.

MSE (Media Sourses Extensions, por sus siglas en ingles) es una extensión de la especificación HTML5 que proporciona un mecanismo similar a appendBytes. Desafortunadamente, MSE es mucho más difícil de entender e implementar.

MPEG-DASH se basa en MSE y es aún más complicado. Por lo tanto, algunos aspectos de trabajar con MPEG-DASH son bastante dolorosos: Toneladas de XML, analizar contenedores binarios con JavaScript, lidiar con políticas de segmentación mal diseñadas.

Curiosamente, MSE también funciona con HLS. Existe una implementación llamada hls.js que descarga listas de reproducción de HLS y fragmentos de MPEG-TS, los vuelve a empaquetar en un formato compatible con MSE y los reproduce a través de MSE. Apple incluso hizo un movimiento hacia la compatibilidad MPEG-DASH mediante el uso de contenedores mp4 en HLS.

A finales de 2017, es probable que Flash desaparezca por completo y ya es una buena idea empezar a utilizar MPEG-DASH para nuevos proyectos.

WebRTC

Flash combinó la comunicación y la radiodifusión en tiempo real bajo el mismo paraguas tecnológico. Desafortunadamente, HTML5 no está del todo bien. Tenemos MSE para transmisión y WebRTS, para videollamadas en línea.

WebRTC es básicamente SIP en el navegador, una forma de crear canales de audio, video y datos entre dos navegadores con la ayuda de un servidor en el medio.

Esta tecnología no está diseñada para la transmisión, pero técnicamente es capaz de hacerlo, por lo que sería un error que nos olvidáramos de ella en este artículo. WebRTC también se considera HTML5, ya que no requiere nada más que JavaScript en el navegador. Por otro lado, requiere las últimas versiones de los dos navegadores más populares y todavía no funciona en Microsoft Edge.

Una fuente importante de confusión que dificulta entender WebRTC es su uso en la entrega de TV basada en torrents. Lo que sucede es que los navegadores construyen una red de canales de datos con WebRTC y transmiten fragmentos de video basados ​​en HLS o MSE a través de esta red. La reproducción se realiza a través de Flash o MSE. En este escenario, WebRTC se usa para la entrega, MSE se usa para la reproducción, no confundir con el uso de WebRTC para la reproducción de video.

Cuál es el problema con la transmisión mp4?

Cualquier navegador moderno puede solicitar un archivo empaquetado mp4 comprimido con h264/aac a través de HTTP. Algunos incluso intentarán reproducirlo. Esta es la forma más conveniente, fácil de entender y estándar de reproducir archivos de video en línea. El archivo simplemente se coloca en un disco y se trata con nginx. El código responsable de la reproducción de mp4 en los navegadores es lo suficientemente sofisticado como para descargar videos en fragmentos (a diferencia de Flash Player que recupera el archivo completo de una vez).

Hay una cierta infamia en torno a h264 debido a su “cercanía”. Por lo tanto, existe una alternativa “abierta” forzada activamente por Google: Los códecs de video vp8 y vp9 empaquetados en el transporte WebM. WebM es un subconjunto del transporte mkv (también conocido como Matroska). WebM es similar a mp4 pero a diferencia de mp4 es “binario”. Aquí es de donde proviene todo este tema de “transmisión mp4”, que funciona como WebM. La cuestión es que, al comienzo de un archivo de video normal comprimido en mp4, se define el tamaño de todo el contenedor. Por lo tanto, no podemos transmitir en vivo a través de mp4. Para que funcione, hay un truco: Envía mp4 sin marcos y agregua bloques de marcos de varios segundos. Esto es lo que se llama mp4 fragmentado o mp4 streaming.

Con todo, no hay transmisión en absoluto. Es una combinación de elementos que te permite crear una impresión de una. Mp4 es un gran formato para videos descargables, pero no es apto para transmisión de video. Por lo tanto, es seguro olvidarse de mp4 en el contexto de la transmisión HTML5 y nunca decir “transmisión mp4”.

En resumen

• Las buenas opciones para la transmisión de HTML5 son MPEG-DASH y HLS. Funcionan en dispositivos móviles, computadoras de escritorio y STB.
• Flash morirá y MSE es lo que ocupará su lugar.
• WebRTC es una tecnología HTML5 principalmente para videollamadas, no para transmisión de video.
• Evita traer códecs antiguos a la web; mp2video y mp2audio no tienen lugar en HLS, incluso si el reproductor puede reproducirlo.
• No digas mas “mp4 streaming”. Por favor!

LEE MAS:

1. H.264 y H.265: ¿Cuál es la diferencia?