Mostrando entradas con la etiqueta Encoding. Mostrar todas las entradas
Mostrando entradas con la etiqueta Encoding. Mostrar todas las entradas

4 de marzo de 2011

Diferencias entre un buen encode y uno muy malo!

Guess what guys, los buenos encodes son cosa de suseptibilidad, lo importante es no cagarla, porque los malos encodes sí que existen, apestan y están por todas partes!

Ahora, todos han de pensar, wtf de qué va este tema?
Simple, ahí les van unos cuantos tips para no cagarla a la hora de encodear.

1.- Nunca, pero nunca filtres de más un video, a menos que sepas lo que estás haciendo realmente (generalmente no lo sabes, wait, de hecho no lo sabes, no lo hagas!). Con un buen ivtc basta y sobra, incluso un deband o anti-alisign si realmente lo necesita, si quedan problemas como halos, un poco de aliasign o escenas rápidas con bloques, es culpa de la fuente y ya tienes excusa, si es que tu fuente fue la mejor posible, aka un dvd, bdmv o ts que se veían del orto! Por el contrario, si sobrefiltras, no tienes excusas del por qué te cargaste todos los detalles del video, sabelo. xD

2.- Nunca uses raws ya hechas, suelen venir sobrefiltras, con mal ivtc, y llenas de mierda que solo Dios sabe cómo llegó al video. Siempre trata de buscar la mejor fuente posible, un dvd, un bdmv, una ts, etc...

3.- Ten siempre en cuenta el aspect ratio, no tienes que ser exacto ni usar resoluciones anamórficas, pero por favor, no uses un aspect ratio 16:9 cuando tu fuente era 4:3, y viceversa, eso es de huge faggots, y suele pasar bastante. Ten siempre en cuenta cuánto crop y resize haces, eso modifica el aspect ratio dependiendo de la cantidad.

4.- Aprende a hacer un ivtc! Hay muchas guías en internet y la gente no le da la menor importancia, cuando realmente es lo más importante de un encode imho y muchos buenos encoders coincidirán conmigo.

5.- Si no sabes qué mierda hace cada parámetro de x264, no te pongas a jugar con ellos al azar, documéntate o bien usa --preset veryslow y quítate de pendejadas. Cualquier encode con crf abajo de 18 con preset veryslow se va a ver decente, tal vez no sea la puta hostia ante los hojos de los freaks del encodeo, pero será un encode decente y no tendrá nada de criticable (a menos que la cagues en los pasos anteriores).

6.- No hagas upscales! Holy shit, enserio, no ganas nada haciéndolo, solo aumentas el bitrate necesario y agrandas las porquerías que traía la fuente si es que no sobrefiltras, en cual caso ya la estarías cagando en el punto 1. -3-

En fin, espero les sirva de algo a los nuevos encoders, tomen en cuenta que no por gastar 8hrs encodeando un video sacrificando su pc los hace buenos, simplemente los hace el doble de ignorantes.
Sup. :3c

Pasos a seguir para encodear un BDMV for dummies. :3c

Ok, ahora recuerdo que me habían pedido una guía de cómo encodear un video desde el primer paso hasta el último hace algún tiempo, pero ya saben, soy demasiado lazy, y hasta ahorita que no tenía absolutamente nada qué hacer, es que me pondré a con esta guía. >3<

Bueno, empezaremos eligiendo el ejemplo que usaré, digamos que quiero encodear un BDMV, cómo le hago, wtf? I don't even... nani kore!
Asumiré que de entrada ya tienen su equipo en condiciones para encodear, es decir, ya tienen Avisynth instalado, .NET Frameworks, una interfaz para editar scripts de Avisynth como AvsP, y sus codecs en condiciones, para los codecs de video, recomiendo que usen CCCP, que tiene todo lo que podrán llegar a necesitar, está bien optimizado y no te instala basura que nunca necesitarás, como el K-Lite. Si tu cpu tiene dos o más cores, marquen MT como decoder h264 preferido.

Avisynth
.NET Frameworks
AvsP
CCCP

21 de mayo de 2010

Uso de TIVTC (Actualizado).

Bueno, notarán que borré dos entradas que tenía sobre tivtc y decomb package, si no lo notaron pues qué mejor, las borré porque estaban muy desactualizadas (mal). Así que va de nuevo, una breve explicación del uso de tivtc.

Primero, qué carajo es un ivtc? Simple, un inverse telecine, revierte el proceso de telecine que hacen los estudios a los dvds, leed mi entrada de animeivtc (que después actualizaré mejor) para mayor entendimiento.

Las dos funciones que váis a usar para hacer un ivtc son "TFM" y "TDecimate". Explicado de una manera simple, tfm se encarga del alineado de campos de los frames y tdecimate se encarga de eliminar los dups (frames repetidos) cambiando una fuente de 30fsp a 24fps normalmente para dvds.

El uso de tfm primero: TFM(pp=7)
El post-processing es el encargado de desentrelazar frames con combing residual después del alineado de campos. Hay diferentes tipos de pp, 0 y 1 no hacen post procesado, 2, 3 y 5 si no mal recuerdo aplican un poco de blur al combing, o eso he notado yo, 4, 6 y 7 hacen un desentrelazado del combing, siendo 7 el más preciso en mi opinión.

tfm(clip2=tdeint(mode=2,type=3))
Un parámetro importante es "clip2", que le indica a tfm la función que ha de usar para ayudarse con el post-processing, mejorando la calidad del pp, ahí puedes insertar cualquier deinterlacer que gustes, yo recomiendo tdeint o nnedi2 en algunos casos donde tdeint llega a dejar aliasign que no había originalmente, aunque nnedi2 come más detalle. Sharp=false para que no aplique ningún sharp el pp y sea más rápido, aconsejado por el trolazo de koichi, el cual solo es aplicable cuando usas type=2. ò,ó

tfm(cthresh=x)
Otro parámetro importante que debéis conocer, ctrhesh controla a qué nivel de rastros de combing se debe usar el pp, siendo 9 el default. Es decir, si después de haber aplicado tfm con pp activado a una fuente y sigues viendo rastros de combing, puedes probar a bajar los valores de ctrhesh hasta que no veas combing en ningún frame, teniendo cuidado de hacerlo bien, por lo general 9 es un valor adecuado en casi todas las fuentes, pero hay casos donde se tiene que bajar o subir por si el pp está detectando frames progresivos como combed frames. Os aviso, nunca lo bajen a 0, aplicará pp a todos los frames, incluso los progresivos, los echará a perder, si tuvieran que bajar un valor demasiado, 1 es lo máximo que recomiendo lo bajen.

tdecimate()
Este ya es más simple y a la vez importante para no fregarse la fluidez del video, si cada 5 frames hay un dup (frame repetido), se deja con sus valores normales, si tu fuente es anime, que por lo general tiene varios frames repetidos en una misma secuencia, se le agrega "mode=1" y ya está, pasará tu fuente de 30fps, como queda después del alineado de campos, a 24fps. Si tienes una fuente híbrida, secciones sin dups (30fps) y secciones con dups (24fps), entonces tendrás que hacer un encode a dos pasadas donde la situación ya es más alargada de explicar. En la documentación de tivtc vienen ejemplos de cómo hacer un encode vfr (variable frame rate), les aconsejo que se lean la documentación.

Eso sería prácticamente todo, arriba expliqué los parámetros más eficientes de esas dos funciones, siendo que al final, su ivtc deberá quedar algo así, siendo el uso de cthresh alternativo dependiendo de la fuente:
No anime: tfm(pp=7,clip2=tdeint(mode=2,type=3)).tdecimate()
Anime: tfm(pp=7,clip2=tdeint(mode=2,type=3)).tdecimate(mode=1)
 
Espero que les haya servido la explicación, conforme vayan agarrando práctica aprenderán a detectar fallos y llegarán a configurar mejor su tivtc, hay muchos más parámetros que también son importantes pero requieren de práctica, así que lo mejor es que lean la documentación. Como siempre, si tienen preguntas, simplemente hacedlas.

Saludos. (づ。◕‿‿◕。)づ

23 de diciembre de 2009

Ordered Chapters for dummies by Thesis

Ok, dos tíos en mi fagsub me pidieron que hiciera un tuto fácil de cómo usar los OC porque no entienden del todo el inglés y bueno, aquí os mostraré cómo se usan de manera simple y como se usan comunmente en la escena española. No tengo muchas ganas de hacer tanta TL;DR pues el tema del uso de Matroska abarca mucho, así que ahí va, lo más simple posible.

1.- Encodear el OP/ED/Cap por separado con todo lo que va a llevar en un .mkv, sería stream de video, audio y uno de subtítulos (aunque estén vacios) si vais a usar subs flotantes, pues los tres videos que uses (op/ed/cap) deben tener el mismo número de streams.
2.- Ahora viene la magia, ya que tenéis OP y ED finalizados, su versión final y tenéis listo el cap, lo que hay que hacer son los chapters que son un .xml, los puden hacer con su editor xml favorito o whatever, lo hacen manual o usan algún otro de muestra como base.

Aquí pongo un ejemplo de Ordered Chapters que hice:
http://freetexthost.com/ua2quj5y46

Ok, ahí está, esos son unos ordered chapters, lo que hay que notar es al inicio, donde ponemos los parámetros de los chapters, activamos los Ordered Chapters al poner un "1" en su flag, que es lo que lo hace diferente de los chapters comunes y activa la heavy magic. Otra cosa que hay que notar, es que esto funciona así, tienes que poner las secciones de video que quieres se reproduzcan al cargar el video en orden siempre poniendo el tiempo de inicio y el tiempo final. Con estos Oredered Chapters no sólo puedes hacer que cargue videos que estén en la misma carpeta, sino que puedes hacer que un video de 15mins se reproduzca tres veces seguidas tardando 45mins en total o cosas por el estilos, puedes jugar con la timeline del video, pues eso es lo que hace, crear una timeline, o sea, un orden de reproducción específico. Ahora notaran que hay partes con un ChapterSegmentUID format="hex" y un numerito abajo. Ahí es donde hacemos el Segment Linking con el OP y ED. Ahora, de dónde saco ese numerito? Ese número es el Segment UID o SUID, todos los .mkv tienen uno y aunque les cambies el nombre este nunca cambiará, a menos que hagas un remuxeo, cada vez que hagas un mux cambiará, por eso requiere que el op y ed estén en su versión final para poder extraer los SUID de ellos y ponerlos en los chapters, para ver el SUID de tu op y ed está una tool llamana MKV Info, que viene con las MKVToolnix. Simplemente revisamos el SUID de estos y los pegamos en el chapter sin los 0x que trae, revisando que sea el correcto pues si falla un número no lo cargará.

3.- Ahora lo que hay que hacer es el mux del cap, con mkvmerge simplemente preparas tu capítulo como siempre, con sus stream de video, el de audio y el de subs y en la pestaña "Global" cargas los chapters. Haces el mux y voilá, ya tienes tu cap con OC, el cap/op/ed deberán estar en la misma carpeta y cada vez que abras un cap xx te deberá cargar el op y ed en la timeline que le hayas puesto.

Eso sería todo lo más básico, si tienen alguna duda bueno, si puedo ayudar simplemente posteenla aquí.
Fuente: Walls of TL;DR

Kthxbye. o/

10 de diciembre de 2009

Cómo determinar si tu fuente es HD o SD

Estaba en #darkhold el otro día cuando cryptw preguntó si una imagen que puso era HD o no, claro que era HD, y bueno, ese no es el punto, la cosa es que Dark Shikari mostró una manera interesante de cómo notar si una fuente es HD o no. Entonces la cosa es super simple, tienes la imagen de alguna fuente que sospechas es HD a 720p, pero no estás serguro (método no válido para raws pre-filtradas con mierda); entonces le aplicas un spline36resize a SD y otro que lo regrese a HD, así:

spline36resize(848,480).spline36resize(1280,720)

Si notas una pérdida severa de detalle en alguna parte del frame, entonces es HD. Este método sirve para los que no tienen el ojo entrenado o no notan mucho la diferencia entre HD y SD. Para hacer esta prueba recomendaría que buscasen un frame con bastante detalle para percatarse de la pérdida si llegará a haber.

A continuación un ejemplo con la imagen que puso cryptw.

Fuente HD:

  
Después del proceso:


El truco aquí se nota en los envases de la derechar, se nota la pérdida de detalle sobre todo en sus etiquetas y definición. Puesto que esta imagen no tiene mucho detalle tal vez no sea la más conveniente para mostrar, pero igual sirve. Y bueno, espero que este truquillo le sirva a más de uno.

kbye. o/

26 de noviembre de 2009

Cómo hacer parches, how, wtf, etc...

Ok, resulta que a muchos les da pereza buscar o no tienen idea de dónde buscar y no saben aún cómo hacer parches en xdelta, usados comunmente para corregir errores de una archivo .mkv, crear una v2 y parchar mediante xdelta para no volver a subir un archivo entero; para no hacer bajar a los leechers dos veces lo mismo también... xD

Es bastante sencillo, se puede hacer mediante command lines vía xdelta, pero enseñárselos es complicarnos la vida, pues hay tools o scripts que nos ayudan al proceso, yo les pondré a continuación un script que sirve para hacer los parches "patch and pack" creado por edogawaconan, bastante simple de usar.

Requerimentos:
xdelta3 y patch and pack

Forma de uso:
1.- Baja los requerimentos y pon el script y el xdelta3 en la misma carpeta.
2.- Pon "edit" al script y coloca la dirección correcta del "7z.exe" en tu pc.
3.- Crea los archivos de diferenciación, la v1 y la v2 y ponlas en un mismo folder.
4.- Ejecuta el script, haz lo que te pide, pon la carpeta del input (donde están los dos archivos a parchar), en "old file" pon el archivo de la v1, en "new file" pon el archivo de la .v2, en prefix pon cómo se llamará el parche, por ejemplo "lalapatch".
5.- Profit.

Y ahí tienen, el .zip del parche deberá aparecer en tu carpeta del input. Fácil y simple.
kbye. ( ´・‿-) ~ ♥

15 de noviembre de 2009

CoreAVC borks

Eso, CoreAVC se jode con las WeightP (yay~), implementado en las últimas revisiones de x264. No es que CoreAVC sea muy importante ni mucho menos, solo sentí que debían saberlo... ffmpeg-mt tendrán que usar, sí, el más reciente usado en el cccp es estable y está bastante bien optimizado así que no extrañarán CoreAVC debido a su rapidez en el decoding. Si usan su soporte CUDA podrán reproducir los nuevos encodes, pero porque el decoder de Nvidia lo hace todo, preferible usar ffmpeg-mt. De lo contrario verán pequeños artefactos y bloques donde no deben estar.

Ahora, os lo digo porque probablemente muchos encoders (incluyéndome) empezaremos a usar las WeightP ya que el problema de los fades con mbtree ha sido arreglado y supone un gran avance encuanto a compresión de video se refiere. So, yay weightp~ CoreAVC trolling it hardcore~

Kthxbye.

10 de octubre de 2009

¿Cómo hacer un buen desentrelazado? (Desactualizado)

Nota: Los modes de animeivtc que menciono son para una versión antigua del script, así que si bajan el más reciente, lean la documentación antes para usar los modes indicados. Luego actualizo esta wada. -3-

Bueno, me he encontrado con muchos que no tienen ni idea de cómo desentrelazar ni saben "what the fuck is that" y se van por el automático del megui por vagos... ´-´

Así que aquí os guiaré más o menos cómo desentrelazar material de anime. Primero que todo, lo más importante para un desentrelazado correcto, es el análisis de la fuente. La mejor herramienta para desentrelazar es YATTA (que no os la enseñaré debido a que aún no lo manejo, pues su uso es algo complicado), otra alternativa que le sigue es AnimeIVTC. Ahora, lo que hay que hacer es el análisis de la fuente con DGIndex (sacado de la documentación de AnimeIVTC):

1 - DGIndex te dice "100% Film" y ves patrón 3:2. Es un Soft telecined, lo único que hay que hacer es marcar "Forced Film" en el DGindex para hacer el pulldown a 23.976fps.
2 - DGIndex te dice "100% Film" y ves frames progresivos y entrelazados sin un patrón específico. Es un Double hard telecined encodeado como progresivo. Usa el mode=2.
3 - DGIndex te dice "algo diferente a 100% Film" y ves un patrón 3:2. Es un Hard telecined. Fácil, usa el mode=1 de animeivtc.
4 - DGIndex te dice "100% Video (NTSC o PAL)" y ves frames progresivos y entrelazados sin un patrón específico. Es Double hard telecined. Usa mode=2 de animeivtc.
5 - DGIndex te dice "100% Video (NTSC)" y ves patrón 3:2 + créditos truly interlaced y/o progresivos. Es Hard telecined + créditos entrelazados o progresivos encima. Para esto hay que usar el mode=3 con omode=1, marcar la zona donde están los créditos entrelazados o progresivos (leer apartado de "Truly interlaced credits", no la pienso traducir) y hacer un encode VFR que se explica en la documentación de animeivtc.
6 - DGIndex te dice "100% Video (NTSC or PAL)" y ves frames progresivos y entrelazados sin un patrón específico + créditos truly interlaced y/o progresivos. Es Double hard telecined + créditos entrelazados o progresivos encima. Para esto hay que usar el mode=4 con omode=1, marcar la zona donde están los créditos entrelazados o progresivos (leer apartado de "Truly interlaced credits", no la pienso traducir) y hacer un encode VFR que se explica en la documentación de animeivtc.
7 - DGIndex te dá un porcentaje de Film o Video de 50 a 95% y ves patrón 3:2 + secuencias progresivas (no sólo los créditos, sino todo el frame). Es un Hybrid. Para esto usas el mode=5 y haces un VFR encode.
8 - DGIndex te dá un porcentaje de Film o Video de 50 to 100% y ves patrón 3:2 + secuencias progresivas (no sólo los créditos, sino todo el frame) + créditos truly interlaced y/o progresivos. Para esto hay que usar el mode=6 con omode=2, marcar la zona donde están los créditos entrelazados o progresivos (leer apartado de "Truly interlaced credits") y hacer un encode VFR que se explica en la documentación de animeivtc.

Con éso tiene todo el uso de animeivtc que necesitan, para más info deben leer su documentación, aunque está en inglés... ´-´

Ahora, algunas veces, animeivtc es overkill, por ejemplo en algunos casos de Soft telecined o Hard telecined (frecuente cuando se manejan TS), bastará con aplicar un "TFM().TDecimate(mode=1)" que viene en el paquete de TIVTC y les hará un desentrelazado correcto, si en todo caso hubiera combing o créditos entrelazados, probar con animeivtc será la opción. Igual pueden hacer encode VFR con TIVTC moviendo los settings en TFM, pero no me meteré a explicarlo porque creo que animeivtc es mejor en ese aspecto.

Ya les mostré cómo usar el IVTC salvo YATTA y otras formas de IVTC como el IT. Así que creo que ahora no habrá excusa para usar el automático del megui (´-´).

Saludos y espero esto le sirva a más de uno que trabaje con DVDs o Transport Streams. :3
kbye o/

25 de septiembre de 2009

¿Cómo usar x264 CLI?

Vale, aquí os mostraré cómo se usa el x264 CLI a base de command lines. Cosa que muchos no saben. Primero que nada a bajar la última revisión de x264 . Recordad que está en constante desarrollo, así que la última puede o no ser una revisión estable y traer o no bugs, ya les tocará averiguarlo en Doom10. Una vez abajo, hay que hacer un .bat para llamar a x264. En este .bat irá las especificaciones del encode y todo. Cómo se crea? Fácil, abrid el notepad y guardar con extensión .bat. :3~

Ejemplo de lo que debe ir en el .bat:
x264.exe --crf 16.0 --preset veryslow --ref 9 --output "output.mkv" "oblivious.loosless.avs" 2> log.txt

La cosa es poner: x264.exe --aquí van las command line, las especificaciones de tu encode --output "aquí el nombre del output.mkv" "aquí el nombre del avs.avs" 2> log.txt (es importante poner el log).

Ahora que tienen el .bat, sólo hay que crear el avs de lo que vayan a encodear y tener todo en la misma carpeta (el x264.exe, el x264.bat y el .avs). Sólo ejecutar el .bat y voilá, su encode con x264 CLI empezará en poco.

Cuáles son las ventajas de usar el CLI y no Megui? Bueno, aunque con megui se puede introducir command lines, por lo general la core no está actualizada con las nuevas implementaciones de x264. Además de que Megui te gasta más ram de lo normal, y dirán "tengo suficiente ram, no me importa usar megui" pero yo les diré, saben lo que es mbtree? Pues si no, investíguenlo, que la última revisión de x264 ya lo trae por default, y si no saben lo que es tal vez les joda un poco el encode. Y por qué digo lo del mbtree? Porque este te come ram a morir... por eso la ventaja de usar el CLI xD. Claro que como toda implementación la pueden desactivar y hacer un encode como venían haciendo hasta ahora con un simple "--no-mbtree".
Edit: Don't ever ever use Megui, está tan buggeado que encodear con las nuevas revisiones de x264 les será un dolor de cabeza, usar el cli es mucho más fácil y eficiente ahora.

Espero que esta info le sirva a más de uno.
Además, lo que necesitan saber más que nada es manejar los settings de x264, los cuales encuentran aquí:
x264 Settings - MeWiki
kbye o/

25 de agosto de 2009

BakeWarpsharp >9000

Dá asco ver este tipo de encodes... Seriously, lo peor es que ya se les ha dicho varias veces (Tokzu Fansub) que sus encodes son horribles, igual no cambian. :V
El video es 720p a 190mb, first lolwut. Si van a sacar a ese peso, al menos hagan resize a 480p para no filtrar tanto ni cagarla tanto y usen CRF for God sake. Por cierto, Bakemonogatari sí se transmite en HD, por lo que 720p estaría bien, pero claro, con el peso adecuado :3

El filtrado es excesivo y horrible. Tiene warpshar y oversharpening, lo que significa aliasing, artefactos, chroma bleeding, no dithering (no grain, no hay profundidad) y bloques overninethousend (por el peso más que por el warpsharp). Y bueno, para no alargar, he aquí la prueba, no tengo que remarcar dónde están los errores puesto que son muy marcados:


Bueno, ya saben, no regalen eyecancer gratix, más peso no violará a tu abuela :3
Y no se olviden que el grain es tu hamijo para evitar imágenes planas como estas.

kthxbye.

20 de agosto de 2009

Acuarelas FFFFFFFFFFFFFFUU!

Cómo un fansub con ya bastante tiempo en el fansubbing puede seguir acuareliando taaaan feo?
tl;dr: Shiawase.
Dunno, but it gets me angry (ó_ó).

Just check this shit:



He aquí a lo que me refiero con filtrado excesivo, tl;dr acuarelas. Lavado de texturas de fondo y bordes pequeños con aliasing. Also, I see some blocks there (ó_ó). Probablemente sea un upscale, pero ya que han filtrado demasiado, no podría decir con seguridad (>_>).

Please, don't do that nevah. kthx.

Stop upscaling the fuck everything

Seriously, no es bonito.
Tienes que aumentar peso innecesario además de que genera pérdida de detalle debido al excesivo filtrado que muchos hacen (ó_ó). Y lo PEOR de todo es que algunos (no mencionaré quienes) aparte de hacer upscale a las raws del dvd... usan un bitrate bajo (>_>). That's so fucking dumb.

He aquí un ejemplo de lo que digo (Kokaku no Regios de Tokzu Fansub):


Nótese que el video está a 180mb y el dezentrelazado es horrible (nótese las lineas negras and stuff)... Bordes no definidos y bloques everywhere. Conclusión: Obvious shit is obvious.
Una buena versión hubiera sido a 480p, buen dezentrelazado, no el automatico del megui y claro, MÁS PESO. Unos cuantos megas más no se comerán a tus mascotas. La época de los 180mb y xvid is so old, ahora hay mejores conexiones y x264 está más optimizado.

So, please, do things how are supouse to be. No seas como los demás.

Thanks in advance. :3

16 de agosto de 2009

Grain is your friend

Este post es inspirado en cierto comentario que me tocó las pelotas (yes it did it xD). Hoy, navegando por la web, leí a randomsomefuckingone decir que cierta versión de FMA: Brotherhood se veía granulosa, y que no le había gustado, a lo que dije: you must be kidding. Pero no, no estaba bromeando.

Seriously, eso a lo que dicen granuloso, se llama GRAIN y es un efecto que la misma raw trae y que NO se debe remover, pues está ahí por cierto motivo, dar profundidad, evitar banding y conservar el detalle, por lo que removerlo vía spatial/whatever causa banding, eyecancer y el odioso chromableeding en algunos casos, dependiendo de qué tan fuerte sea el filtro usado. Así que sépanlo, el grain está ahí por algo y es tu amigo, cuídenlo y quiéranlo.

Ah, la verisón de FMA a la que se refería cierto comentario estaba excelente btw, justo el grain necesario y que traía deporsí la fuente. :3

Practicamente la mayoría de las fuentes trae grain, son pocas las que he visto que no lo trae. Se puede añadir con ciertos filtros, pero ya que el objetivo de un buen encode es conservar el video como el estudio quiere que el expectador lo vea, recomiendo no pasarse de la raya si pensáis añadirlo. Pero sepan el grain es SIEMPRE bueno, a sí, y mejora la compresión, se me estaba olvidando. :3

kthxbye

24 de julio de 2009