Daniel muchas gracias por desasnarme. La verdad que no conocia nada de lo que hablaste. Vere de profundizar un poco en esos conocimientos para intentar comprender mejor este mundo de la TDT. Saludos. On Thu, Apr 12, 2012 at 11:25 AM, Daniel Soria <[email protected]> wrote:
Santiago,
No es un canal de datos especificamente. Las especificaciones las podes hallar en todo material que encuentres en la web sobre el Mpeg 2. Basicamente son dos formas de paquetizar la informacion que de por si necesita el mpeg 2 para resolverse en cada decoder. Una se llama Horizontal Ancilliary Data (HANC) que basicamente resuelve y porta informacion del color y del transport stream con el espacio rservado para el audio. La informacion que tiene que ver con las aplicaciones ITV o tambien por ejemplo con el closed captioning viaja en lo que se llama el Vertical Ancilliary Data (VANC) . El Carrouseling se encarga de encodear en esos espacios que se miden en word alfanumericos...manteniendose en el tiempo y el espacio de la media tanto como este indicado en la aplicacion. Lo ideal ( cuando contemos con el canal de retorno) es no enviar en el paquete mas que links hacia las imagenes, los sonidos, los Gifanimation, paginas web..etc...Lo que en ginga creo se llama portales y en el ATVEF se llama triggers. La idea del VANC es un viejo recurso de ingenieria que se aplico siempre en el intervalo vertical de blanking en la emision de señales de tv analogicas. Para la linea 21 por ejemplo, en el ATSC, se reservaba el closed captioning, y se contaba con 11 lineas para se usaba entre otras cosas para la comunicacion ( onda email) entre cabeceras de ingenieria..y plaff para ITV cuando el bienamado Tim Berners Lee escupio el http. Antes los ingleses, por ejemplo usaban esas lineas para ponerte si querias la guia telefonica via la señal de tv, asi como los franchutes habian metido algo asi en la linea telefonica. Los rusos usaron los encoders Norpak para sus trabajitos policiacos de envio de informacion y documentos en todo el territorio de la ex USSR, que era grande y ajeno. ABC, por ejemplo usaba ese canal de datos para enviar cortos publicitarios en formatos qt de alta a la repetidoras que debian reproducirlos en sus emisiones locales. En realidad si lo pensas bien podias usar todas la lineas de emision ( como de hecho se usaban en los momentos del dia en que no se emitia contenido y vos solo veias el ruido blanco) para lograr un ancho de banda infinitamente superior a cualquier downstream que te quieren vender los fibertel de turnos. Norpak ademas te vendia unas tarjetas para la PC que si vos estabas en medio de La Pampa y colgabas una antenita de recepcion de TV zappp! tenias una internet One Way que era excelente canal de servicios de educacion a distancia. La verdad eran barbaras! Todavia se consiguen cositas asi pero solo para la analogic tv... ( el IPTV ya es como una bendicion que barre con todos estos metodos obsoletos incluidos los que nos develan). En relacion a los puntos finales de tu cartita, dear Santiago.... es lo que vengo reclamando moi aussi..Lo que se llama un manual de estilo. Tengo varios de ese tipo sobre MicrosoftTV, Liberate, Mediahighway, OpenTV...pero son viejos (as I´m) Asi que muchachos ¿cuando nos ponemos a trabajar con un manual de estilo para el Middleware Ginga? Fer: Es una excelente forma de trabajar la que vos propones. Tal cual...siempre llo mejor de movida y usar una spica para tester.. Congratulation Mister NeOrwell...
Gracias...y disculpen el largo suspiro de un viejo... :-) D:S:
1. Re: Resolucion de las apps (Santiago Lombardi) From: Santiago Lombardi <[email protected]> Date: Wed, 11 Apr 2012 10:24:51 -0300 Subject: Re: [Ginga-argentina] Resolucion de las apps Perdon si pregunto cosas sin sentido pero la parte del carrouseling y la transmisión de las apps no es mi fuerte.
Hasta donde yo entiendo las apps van por el canal de datos de un paquete due lleva: video, audio, datos. Este canal se comprime con los mismos parametros que el canal de video? eso creo entender de lo que vos me contas Daniel. No me cierra como se puede comprimir con algoritmos de compresion de imagenes un texto ascii como puede ser un archivo ncl. En ese sentido imaginaria que todo lo que viaje por el canal de datos deberia ser tratado de manera diferente a la imagen.
Alguien tiene este conocimiento o sabe por donde podemos buscar esta info? Seria interesante tener pautas claras como:
- Es recomndable trabajar con imagenes jpg al 85% en tamaños 720 x 405 px por ejemplo. - Las imagenes png trabajarlas de determinada manera.
espero no haber escrito pavadas. De ser asi por favor haganmelo saber.
Saludos.
Santiago Lombardi
from: Fernando Cassia <[email protected]>
Igual que en el disen~o web, vos tenes que partir del "minimo comun denominador". O sea, asumi que quien lo vea puede tener un CRT de 14" con un STB coradir. Y no al reves (no asumir que el usuario tiene un 42' en modo 1080i.
O sea, primero que se vea bien en SD (720x400)
De ahi para arriba, podes ver si hay apis en ginga que te permitan determinar el modo de video en que esta operando el STB.
Una de las cosas que veo, igual que en las publicidades en los programas de TV con texto, es que la gente no tiene en cuenta el tema muy importante de los taman~os de los fonts. Se tiene que poder ver bien en un CRT de 14". Quien tenga un TV mas grande, lo vera mas grande. Pero siempre tener en cuenta el minimo comun denominador.
__________________________________________Lista de correo [email protected] cambiar suscripción: https://lists.ourproject.org/cgi-bin/mailman/listinfo/ginga-argentina Sitio web: http://comunidad.ginga.org.ar Wiki: http://wiki.ginga.org.ar