Hola Gente !!!

Bueno, estaba yo pensando el otro dia en todo el proceso de creacion de un VideoCD, asi en general ...

La cosa es mas o menos asi ... : 1º) Se ripea o se separa Video de audio, en definitiva se prepara para ser absorvido por AviSynth o el frameserver que cada cual use. 2º) La peli pasa por el frameserver, en mi caso AviSynth, y se transforma, o sea que cuece hasta que queda en su punto, se realiza el recorte, la suavizacion de la imagen, filtrado de bloques, eliminacion de puntos ... 3º) Cada frame "transformado" se lleva al codificador, en mi caso TMPGEnc, el cual transforma los frames que le van llegando en una secuncia de video codificada con el algoritmo MPG.

Hasta ahi creo que voy bien ...

Visto esto, es cristalino que el frameserver es el que hace todo el trabajo, bueno, todo el trabajo "pesado", y el codificador solo se encarga de concatenar frames (cosa que tambien puede hacer mejor o peor, pero vamos que su funcion fundamental es concatenar). Visto lo visto, deduzco que donde nos tenemos que centrar para conseguir mayor calidad y menos espacio es ciertamente en el script, no digo que el encoder no sea importante, pero mi intuicion me dice que la base fundamental es el AviSynth.

Veamos dentro de AviSynth ... ¿Cuales serian los factores criticos de calidad?, me refiero, ¿Donde esta el cuello de botella? ¿Que paso es donde realmente se pierde calidad con respecto al original? . Para mi, parece evidente que el redimensionado de la imagen es ese punto, el GripCrop, el Bicubic ... vamos ese momento, donde la imagen pasa de ser 724x605 (por ejemplo) a ser 352x576. Creo que ese es el momento clave, donde se produce la verdadera perdida de calidad, perdida que se intenta subsanar con los filtros que despues se usan.

Pero digo yo ... hasta ahora conocemos 2 metodos "basicos" de redimensionado : "Bicubic" y "Lanczos", a partir de ahora hablo como si de un "pardillo total" se tratara (ya que no estoy muy metido en el tema de algoritmos de compresion de video y esas cosas) ... pero, ¿No existe ningun otro algoritmo de redimensionado? Lo digo porque en los programas de "retoque fotografico" que existen en el mercado hay una infinidad de metodos de redimensionar una imagen, y se podria intuir que existen mas metodos ... y si existiesen ... ¿No seria interesante probar con algun otro metodo nuevo de redimensionado de imagen?

Ya digo que en este aspecto la verdad que no estoy al dia, recuerdo que tenia una asignatura en la universidad que se llamaba "MULTIMEDIA" y otra que era "DISEÑO 2D", donde veiamos algoritmos JPG, GIF y esas cosas, pero vamos que no entramos en detalles de video, solo de imagenes estaticas. Pero dado que el JPG es el homonimo de MPG para imagenes estaticas (es una compresion CON PERDIDAS), pense que existirian otros metodos. Tal vez alguien que este mas al dia que yo puede orientar este post (seguramente Kwag o Pulsar, que parecen ser los mas tecnicos).

Para mí, el que hace el trabajo pesado es el codificador. Prueba a investigar las interioridades de una secuencia de MPEG1 y me cuentas: VOBUS, AUDIO, VIDEO, P-PICTURES, SUBTITLES, todo juntito en cuatro décimas de segundo de media. ¿no es complicadillo?. Si no ¿por qué podemos ver una peli "frameserveada" casi en tiempo real mientras que para hacer una compresión necesitamos horas y horas de proceso?

Por otro lado, pienso que filtrar una película es desvirtuar su contenido -¡aunque sea para mejorar la compresión!-. Excepción hecha del retoque de valores luma y croma. De hecho, ya la estamos desvirtuando al comprimirla, pues sabemos que MPEG1 utiliza un algoritmo de compresión CON PÉRDIDAS, al cuantificar los valores de los bloques DCT. Que éstas pérdidas sean visibles o no es otra cuestion, y que las deficiencias que introducimos en la imagen al filtrararla se aprecien o no también es otra cuestión largamente discutida. Todavía no he encontrado a nadie que paso a paso y con ejemplos claros, fieles, didácticos y reproducibles en cualquier máquina para testear su bondad, me explique claramente el porqué el m.a. script. ¿Donde están los comentarios (léase, las #) en el source del MA Script? Posteos con notas tajantes sí, pero explicaciones comprensivas y completas, ninguna.

(Nota: Hablando de pérdidas en la compresión, ¿no os habéis fijado que TMPGEnc produce cierta palidez en las imágenes comprimidas? ¿No será que al desaturar los colores evita la aparición de los temidos artifacts? Yo siempre tengo que ajustar los valores de brillo y contraste en los settings de TMP si quiero fidelidad con el original, cosa que no pasa con MCE)

Ahora bien, partiendo de lo que tú dices, que la mayor parte de los problemas residen en un resize, tengo dos comentarios que hacer:

1.- Estoy enfrascado en comprobar que, efectivamente, los resizes se están haciendo actualmente respetan el formato de la imagen original. Los ejemplos y métodos indicados en los foros me dejan frío. Soy un Sto.Tomás en este sentido: si no meto el dedo en la llaga, si no compruebo "a mano" la exactitud de un resize de los llamados correctos, no me lo creo. Otros sí, con algún programa "automagicado" (Mal de muchos, consuelo de tontos). Recuerdo que nuestro amigo Nómada se marchó porque nadie le explicó con espíritu ilustrativo el porqué de los tamaños de resize. Y Ahhh, se me olvidaba: el último post que leí sobre el resize nos remitía a una página en inglés donde se recortaba - o sea, se censuraba- los laterales de la película sin más peros. Nos sobra, pues fuera, lo eliminamos alegremente. Que el director quiere trabajar en 2,40:1 vale, como si se coge un resfriado. Yo la reduzco a mi manera y listo. Señores: Seriedad ante todo. Y si no, pues hale, cortemos la escena del desierto del paciente inglés y dejemos que hablen las cálidas arenas en vez de ver las bocas de los personajes.

2.- Un resize de la resolución estándar DVD (720x576) a un tamaño inferior de sample no debe de ser problemático. A dos metros de distancia media de un aparato de TV, los problemas de visionado deberían afectar solamente a los daltónicos. Lo problemático sería ampliar la muestra, pues ahí sí que estamos introduciendo información falsa para conseguir la resolución objetivo. De aquí se deduce que yo en particular no trabaje por lo general con ficheros divx: primero porque son piratas, y segundo porque son un desastre de resize.

Siguiendo con los resizes, existe en la red una pagina en inglés, donde se analizan al detalle diversos métodos de redimensionado, mostrando con un zoom de pantalla, los problemas de unos y otros. Lo malo es que la copia de la página la tengo revuelta entre más de 600 páginas de apuntes sobre vídeo digital que tengo en casa (3 bloques de A-Z llenitos hasta los topes), y creo que será más rápido que invesigues en la red a que yo busque esa página en mi librería particular y te remita el enlace. Busca "video resizing methods".

Además, hay páginas en las que se estudia una mejoría de los algoritmos IDCT, y ciertamente, se consigue; pero eso supondría tener que cambiar los chips (literalmente, los modulitos negros con patillas de metal) de los DVD.

Si quieres aplicar filtros estáticos en imágenes 2-D, prueba "Net Image", gratuíto para uso personal, y especialista en mejorar la apariencia REAL de los JPG. Se puede mirar con lupa para comprobar los resultados. Sería estupendo tener un filtrador de MPEG a posteriori, es decir, con la película ya comprimida.

y...

¡¡¡¡POR DIOS!!!!
NO ME LLAMES TÉCNICO. SOY TAN AFICIONADO COMO TÚ MISMO TE PUEDAS CONSIDERAR. Estoy en esto solo hace unos cuatro meses y mi tiempo es escaso -como el de todos nosotros-. No entraré en particularidades (cada cual con su cruz) pero no puedo echarle más de dos horas semanales -cuando las tengo seguidas- a estudiar los KVCD.

__________________
Saludos, Pulsar.

Hola Gente !!! Hola Pulsar !!!

Para comenzar ... a mi, personalmente, me pareces bastante tecnico (en el buen sentido de la palabra, que por otra parte yo solo le veo buen sentido).

Luego, a la cuestion ... creo que no nos hemos entendido ... o tal vez yo no te haya entendido a ti.

En lo que comentamos ambos del codificador y el frameserver ... no sabria que decirte, yo pienso que el trabajo del codificador es mecanico, recibe una imagen, o frame, usa el algoritmo MPG, y la une con el resto. Que lo haga mejor o peor es otra historia. Te preguntaras ... ¿porque opino asi? pues porque si codificas una peli directamente con TMPGEnc te va a salir una patata, aunque la codifiques 40 veces, porque el trabajo del codificador es mecanico, no hace nada por "mejorar" el aspecto de la imagen, solo la comprime mas o menos (tal vez en eso no me haya explicado bien, buscamos CALIDAD DE IMAGEN y MINIMO ESPACIO, a eso me refiero). Y pensaras ... pero el encoder comprime la peli, a veces mas o a veces menos ... pero yo pienso el algoritmo MPG ha de ser un estandar, ha de estar "hecho", poco se puede mejorar (lo comparo con su homonimo JPG, poco puedes hacer con el JPG, y si piensas lo contrario ... te equivocas, por experiencia lo digo, eso si, lo que puedes hacer es UNA VEZ JOTAPEGEADO, limpiarlo, pero vamos que la FORMA de JOTAPEGEAR es BASICAMENTE la misma, siempre y en todo programa).

Bien, dicho esto ... no se por donde me voy, a veces divago, lo siento :P

Bueno, por lo primero, difiero en eso, pienso que el verdadero trabajo lo hace el frameserver, o si lo quieres ver de otra manera, los FILTROS que uses en el frameserver. A eso me refiero, a que la CALIDAD, impepinablemente lo va a dar lo que hagamos ANTES con cada frame, para que el encoder lo pase a MPG limpito y reluciente. Que al pasar por el encoder tendra perdidas ... pues fijo, porque lo que hacemos es LIMPIAR una imagen, para luego comprimirla y al comprimirla con PERDIDAS ... pues pierde, pero a mayor limpieza, menor perdida, de eso intuyo que es de lo que se trata.

Por eso decia lo del RESIZE, no me refiero a los puntos en pantalla, ni si esta mejor a 720 que a 352 ... me refiero a LA FORMA DE REDUCIR LA IMAGEN.

Me explicare, pogamos que ponemos la peli en el frameserver ... la peli se carga, y se llega al primer frame. Iniciamos pues la secuencia de nuestro script para el primer frame. Lo primero que hacemos es GRIPCROP, o sea RESIZE (o recorte o como adecuacion del tamaño, o reduccion, ... vamos creo que se me entiende). En el momento en que reducimos una imagen (e impepinablemente la tendremos que reducir) perdemos calidad. Intuyo que es ahi donde aparecen los macrobloques, artefactos, "movidas chungas" ... en fin, los fallos con respecto a la imagen original. Una vez reducida la imagen, la reduccion la pasamos por una serie de filtros, con la intencion de dejarla lo mas parecida al original posible, lo mas limpita posible, lo mas nitida, ... con el proposito que cuando llegue al encoder la pase a MPG (perdiendo, por supuesto, nuevamente calidad) pero al estar tan tan tan limpita la perdida sea muy poca.

Intuyo que ese es el proceso basico.

Entonces yo pienso (y esto, como dije antes es elucubraciones mias de "pardillo" por asi decirlo) ... la perdida sustancia de calidad con respecto al original se produce al hacer GRIPCROP, una funcion que esta definida en el GRIPFIT.DLL, una funcion (o procedimiento o subrutina o como querais llamarlo) que usa el algoritmo de reduccion BICUBICO (por ejemplo, o el LANCZOS) y vuelvo a pensar ... si es ahi donde se produce la mayor perdida de calidad ... ¿No existira otro algoritmo de RESIZE (o reduccion, o ... ) en el que se pierda menos calidad?, uno que no sea BICUBIC, que se llame TARATACHAN (por llamarlo de alguna manera) y que haga mejor la reduccion y se pierda menos calidad.

O tal vez exista un algoritmo, basado en el BICUBICO, que este mejorado y trate mejor la imagen, la reduzca mejor y pierda menos calidad. A eso es a lo que me refiero.

Pienso que si existiera (o existiese), seria un buen punto de partida para hacer pruebas.

PD: Realmente sigo pensando que el trabajo para dar calidad a una peli no lo hace el encoder, sino nuestro script por el frameserver. Otra cosa seria que la peli se comprima mas o menos ... eso ya es cosa del encoder que es el que comprime. Aunque tal vez haya algunos filtros que faciliten que esa compresion sea menor, pero pienso que en ese aspecto el encoder es fundamental.

Bueno, vamos a ver.

El algoritmo MPEG es mecánico. Cierto. Pero tiene un montón de parámetros que podemos tocar para ajustar la compresión, que es donde se producen los artefactos. El meollo de la cuestión, la base de kvcd, como dice K, en los anuncios preliminares de la página, es la Notch Matrix (una matriz de parámetros que se usa para cuantizar los DCT) y la estructura de los GOP. Luego vienen los filtros.

El resize es posible que produzca deficiencias, pero no ocasiona macrobloques. Éstos se producen por un error de interpretación de los valores luma, croma y de predicción de movimiento en cada bloque de 8x8 con el que trabaja el algoritmo MPEG. Más bien con la cuantificación de valores DCT.
Verás: La función Transformada Discreta del Coseno (derivada de la transformada de Fourier), es una función sin pérdidas por definición. Podemos recuperar los valores íntegramente de una tabla DCT 8x8 que no ha sido cuantificada ni se le han reducido los valores próximos al cero. Ahora bien, si dividimos cada valor por 8, redondeamos y eliminamos valores proximos a cero, es predecible que la información que posteriormente reconstruyamos no será idéntica al original. Esto es lo mismo que decir que aparecerán fallos de visión. Estas operaciones son internas al MPEG y no podemos modificarlas, sólo podemos modificar los parámetros con los que trabajan (notch matrix, GOP, etc.)


Como ves, nada que ver con el resize. Todos los artifacts que nos aparecen son producidos por el MPEG. El resto son deficiencias de la propia peli original o deficiencias aportadas por los filtros. Cógete un AVS procedente del original de un DVD. ¿Aparecen bloques DCT? ¿Hay mosquitos? me temo que no. Éstos sólo aparecen tras la compresión.

Otra cosa: tmpg, además de introducir artifacts como cualquier otro compresor, hace que la peli palidezca, desaturando colores y brillo, por lo que sí es preciso ajustar estos valores antes de la compresión.

Lo que haces al utilizar los filtros es "paliar" los defectos de la compresión. Mejor dicho, intentar intuir qué defectos aparecerán al comprimir un determinado original e intentar disimularlos. Esto lo hacemos comprobando la calidad de la película viéndola antes de procesarla (habiliadad solo reservada a los expertos que han tratado cientos de secuencias de vídeo y pueden intuirlos y de los que yo no formo parte)

__________________
Saludos, Pulsar.

Hola Gente !!! Hola Pulsar !!!

Entiendo lo que me comentas de las opciones a "tocar" en el encoder, los GOPS, la matriz de compresion, ...etc ...

Pongamos que las deficiencias, como tu apuntas, aparecen en el encoder ... entonces yo me pregunto ... A igualdad de condiciones ... con dos encoders diferentes ... si se utiliza el mismo algoritmo de compresion MPG (basado el la transformada de Fourrier, como tu apuntas) ... ¿No deberian dar el mismo resultado?. Y sino lo dan ... supondria que un encoder es mejor que otro ... y que por tanto esa "funcion" compresora del encoder es mejor en uno que en otro ¿Cierto?. Lo cual nos da un buen punto de partida para observar las diferencias entre los diferentes encoders. (INCISO: En esto tal vez yo estaba equivocado, ya que pensaba que todos los encoders usan el mismo algoritmo MPG, el cual supongo que es universal y estandar, cosa que de hecho todavia sigo pensando, pero es posible que modificaciones a ese algoritmo consigan mejores o peores resultados. Pero lo que yo realmente creia es que esas modificaciones no eran la clave de "una peli de calidad", ya digo que en lo cual puedo estar equivocado).

Pensemos ahora ... si es el encoder el que proporciona calidad a una pelicula ... deberiamos buscar el encoder que diera mas calidad y adaptarlo al KVCD (seria como he dicho antes, un buen punto de partida), pero en realidad la experiencia me dice (al menos con CCE y TMPGEnc, que si paso la peli directamente por el encoder el resultado es muy similar, al menos en calidad, no asi en tiempo, pero si en calidad). De lo cual deduzco que para obtener una peli de calidad, he de crear un script, independiente del encoder (o dependiente, segun se mire), que me haga que esa peli tenga calidad.

A grandes rasgos podria deducir que las opciones que puedo "modificar" con cualquier encoder (al menos que yo conozca) son insuficientes para conseguir una peli de calidad. Tambien podria crear una nueva matriz, llamemosla por ejemplo VIALVCD, pero intuyo que (basandome en la experiencia) que no notaria grandes cambios en la calidad.

Sin embargo (y volviendome a basar en la experiencia) puedo decir que usando unos ciertos filtros u otros, si que consigo un gran cambio en la calidad final de la pelicula (independientemente del encoder, o dependientemente, ya digo que segun se mire). Lo cual me hace pensar que el verdadero factor de calidad es el script y no el encoder.

Es por eso que pretendia abrir un camino nuevo dentro de los scripts, utilizando nuevas funciones (o .DLL's, como quieras llamarlo) que consiguieran mas calidad.

Esto lo digo unicamente basandome en la experiencia visual, viendo cortes de MCE, viendo cortes de TMPGEnc y viendo cortes de CCE.

PD: Con respecto a CCE, y esto es algo curioso, un amigo me enseño la pelicula de FINAL FANTASY, y puedo decir que es algo BARBARO. Me enseño el proceso ... pero increiblemente no he podido repetirlo, no he conseguido ni por asomo la calidad de esa pelicula. Es que tendriais que hecharle un vistazo, es un 352x576, de imagenes 3D, ... pero es algo fuera de lo comun, en un solo CD de 80 ... Lo unico que no he conseguido es el script que utilizaron, por eso mis intentos con CCE son "normales", no veo gran diferencia con TMPGEnc (y estoy hablando de calidad, y de CCE en MPG-2 y TMPGEnc en MPG-1, intentando sacar el maximo partido a cada uno), por ello estoy convencido que el SCRIPT es fundamental y elemental.

Segun yo lo veo:
Mpeg-1 y Mpeg-2 son dos estandares, y como tal, lo unico que son, definiciones de propiedades. Es decir, para que un archivo se defina como mpeg, debe tener una serie de propiedades que se ajusten al estandart. Ahora bien, el modo para llegar a ellas, es lo que puede definir la calidad de un encoder.
Su capacidad para predecir frames y detectar movimientos. No olvidemos, que la compresión mpeg utiliza dos tipos de predicción de frames (hacia adelante o P-frames, y bidireccional B-frames), mas un algoritmo de detección de movimiento de objetos.
O sea, que nuestro frameserver, entrega un frame al encoder, supongamos que el primero, este lo guardará tal cual (I-frame). El encoder solicita al frameserver el frame que corresponde en orden, al que seria su p-frame. Si es una estructura IBBPBBP, solicitará el cuarto.
El encoder buscará las diferencias entre este y el primero y guardará el resultado en su posición correcta.
En este momento tenemos esto IxxP
Ahora el encoder calcularà la diferencia entre este (que ya no es el original, si no el resultado de un calculo), y de nuevo con el primero, rellenando los huecos obteniendo IBBP
y así sucesivamente hasta que termine la secuencia de GOP y vuelva a solicitar un I-frame, que es el unico que se guarda 'tal cual'

O sea, que el encoder SI tiene su importancia


SIGO:
A mi entender, creo que lo acertado, seria crear un script que se adaptara a las particularidades de cada encoder y de sus algoritmos, pero está clarisimo que ningun desarollador de encoders, va a 'enseñarte' sus algoritmos, por lo que nos tendremos que conformar con un script no dependiente del encoder, como mucho, y como ya existen, son scripts dependientes de la fuente, pues no nos importa como trate las imagenes, si no de su aspecto visual, ya que es su aspecto visual el que va a tener que manejar el encoder.

OK, ya hemos empezado la enciclo-multimedia del KVCD.

Epístola Tercera de Pulsar Informaticks a los Vialhuenses

Amigos:

El algoritmo MPEG es estándar, definido en los documentos base ISO. Privados y de pago, salvo que algún lumbreras lo publice subversivamente (existen y se pueden encontrar). Ahora bien, cada cual lo adapta e implementa a su gusto y albedrío, obteniendo resultados diferentes en las tasas de compresión, las velocidades de proceso y el tamaño de los archivos. Pero estoy repitiendo lo que dice Yazooo (qué buen grupo de música de los 80, la que más me gustaba era la canción "In my room", una delicia).

En cuanto a lo de el encoder que dé más calidad ... ¿No hay ya mucha polémica con esto? Dejémoslo estar y que cada cual utilice el que más le guste.

La matriz de cuantificación: ¿Es mejorable? ¿Hay pruebas visibles de diferentes valores?. Una vez hice como divertimento una implementación del algoritmo DCT-IDCT para jugar con ella, pero necesitamos conocimientos más técnicos para valorar este juego de titanes.

Los filtros: Sigo pensando lo mismo, están para darle la merienda masticadita al encoder, y que éste no se atragante. Masticar es destruír en trocitos pequeños. Mediterráneo (la primera peli que pasé) se ve de miedo sin filtros, pero el libro de los gustos está por terminar aún, así que ...

Lo de Final Fantasy me interesa. No Final Fantasy en sí misma, sino el proceso de compresión utilizado. ¿Podría adaptarse a TMPG o MCE?. Pasa información plis.

Yazoo: coincido totalmente, pero además de adaptar el script al encoder, habría que adaptarlo al tipo de película objeto de la compresión. Y eso sería encomiable, pero un derroche de tiempo. Yo particularmente busco calidad/precio (calidad vs engorro y tiempo de compresión)

Bueno, os dejo, me voy a ver "El último Samurai" EN EL CINE, que es donde mejor se ven las películas.

__________________
Saludos, Pulsar.

Si no me equivoco, lo que está definido, no es el algoritmo en si, si no las precondiciones y las postcondiciones, asi pues, lo que tiene que hacer un encoder, es, dadas unas precondiciones ,llegar a las postcondiciones definidas por el estandart. El medio para hacerlo, es lo que se debe desarrollar.

Lo que está claro, es que cualquier encoder comercial, va a dar unas calidades y velocidades similares o quizá en unos se prime una cosa sobre la otra. Así pues, los algoritmos que implementan los encoders, pueden ser completamente diferentes, y cada uno puede tener sus particularidades.

Seguramente, las peliculas que se ven perfectas sin ningun filtro, es sencillamente, porque no lo necesitan, aun así, aprovechando el como trabaja el encoder, se pueden desarrollar filtros que simplemente, reduzcan el tamaño del archivo, permitiendo así, aumentar la CQ o el bitrate.
Sin ir mas lejos, ¿habeis visto como trabaja el filtro DUP?.
Este filtro, busca diferencias entre frames contiguos y si estas diferencias están dentro de un limite, el filtro le pasa al encoder el mismo frame.
Muy util en peliculas anime, que contienen muchos grupos de frames que en origen eran exactamente iguales, y que si al procesarlos no lo son, es sencillamente porque se degradaron en la primera codificación.
Al obligar a nuestro frameserver a repetir frames, conseguimos que el encoder no encuentre diferencias que calcular para los frames P o B, y que el resultado sea una imagen mas estable y con menos ruido, a la par que nos da un archivo mas pequeño.(otra vez podemos subir la CQ o el bitrate)
Los filtros temporales, como este, analizan grupos de frames para determinar que información a cambiado los suficientemente poco entre frames como para despreciarla a la hora de entregarla al encoder, y a menos información a codificar, tamaño menor (ooootra vez podemos subir la CQ o el bitrate)
Los filtros espaciales, analizan porciones contiguas de un mismo frame para determinar que informacion se parece tanto como para despreciarla (Reeeeeepeeetiiiiimooooosss: o sea, a menor informacion.......)

Y ahora direis: Vale, que ya lo sabemos.
Si, pero recordadlo a la hora de entender como trata el encoder la informacion que le suministra el frameserver.


Joer, que divertimentos tienes!!!

Yazoo (con dos o, atención), si, pero tienes razon, Pulsar, el nombre me lo puse como tributo. Por cierto 'In my room' es impresionante, pero prefiero 'Midnight'. Te la recomiendo.


SALUDOS

Hola Gente !!! Hola Yazoo !!! Hola Pulsar !!!

Increible debate ... estoy disfrutando como un niño ...

Bien, en principio entiendo muy bien vuestras opiniones, asi como los comentarios sobre el estandar MPG y de acuerdo con Yazoo en las precondiciones y postcondiciones (lo tipico cuando se crea un algoritmo, aunque existes mas metodos para crear un algoritmo Yazoo, esta el pseudocodigo, el lenguaje formal ... no solo se crean algoritmos de esa forma, y por la complejidad del MPG, puedo intuir que no es un algoritmo que se base en precondiciones y postcondiciones, por muy complejas que estan puedan llegar a ser).

Bien, ahora veamos las cosas del "mundo real", las herramientas que tenemos y los resultados que obtenemos.

Hoy por hoy ... usamos TMPGEnc sin ayuda de ningun filtro ... yo no digo que el resultado sea malo, pero desde luego lo podriamos calificar de "mediocre", al menos hablando en general. Puedo hablar tambien con CCE, y pasa lo mismo. De MCE ... me abstengo, aunque por los cortes que he visto de la peli de "X-MEN 2" que hay en un post de aki ... yo los calificaria tb de mediocres (no se vosotros, pero yo sigo viendo bastantes puntitos alrededor de las caras de los personajes, eso si, he de reconocer que es muy nitida la imagen).

Personalmente me puedo volver loco tocando opciones de TMPGEnc ... pero el resultado ha sido siempre mediocre.

Ahora bien, usamos AviSynth (por ejemplo, como frameserver) y el Script Optimo. A mi entender los resultados mejoran una barbaridad, tambien es verdad que la imagen se hace un poco borrosa, pero aun asi hay un mundo de diferencia.

Por eso digo, si "hoy por hoy" el pasar una peli por el encoder resulta mediocre, pues tendremos que centrarnos en el Script.

Tal vez seria una buena idea tranformar la "estructura" del script. He pensado en el redimensionado porque me parece que es el factor donde mas calidad se puede perder.

Pero bueno, en conclusion, decidme con el corazon en la mano ... ¿Conseguis mejores resultados con o sin script? (Yo puedo decir que "con" sin duda alguna). Por eso me parece que el factor de mejora se centra ahi, en el script.

Creo tambien en el gran paso de un script lineal a un adaptativo, y vi los resultados de uno y de otro ... por eso creo que es en ese aspecto donde hay que "pensar" ya que ahi esta la clave para conseguir la calidad final.

Para terminar decir que lo que explico es todo simplemente basado en mi experiencia "visual", o sea en el resultado que veo. Es posible que mi DVD haga esto o aquello, que mi televisor no sea 100Hz, o mil cosas mas, pero a grandes rasgos me fijo en los detalles importantes, y creo que esos si que se diferencian en cualquier pantalla.

PD: Pulsar, sobre la peli de FINAL FANTASY la verdad que no puedo darte mas pistas, solo se que se hizo con CEE y uno de los filtros era el FITCD. Ahora si, te puedo decir que esa peli es mi "meta". Si consiguiera hacer todas las pelis con esa calidad ... ni pensaria en comprarme una grabadora de DVD's, te lo aseguro, es un CVD fuera de lo comun.