<div dir="ltr"><div><div>Hola,<br><br>Respondo en tu mensaje :)<br><br></div><div>Un saludo!<br></div><div><br>El 12 de julio de 2013 13:59, Oscar Garcia <span dir="ltr"><<a href="mailto:oscar.robotica@linaresdigital.com" target="_blank">oscar.robotica@linaresdigital.com</a>></span> escribió:<br>
El 12/07/2013 13:23, Daniel Castellano escribió:<br>
<div class="im">> De los problemas que comenta Oscar, H.264 puede ser con bitrate<br>
> variable o continuo, así que no hay problema en ese aspecto (se<br>
> declara como continuo y listo); el problema con el que yo me topé para<br>
> streaming en directo es que no sabemos cuanto durará la retransmisión,<br>
> y es un parámetro que necesita el navegador<br>
<br>
</div>Dos cosas:<br>
1.- El problema no radica en bitrate variable o constante, radica en que<br>
el codec no saca información al flujo de datos hasta que no pasa una<br>
serie de fotogramas llamados "grupo de imágenes" [1]. En una estructura<br>
M=x, N=16 (por ejemplo, N puede ampliarse o reducirse manualmente e<br>
incluso puede ponerse dinámico) hasta que no pasan (a 25 imágenes por<br>
segundo) 16/25 s = 640 ms de vídeo no se da salida a los fotogramas<br>
procesados. A eso hay que agregar otras latencias (de la pila TCP de<br>
salida, RTT/2 de red, pila TCP de recepción, tiempo de decodificación, etc).<br><br></div>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.<br>
</div>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"<br>
<div><div>
<br>
2.- ¿Qué reproductor usáis para que os pida la duración del evento?<br>
Nunca hemos tenido ese problema en nuestro caso.<br>
<div class="im"><br>
</div><div class="im">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...)<br>
</div><div class="im"><br>
> La solución ideal, a mi parecer, sería codificar en H.264 y si no,<br>
> pues ya depende de si puedes utilizar plugins o no; si no puedes, MJPG<br>
> funciona bien, dentro del "despilfarro" de recursos que supone...<br>
<br>
<br>
</div>De nuevo son dos cosas:<br>
<br>
1.- Se puede codificar en H.264 desde opencv (si mal no recuerdo usa<br>
ffmpeg), pero me gusta más este proyecto que quizá sea interesante<br>
seguir: [2].<br><br></div><div>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...)<br></div><div><br>
2.- MJPEG sólo despilfarra ancho de banda, se comporta exactamente igual<br>
que si codificaras en MPEG con una estructura M=0, N=1. La codificación<br>
JPEG es MUY liviana en cuanto al uso de CPU y memoria comparada con la<br>
codificación MPEG con un M y N mayores de 1, pero a cambio pierdes la<br>
eficiencia de ancho de banda de la codificación basada en predicciones,<br>
estimaciones y diferencias.<br><br></div><div>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.<br>
</div><div>
<br>
Un saludo.<div class="gmail_extra"><br><br><div class="gmail_quote">El 12 de julio de 2013 13:59, Oscar Garcia <span dir="ltr"><<a href="mailto:oscar.robotica@linaresdigital.com" target="_blank">oscar.robotica@linaresdigital.com</a>></span> escribió:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">El 12/07/2013 13:23, Daniel Castellano escribió:<br>
<div class="im">> De los problemas que comenta Oscar, H.264 puede ser con bitrate<br>
> variable o continuo, así que no hay problema en ese aspecto (se<br>
> declara como continuo y listo); el problema con el que yo me topé para<br>
> streaming en directo es que no sabemos cuanto durará la retransmisión,<br>
> y es un parámetro que necesita el navegador<br>
<br>
</div>Dos cosas:<br>
1.- El problema no radica en bitrate variable o constante, radica en que<br>
el codec no saca información al flujo de datos hasta que no pasa una<br>
serie de fotogramas llamados "grupo de imágenes" [1]. En una estructura<br>
M=x, N=16 (por ejemplo, N puede ampliarse o reducirse manualmente e<br>
incluso puede ponerse dinámico) hasta que no pasan (a 25 imágenes por<br>
segundo) 16/25 s = 640 ms de vídeo no se da salida a los fotogramas<br>
procesados. A eso hay que agregar otras latencias (de la pila TCP de<br>
salida, RTT/2 de red, pila TCP de recepción, tiempo de decodificación, etc).<br>
<br>
2.- ¿Qué reproductor usáis para que os pida la duración del evento?<br>
Nunca hemos tenido ese problema en nuestro caso.<br>
<div class="im"><br>
<br>
> La solución ideal, a mi parecer, sería codificar en H.264 y si no,<br>
> pues ya depende de si puedes utilizar plugins o no; si no puedes, MJPG<br>
> funciona bien, dentro del "despilfarro" de recursos que supone...<br>
<br>
<br>
</div>De nuevo son dos cosas:<br>
<br>
1.- Se puede codificar en H.264 desde opencv (si mal no recuerdo usa<br>
ffmpeg), pero me gusta más este proyecto que quizá sea interesante<br>
seguir: [2].<br>
2.- MJPEG sólo despilfarra ancho de banda, se comporta exactamente igual<br>
que si codificaras en MPEG con una estructura M=0, N=1. La codificación<br>
JPEG es MUY liviana en cuanto al uso de CPU y memoria comparada con la<br>
codificación MPEG con un M y N mayores de 1, pero a cambio pierdes la<br>
eficiencia de ancho de banda de la codificación basada en predicciones,<br>
estimaciones y diferencias.<br>
<br>
Un saludo.<br>
<br>
<br>
[1] <a href="http://en.wikipedia.org/wiki/Group_of_pictures" target="_blank">http://en.wikipedia.org/wiki/Group_of_pictures</a><br>
[2] <a href="https://code.launchpad.net/~alex-stevens/+junk/spyPanda" target="_blank">https://code.launchpad.net/~alex-stevens/+junk/spyPanda</a><br>
<<a href="https://code.launchpad.net/%7Ealex-stevens/+junk/spyPanda" target="_blank">https://code.launchpad.net/%7Ealex-stevens/+junk/spyPanda</a>><br>
<div class=""><div class="h5">_______________________________________________<br>
Jde-developers mailing list<br>
<a href="mailto:Jde-developers@gsyc.es">Jde-developers@gsyc.es</a><br>
<a href="http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers" target="_blank">http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers</a><br>
</div></div></blockquote></div><br></div></div></div></div>