[Jderobot] Streaming de Video en browsers con HTML5

[Oscar Garcia]

El 12/07/2013 14:25, Daniel Castellano escribió:
> 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"


Es justo lo que puse, estaríamos hablando prácticamente de MJPEG como 
solución de vídeo en streaming de baja latencia. Más que nada es una 
solución que requiere poco esfuerzo de desarrollo y ya está probado. En 
un móvil de 335M de RAM con una CPU de 1 GHz el servidor va bastante 
bien (aunque no hice métricas de consumo de CPU, lo haré para más adelante).



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


No he usado aún el reproductor de vídeo que te incorpora una página en 
HTML5, pero en principio, si es un streaming en vivo, no deberías tener 
que poner la duración en ningún lado, se supone que tampoco podrás ir 
adelante (las máquinas del tiempo aún no están inventadas) ni atrás (eso 
suele permitirse únicamente cuando es un archivo estático, aunque hay 
reproductores que soportan ir atrás un poco en el tiempo, pero sólo un 
tiempo definido que guardan en un buffer).



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


jderobot-user(1): ¡Compañeros!, ¿Qué somos?
jderobot-users(2..n): ¡PROGRAMADORES!
jderobot-user(1): ¿Y qué queremos?
jderobot-users(2..n): ¡PROGRAMAR UN SERVIDOR DE STREAMING H.264 RTSP! 
¡AUHH! ¡AUHHH! ¡AUHH!

Pues nada, ya tenemos algo de código, sólo queda destriparlo y quitar 
todo aquello que no necesitemos.



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


¿Qué usaste para codificar en JPEG los fotogramas? No parece demasiado 
eficiente...

Tengo muchas ganas de experimentar con la API de OpenMAX, te permite, 
entre otras cosas, codificar vídeo usando el hardware subyacente.

También tenemos la opción de programar un compresor JPEG en GPGPU como 
OpenGL ES 2.0 (yo estoy deseando jugar con mis GPUs :)...

Este verano quizá tengamos tiempo para jugar con todas estas tecnologías :)

Un saludo.