[Jderobot-dev] RTSP y MJPEG sin delay en Android

[Oscar Garcia]

El 28/03/13 14:57, Roberto Calvo escribi�:
> El problema es que si programas en nativo en Android utiliando el 
> componente VideoView que permite reproducir streaming RTSP, siempre 
> siempre siempre tiene un delay de 10seg, independientemente de los 
> paquetes, red y conexi�n. Est� ya m�s que documentado este bug 
> (feature para otros) en Android, pero de momento sigue as�. Est� claro 
> la ventaja de UDP contra TCP en este tipo de aplicaciones, pero el 
> delay de 10seg en Android utilizando VideoView est� hardcodeado y es 
> una faena.


Tienes toda la raz�n, no todas las aplicaciones permiten modificar el 
tama�o del "prebuffer", incluso algunas lo permiten pero a�n as� luego 
tienen un b�ffer interno previo a la reproducci�n que no se puede salvar 
(y muchas veces es inherente al algoritmo de decodificaci�n). Como dije 
anteriormente, pr�cticamente todo es problema del cliente, muy pocas 
veces suele ser problema del servidor, aunque hay implementaciones de 
servidor que no dan salida de datos hasta que no se ha codificado una 
secuencia completa (fotograma completo, o fotograma "I", y estimaciones 
temporales, o fotogramas "B" y "P"), sobre todo por el problema de 
reordenaci�n que conlleva los fotogramas "B". Una implementaci�n MJPEG 
es como si todos los fotogramas fueran fotogramas "I".



> La implementaci�n que has hecho de MJPEG en android es est�ndar? Es 
> decir, da igual si lo enganchamos a un cameraserver o a una webcam que 
> exporte video usando MJPEG �funciona?


Como has podido ver en el v�deo, el m�vil Android hace de "servidor" y 
no de cliente. Es simplemente un servidor HTTP basado en NIO que permite 
enviar mediante streaming los fotogramas de la preview de la c�mara 
Android. El cliente puede ser cualquier navegador web que soporte 
streaming MJPEG (como chrome, firefox, safari, etc) o un cliente 
espec�fico como VLC, Quicktime, etc.

Es decir, no se puede enganchar a un cameraserver o a una webcam que 
exporte v�deo usando MJPEG porque precisamente la funci�n de mi 
aplicaci�n es esa, hacer de servidor y exportar el v�deo.



> Ser�a ideal que cameraserver exportara im�genes o v�deo de una manera 
> est�ndar para poder utilizar los clientes que quisieramos. Hay veces 
> donde JDEROBOT no podemos integrarlo donde quisieramos (por ejemplo en 
> una webcam IP) y entonces los clientes no se puede utilizar. Yo lo vi 
> claro con mi PFC del M�ster, donde si no estaba JDEROBOT por medio, no 
> pod�a visualizar ning�na webcam.


Realmente lo hace as�, lo hace con una interfaz bien definida. Bueno, 
pero por dentro permite usar una variedad de codificaci�n de fotogramas 
(RGB, YUV, combinaci�n de los anteriores con diferentes anchos de bit 
por pixel, etc), pero yo no lo ver�a como algo "no est�ndar", si no un 
abanico diferente de posibilidades de codificar cada fotograma.

Jderobot puede obtener im�genes desde una c�mara IP, s�lo necesita un 
cliente HTTP intermedio que realice el trabajo de la descarga de 
fotogramas usando transporte HTTP, podr�a llamarse "cameraserverhttp" 
por ejemplo, y convertirlo a un formato de fotograma compatible. 
Actuar�a como representante (proxy) de la c�mara IP real y se podr�a 
ejecutar en la misma m�quina que tuviera cameraview o en una m�quina 
diferente.

Habr�a dos formas de implementarlo, que tras una petici�n realice una 
conexi�n HTTP al servidor y se descargue �nicamente un fotograma, o que 
mantenga esa conexi�n obteniendo fotogramas continuamente y atienda las 
peticiones conforme les vayan llegando con el siguiente fotograma del 
streaming (mejorar�a la latencia al eliminar los tiempos de 
establecimiento de conexi�n, etc).

Un tercer escal�n a salvar es que la interfaz camera no soporta 
fotogramas en JPEG, habr�a que convertirlos a RGB u otro formato 
similar. Yo tuve ese problema en cameraserver para Android, en el que 
termin� por implementar en JDErobot la lectura de fotogramas codificados 
en NV21 para evitar hacer esa transformaci�n en un m�vil que suele tener 
menos capacidad de c�mputo que un ordenador port�til o de sobremesa 
(aunque �ltimamente las cosas se van equiparando, pero en m�viles con un 
precio que no est� al alcance de cualquiera).

Un saludo y espero que hay�is disfrutado de la semana santa :)