¿La descarga HTTP progresiva es una alternativa viable a HLS / DASH / RTMP para proporcionar video en vivo?

Estoy trabajando en un sitio web que necesita transmitir video en vivo a los usuarios y, como tal, tuve que entender el lamentable estado de la tecnología actual de transmisión de video basada en navegador. Las soluciones más populares para la transmisión en vivo en la actualidad tienen problemas de compatibilidad; RTMP requiere Flash, HLS solo es compatible de forma nativa en Safari y Chrome para Android, DASH no es compatible de forma nativa en ninguna parte, y el uso de dash.js requiere Extensiones de origen de medios , que aún no son ampliamente compatibles.

Esto lleva a una pregunta que me parece obvia: ¿es posible usar una descarga progresiva simple como alternativa a protocolos como HLS, RTMP y DASH que requieren soporte de navegador o complementos?

La idea de usar la descarga progresiva para transmitir medios en vivo no tiene precedentes; la gente ya lo hace por audio. Herramientas como liveCaster le permiten transmitir audio MP3 en vivo a través de una única respuesta HTTP progresiva sin necesidad de un archivo MP3 pregrabado, y las bibliotecas como AmplitudeJS se han esforzado por agregar funciones relacionadas con este tipo de transmisión de audio en vivo .

Sin embargo, no he visto ninguna instancia de esta técnica utilizada en la naturaleza para video , y no puedo decir por qué. Parece que eliminaría una capa de problemas de compatibilidad complicados y complicados en el lado del navegador para una compensación relativamente pequeña. (Y la compatibilidad sigue siendo un gran problema para la transmisión en vivo, incluso cuando los profesionales lo hacen; si trato de ver videos en vivo en el iPlayer de la BBC en Firefox, solo me da un mensaje de error que me indica que instale Flash). Sin embargo, nadie está usando esta técnica, y nunca he visto a nadie mencionar la idea además de mí.

¿Por qué? ¿Existe una limitación fundamental que no veo que haría imposible simplemente transmitir un archivo de video como un MP4 a través de una descarga progresiva a medida que se genera, y reproducirlo en un <video>elemento a medida que se descarga?

— Mark Amery
fuente

¿No podría usar una biblioteca HLS javascript (por ejemplo, hls.js aquí: github.com/video-dev/hls.js/tree/master ) para agregar compatibilidad HLS de navegador cruzado para su página? Supongo que esto quizás no existía cuando hiciste esta pregunta originalmente ... pero ahora sí. :)

— stuckj

Su pregunta es válida y, en teoría, creo que puede usar descargas progresivas para la transmisión de video en vivo. En realidad, muchos videos de transmisión en línea como YouTube, etc., ya usan HTTP. Supongo que está hablando estrictamente de transmisión EN VIVO y no solo de transmisión.

Sin embargo, tendrá que implementar los casos de uso de Live Streaming. De lo contrario, los protocolos de transmisión (RTMP, etc.) lo hacen ellos mismos. Aquí hay algunas razones para preferir estos protocolos y arquitectura:

1. Velocidad de bits variable

La mayoría de los videos de transmisión en vivo están codificados en VBR y su video tendrá que adaptarse rápidamente a la congestión de red cambiante de su cliente. Por lo tanto, su video puede cambiar varias resoluciones en muy poco tiempo dependiendo de qué tan rápida o lenta sea la conexión del cliente.

De acuerdo con Wikipedia

Funciona detectando el ancho de banda de un usuario y la capacidad de la CPU en tiempo real y ajustando la calidad de una transmisión de video en consecuencia

2. Contenido en vivo

El punto más importante es que la transmisión en vivo significa contenido en vivo . A diferencia de la descarga progresiva HTTP, no puede almacenar en búfer en ningún momento. El usuario debe ver el último cuadro destinado a todo el mundo y no puede quedarse atrás.

3. Desactivar la búsqueda

Un problema menor, pero el protocolo no debe permitir específicamente que el usuario busque hacia atrás (y obviamente hacia adelante). Esto no solo debe controlarse en el nivel del reproductor de video sino también en el nivel de la red.

4. Desconexiones frecuentes / red poco confiable

No estoy muy claro sobre este punto, pero sé que una vez que se desconecta una descarga HTTP entrante, puede tomar algún tiempo establecer otro protocolo de enlace (incluso con keep-alive). Los protocolos en vivo son mucho más rápidos de conectar y desconectar debido al siguiente punto ->

5. Latencia

HTTP se ejecuta inherentemente sobre TCP, lo que garantiza la entrega garantizada de paquetes. Compare esto con UDP usado en muchos protocolos (especialmente en juegos multijugador en vivo) donde la velocidad se prioriza sobre las garantías.

Para obtener más información, consulte aquí -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. Copia de contenido

La mayoría de los servidores de transmisión en vivo solo responderán al contenido de la hora actual. Aunque todavía es posible copiar contenido de transmisiones en vivo, uno tiene que recurrir a la captura de pantalla, etc. Dar una descarga progresiva HTTP hace que la tarea de copiar contenido sea bastante trivial (por lo tanto, hay muchos descargadores de YouTube).

Ahora, HTTP puede ser modelado para proporcionar la mayor parte de lo anterior.

Usted mencionó que el HTTP Live Streaming (HLS) de Apple se acerca más a lo que está tratando de lograr.

Y se está llevando a cabo una investigación activa en este campo como se indica aquí -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

Estoy buscando más información y actualizaré esta respuesta.

— Gaurav Ramanan
fuente

Parece incorrecto mencionar la latencia como una desventaja del uso de la descarga progresiva de HTTP dado que los principales competidores incluyen DASH y HLS que entregan segmentos de video a través de múltiples solicitudes HTTP secuenciales. No conozco todos los detalles de los protocolos, pero supongo que el último enfoque requiere una latencia mínima de al menos la longitud del segmento que se utiliza, mientras que con el enfoque de descarga progresiva no hay una latencia mínima teórica: una latencia más baja debería ser un anuncio de vista del enfoque de la descarga progresiva, ¿verdad?

— Mark Amery

Además, algunas de las otras preocupaciones aquí, como buscar y recuperarse de desconexiones, son problemas que se aplican por igual a una implementación de JavaScript de DASH, pero presumiblemente dash.js los supera. Me imagino que podrían superarse para un reproductor de descarga progresiva simplemente robando cualquier solución que los desarrolladores de dash.js hayan presentado.

— Mark Amery

@ MarkAmery Si se compara con DASH y HLS, sí, supongo que es comparable. Pero, si lo compara con algunos de los protocolos más antiguos que están sobre UDP, ¡HTTP pierde fácilmente! Incluso si ve que muchos sistemas en tiempo real hoy en día están construidos usando Websockets y evitan HTTP debido a sus problemas de latencia.

— Gaurav Ramanan

Sin embargo, la facilidad de copia de contenido es una desventaja real sobre dash.js y HLS. Y no estoy seguro de cómo se podrían implementar flujos de velocidad de bits variables utilizando la descarga progresiva, aunque espero que sea posible con un poco de astucia.

— Mark Amery

@ MarkAmery Cuando se trata de transmisión en tiempo real y en vivo, debemos considerar el rendimiento y no solo la posibilidad. Examinaré DASH, pero me pregunto si hay puntos de referencia que muestren comparaciones de rendimiento entre los Protocolos de transmisión y la recuperación de HTTP de una desconexión.

— Gaurav Ramanan