[Jderobot] Streaming de Video en browsers con HTML5

[Daniel Castellano]

Hola,

Yo las pruebas e investigaciones que hice fueron enfocadas al uso con
Raspberry, pero son extrapolables.

Aunque los formatos de vídeo que se pueden reproducir aún no son estandar,
el formato "WebM2 está implementados en los navegadores mayoritarios
(chrome, firefox y opera) y el formato "mp4" está soportado por estos y
también IExplorer (http://www.w3schools.com/html/html5_video.asp).

En mi caso probé a cargar vídeos enlatados en ambos formatos desde un
servidor Django y funcionaron los dos sin problemas.
La raspberry tiene un chip codificador H.264, así que en teoría podría
coger el flujo de la cámara y codificarlo "al vuelo" sin mucha latencia,
aunque no lo conseguí y terminé enviando las imágenes jpg por separado
(vamos, que se envían las imágenes como vídeo, si no como sucesión de
imágenes suelta, lo cual carga mucho la máquina...)

De los problemas que comenta Oscar, H.264 puede ser con bitrate variable o
continuo, así que no hay problema en ese aspecto (se declara como continuo
y listo); el problema con el que yo me topé para streaming en directo es
que no sabemos cuanto durará la retransmisión, y es un parámetro que
necesita el navegador

La otra opción (con plug-ins) que probé fue usar "VLC"; cargaba menos la
máquina y el resultado era el mismo (a nivel usuario, claro), pero el tener
que bajar un plug-in no me gustó, así que terminé utilizando
"MJPG-streamer", aunque cuando tenga tiempo (si lo tengo XD) intentaré de
nuevo codificar en H.264
Las dos opciones de streaming en vivo que probé (VLC y MJPG) tenían una
latencia bastante aceptable (como 1 segundo)

La solución ideal, a mi parecer, sería codificar en H.264 y si no, pues ya
depende de si puedes utilizar plugins o no; si no puedes, MJPG funciona
bien, dentro del "despilfarro" de recursos que supone...

Un saludo, Dani.


El 12 de julio de 2013 12:03, Oscar Garcia <
oscar.robotica en linaresdigital.com> escribió:

> El 12/07/2013 10:30, Roberto Calvo escribió:
> > Mirando diferentes maneras para reproducir un streaming de vídeo en un
> > browser con HTML5 sin necesidad de plugins externos, veo que está
> > complicado.
> >
> > En principio los formatos de streaming y codecs de video no son parte de
> > la estandarización de HTML5, aunque viendo el panorama están en ello. Se
> > comenta que MPEG o el nuevo MPEG-DASH [1] son los candidatos. MPEG-DASH
> > es similar al HLS de Apple.
>
> Buenos días.
>
> Yo he tratado de poner en marcha HLS en nuestro servidor de streaming
> (basado en flussonic) y no he conseguido configurarlo para streaming
> online (pero sí offline, en vídeos estáticos en disco).
>
> Aún así os recuerdo que eso incrementa enormemente la latencia en el
> streaming debido a que debe codificar secuencias completas, dividirlas
> en segmentos, cada uno en un bitrate diferente y luego generar el
> archivo con los índices a cada parte. Es decir, veo difícil aplicar HLS
> a streaming en tiempo real para jderobot (por ejemplo).
>
>
>
> > He preguntado a varios colegas que trabajan en sistemas de contenidos
> > audio-visuales y todos en sus sistemas tienen plugins para los
> > navegadores porque es imposible, de momento, reproducir el mismo
> > streaming con el tag video de HTML5.
>
>
> Nosotros optamos y pasado por varias soluciones, cuando usábamos windows
> media server usábamos windows media player en el navegador del cliente
> para reproducir el streaming. No funcionaba bien en Linux e incluso
> algunas veces en windows tampoco (dependiendo del navegador y otros
> detalles que ya no recuerdo).
>
> Hubo un intervalo de tiempo que apostamos por icecast2 y theora, pero el
> reproductor java que usábamos ponía la CPU de los equipos antiguos al
> 100% y la calidad de imagen no era buena si no había correspondencia de
> pixel 1:1 entre el vídeo y el tamaño del applet java.
>
> Con la llegada de flussonic a nuestro servicio empezamos a usar un
> reproductor en flash. Desde entonces todo va como la seda en cuanto al
> streaming de vídeo, se puede cambiar el tamaño del reproductor, poner a
> pantalla completa, etc... aunque no hemos conseguido hacer streaming en
> vivo usando bitrate dinámico (HLS).
>
>
> > Creo que Daniel también andaba o había mirado esto ¿llegaste a alguna
> > otra conclusión?
>
>
> Yo también he estado con el tema y en mi caso he optado para mis pruebas
> por usar MJPEG. A diferencia de MPEG no es necesario codificar una serie
> de fotogramas completos antes de poder empezar a enviar datos por el
> canal, por cada fotograma se envía por la conexión dicho fotograma
> codificado en JPEG y éste es recibido casi de inmediato por el otro
> extremo de la comunicación (el navegador web).
>
> Hay diferentes tipos de fotogramas en MPEG, fotogramas completos,
> fotogramas diferenciales (entre el fotograma actual y el anterior) y
> fotogramas diferenciales bidireccionales (hacia delante y hacia atrás),
> por lo que no se puede dar salida de una secuencia hasta que no se
> genere el próximo fotograma completo.
>
> Esto me suena que ya lo he escrito en esta lista o en alguna
> conversación con José María.
>
> Estos fueron los experimentos que realicé:
> http://www.youtube.com/watch?v=3UHwSxOfxqw
>
> Uso un navegador web normal para visualizar el streaming. Principalmente
> hay que destacar la baja latencia y número de imágenes por segundo del
> vídeo comparado con cameraserver:
> http://www.youtube.com/watch?v=_d_8pzFQOZ4
>
> Un saludo.
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20130712/8f923235/attachment.htm