|
SonicDS
|
| |
| Mensajes: 93 |
| Registrado: Septiembre/2007 |
| Estado:
Off-line |
| Grupo: Administrador del foro |
| |
|
| |
|
WMP: Window Media Player.
Buenas.
El "conocido" problema del vídeo ó imagen en color verde (que además sólo ocurre/ocurría en ése color), se debe a la versión del FourCC que se empleó para hacer ése vídeo en formato XviD . Ello se debía a que la fuente de salida en formato YUV que generaba esa versión del XviD era "correcta" pero con "conversión" inválida. Nos explicamos :
El formato YUV (para ser más exactos: "YUV2") de cada frame comprimido provoca que al Macropixel (2 pixels*(Horizontalidad+Verticalidad) = 4*4 pixels. Que no, Macrobloque: 8 pixels*(Horizontalidad+Verticalidad = 16*16 pixels) se le asigne una posición determinada para cada una de las líneas del frame. Ello se consigue mediante un diagrama (compresión del Codec en bloques de 8 pixeles ó macrobloques de 16 pixeles); donde el valor de "Y" es colocado en el primer y tercer pixel, mientras que el valor de "U" (Cb) y "V" (cr) se posicionan en el segundo y cuarto respectivamente (el llamado "FourCC" ) y así sucesivamente por cada uno de los bloques ( 8*8 ) del frame. De manera (y a modo de ejemplo), que la instrucción que enviaría el codec sería de la siguiente manera:
Macropixel
-------------|
Y0 U0 Y1 V0 | Y2 U2 Y3 V2 .. .. .. ..
-------------|
Esto que que parece "complejo" en realidad no lo es , dado que ésta es la secuencia de compresión para el formato MPEG-4 en modo "YUV2".
Por desgracia, existieron numerosas Releases de XviD que añadían su FourCC correspondiente el cual era digamos, incompatible (realmente lo que se enviaban eran frames "SEMI-COMPRIMIDOS") con el soporte DirectDraw. El echo es, que en ésas versiones de XviD el código era(es) enviado ántes que los "traductores" de la imagen del propio Sistema Operativo (interviniendo el "kernel" del propio DirectDraw) provocando la comentada imagen de color verde ó incluso llegar a provocar los "errores de excepción". De ahí que con la instalación del filtro "ffDirectShow" se haya solucionado en determinadas ocasiones y en otras no .
Además, está el echo de que el propio FourCC es el encargado de decirle a nuestra Tarjeta Gráfica y mediante la traducción de los "drivers" ó "intérpretes" de la señal (DirectDraw, DirectShow, etc, ...) de vídeo cómo se ha creado ése fichero de vídeo (Codec utilizado, Resolución, etc...). Por lo tanto se supone que con la actualización de un "intérprete" (veáse, "ffDirectShow" ó con el propio "DirectDraw") entre el Codec y el propio S.O. debería de solucionarse .
Bueno amigos, espero haber aportado algo más de información a éste "problemilla" que apareció en su momento pero que por una u otra razón, ha vuelto a aparecer (desde luego en las nuevas versiones del XviD se supone que ésto está más que corregido ).
Un Saludo.
P.D.: También cabe la posibilidad (si observamos que no conseguimos la OBLIGATORIA conectividad entre los "drivers" de Vídeo del Sistema y ése vídeo en concreto), usar la utilidad "AVI FourCC Code Changer" y probar con ella sobre el "AVI" en cuestión. Aunque para ello, deberíamos de estar seguros de que tenemos el filtro "correcto" (en éste caso del XviD) del "DirectShow" del propio XviD .
Mi Solución:
Este problema sucedio en win2000. Pero en XD yo creo que tb es lo mismo, si no es asi, haganmelo saber.
Ejecuten dxdiag.
en la paleta "pantalla" deshabilitar Aceleración DirectDraw
...
Que esten super!!
#Nos vemos...
|
|
