[Ginga-argentina] Sobre los datos en la señal Mpeg

Thu Apr 12 16:26:03 CEST 2012

El 12 de abril de 2012 11:25, Daniel Soria <dansoria at gmail.com> escribió:

> 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 <santiago.lombardi at gmail.com>
>> 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 <fcassia at gmail.com>
>>
>
>
>> 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.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ourproject.org/pipermail/ginga-argentina/attachments/20120412/26d4d3bd/attachment.htm 