http://www.cuti.org.uy/
Algo interesante es que la idea es que en un punto se apaguen las emisiones analógicas y sean todas digitales. Por lo que las aplicaciones interactivas que se hagan para la TV digital van a poder llegar a todos los usuarios que miran TV y no solo a los que usan Internet, que es en lo que piensa uno al hacer aplicaciones para la población en general.
Uruguay eligió el estándar DVB
http://es.wikipedia.org/wiki/
http://tic.item.org.uy/?q=
En DVB para escribir aplicaciones interactivas para la TV se usa MHP:
http://es.wikipedia.org/wiki/
Y para programar se usa Java:
http://java.sun.com/products/
http://mhp.det.uvigo.es/mhp/
Estas aplicaciones están al nivel de JME, corren en los decodificadores, dispositivos con pocos recursos de hardware y además lo que puede o no hacer la aplicación, depende de lo que tenga disponible el decodificador.
Actualización:
Parece que las aplicaciones se ejecutan usando una JVM con Connected Device Configuration
5 comentarios:
Y como hacen los dispositivos en cuestion para ejecutar codigo java (interpetado o ejecucion en hardware)...
Me preocupa que son dispositivos de tiempo real y que java (JME) no este a la altura de las necesidades si hablamos de tiempo real estricto y java interpretado (quien asegura la calidad de servicio en esa idea).
Por otro lado, ya existen procesadores que ejecutan bytecodes de java (sera esta la eleccion de los fabricantes de hw para tv digital?).
Las aplicaciones usan el middleware MHP. La idea de poner esto en el medio es que se pueda escribir el software independientemente del hardware que hay por debajo.
Supongo que si algún fabricante quisiera implementar las APIs DVB-J por hardware podría... Lo que si cuando comprás un set top box lo comprás soportando MHP.
Igual no veo por qué el tiempo sería un problema, ni por qué Java no estaría a la altura, ni por qué importaría si es interpretado o si se ejecuta directamente el bytecode. No es como si fuera un marcapasos, que si no se controlan exactamente los tiempos se muere una persona.
En todo caso las aplicaciones para celulares usan una máquina virtual y funcionan igual.
Estoy de acuerdo contigo. No es un marca pasos.
De todas maneras... imaginate que el control remoto justo esta atorado con otras aplicaciones y vos apretas para apagar la tele, no estaria muy bueno
que demorara unos segundos en
apagar efectivamente.
Ademas, va a levantar una jvm por cada aplicacion que corre? Eso esta de menos porque entonces precisas terrible hw y por tanto va a salir bastante carito (los celulares que soportan multiples aplicaciones java corriendo en paralelo no son nada baratos (al menos para mi).
Yo no digo que la solución no sea Java (de hecho esta en mi lista de favoritos). Solo me preguntaba como va a funcionar en los sistemas finales.
Gracias por la pronta respuesta, evacuaste gran cantidad de dudas.
No se, el tema de la JVM nunca lo vi como algo tan grave.
Definitivamente no está bueno que una aplicación te coma todos los recursos y te tranque todo.
Pero en ese caso le echaría la culpa a la aplicación y no al hecho de que haya una JVM.
En todo caso el que se podría quejar es el programador, porque la JVM consume recursos o implica tiempos que él no puede gastar en su propia aplicación. Pero el programador prefiere eso y tener una API decente para programar, que lo otro y tener que programar en assembler. Y tener que hacer n versiones para los n aparatitos que hay en el mercado.
Un programador medianamente normal, siempre hay fanáticos de la eficiencia.
Ah, en cuanto a precio, la idea es que todos tengan acceso a los mismos, por programas de promociones, beneficios especiales, subsidios o lo que pinte. De manera que para al año en el que se corten las emisiones digitales todos tengan los aparatos y las instalaciones adecuadas. Y que siga habiendo canales abiertos y gratuitos.
Publicar un comentario