[Jderobot] Streaming de Video en browsers con HTML5

[Daniel Castellano]

Hola,

Respondo en tu mensaje :)

Un saludo!

El 12 de julio de 2013 13:59, Oscar Garcia <
oscar.robotica en linaresdigital.com> escribió:
El 12/07/2013 13:23, Daniel Castellano escribió:
> 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

Dos cosas:
1.- El problema no radica en bitrate variable o constante, radica en que
el codec no saca información al flujo de datos hasta que no pasa una
serie de fotogramas llamados "grupo de imágenes" [1]. En una estructura
M=x, N=16 (por ejemplo, N puede ampliarse o reducirse manualmente e
incluso puede ponerse dinámico) hasta que no pasan (a 25 imágenes por
segundo) 16/25 s = 640 ms de vídeo no se da salida a los fotogramas
procesados. A eso hay que agregar otras latencias (de la pila TCP de
salida, RTT/2 de red, pila TCP de recepción, tiempo de decodificación, etc).

Claro, pero esto es inevitable, no puedes adivinar los fotogramas
futuros... el quid aquí estaría en saber cómo de pequeño debe ser N (a más
pequeño, menos latencia, pero menor compresión); si lo llevamos al extremo
(N=1) tendremos lo mismo que si enviamos las imágenes como JPG.
Si el problema es de latencia, crean una matriz pequeña (N=4, por ejemplo,
serían 160ms; eso suponiendo que se llegue a los 25fps...), que a lo mejor
no nos sirve para comprimir mucho, pero será mejor que enviar los JPG "a
las bravas"

2.- ¿Qué reproductor usáis para que os pida la duración del evento?
Nunca hemos tenido ese problema en nuestro caso.

El reproductor para el HTML5 es el propio navegador (otra cosa es cómo lo
implemente cada uno). Lo de enviar la duración del vídeo es algo que
entendía que hay que hacer, porque al renderizar el vídeo te muestra una
barrita con el progreso, si no tiene la duración... cómo sabe por donde va?
XD (no sé si hay alguna opción para que no muestre la barra de progreso o
algo...)

> 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...


De nuevo son dos cosas:

1.- Se puede codificar en H.264 desde opencv (si mal no recuerdo usa
ffmpeg), pero me gusta más este proyecto que quizá sea interesante
seguir: [2].

Sí, eso opción también la vi, pero utilizaba el XServer para hacerlo y yo
no lo tengo instalado en el rasperry (aparte de que me parecía una
guarrada...)

2.- MJPEG sólo despilfarra ancho de banda, se comporta exactamente igual
que si codificaras en MPEG con una estructura M=0, N=1. La codificación
JPEG es MUY liviana en cuanto al uso de CPU y memoria comparada con la
codificación MPEG con un M y N mayores de 1, pero a cambio pierdes la
eficiencia de ancho de banda de la codificación basada en predicciones,
estimaciones y diferencias.

En las dos pruebas que hice, no me metí a fondo, pero MJPG me carga algo
más el procesador que el VLC enviando el vídeo (un 90% y un 80% más o
menos); eso sí, estoy hablando de que lo hice en una raspberry (procesador
mononúcleo de 700MHz) y que esta también tiene una GPU, que entiendo que
VLC lo aprovecha, pero MJPG no. Para un PC la diferencia entre usar la GPU
o no (para tamaños de videos no muy grandes) a lo mejor no es mucha, pero
en mi caso se nota bastante. Es decir, el procesamiento de JPG es más
ligero, pero en mi caso se desperdicia la GPU.

Un saludo.


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

> El 12/07/2013 13:23, Daniel Castellano escribió:
> > 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
>
> Dos cosas:
> 1.- El problema no radica en bitrate variable o constante, radica en que
> el codec no saca información al flujo de datos hasta que no pasa una
> serie de fotogramas llamados "grupo de imágenes" [1]. En una estructura
> M=x, N=16 (por ejemplo, N puede ampliarse o reducirse manualmente e
> incluso puede ponerse dinámico) hasta que no pasan (a 25 imágenes por
> segundo) 16/25 s = 640 ms de vídeo no se da salida a los fotogramas
> procesados. A eso hay que agregar otras latencias (de la pila TCP de
> salida, RTT/2 de red, pila TCP de recepción, tiempo de decodificación,
> etc).
>
> 2.- ¿Qué reproductor usáis para que os pida la duración del evento?
> Nunca hemos tenido ese problema en nuestro caso.
>
>
> > 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...
>
>
> De nuevo son dos cosas:
>
> 1.- Se puede codificar en H.264 desde opencv (si mal no recuerdo usa
> ffmpeg), pero me gusta más este proyecto que quizá sea interesante
> seguir: [2].
> 2.- MJPEG sólo despilfarra ancho de banda, se comporta exactamente igual
> que si codificaras en MPEG con una estructura M=0, N=1. La codificación
> JPEG es MUY liviana en cuanto al uso de CPU y memoria comparada con la
> codificación MPEG con un M y N mayores de 1, pero a cambio pierdes la
> eficiencia de ancho de banda de la codificación basada en predicciones,
> estimaciones y diferencias.
>
> Un saludo.
>
>
> [1] http://en.wikipedia.org/wiki/Group_of_pictures
> [2] https://code.launchpad.net/~alex-stevens/+junk/spyPanda
> <https://code.launchpad.net/%7Ealex-stevens/+junk/spyPanda>
> _______________________________________________
> 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/15f364bd/attachment.htm