Reid,
buscando como utilizar sus parámetros, llegue a la conclusión que eran un poco contradictorios, o por lo menos inadecuados :
Level 4.1
este level lee y permite un rip de alta resolución en pixel, es decir que no mejora directamente el rip, solo que permite hacer un rip con tamaños de imágenes hasta 2048X1024 con 30fps o 1280X720 con 68 fps.
En un DVD estándar (la mayoria), la resolución es generalmente de 1280X720 o 720X576 con 25 fps.
El codec X264 utiliza al máximo el Level del original, es decir 3.1 para un DVD estándar.
Así que me parece inútil especificar el level para un ripeo, excepto si queremos bajar la resolución (y la calidad), poniendo un level inferior al original.
Tune Grain
en los parámetros de Tune grain vemos « ipratio 1,1 y pbratio 1,1 » es decir que Tune Grain disminuye las imágenes I y P privilegiando las B.
Y esto es un poco contradictorio con el Preset Slower... además de « modificar » el original.
Preset Slower
este parámetro implica un « subme 9 », es decir que la estimación de complexidad del pixel se va hacer en las imagenes I, P y B, Siendo las I las mejores para esta estimación RD. Y estas Iframes serian limitadas por el « Tune Grain ».
Entonces, hizo unas pruebas en linea de comando con un original vob extraído tal cual de un DVD, este original pesa 33,7 Mo con dos pistas audio (AAC y DTS), duracion 52'' (1300 frames).
Es un « extra » del DVD Amores perros, una entrevista al « chivo ».
Con sus parámetros :
Test 0 :
x264 --preset slower --tune grain --level 4.1 --crf 18
Tiempo 15'05'' ; tamaño : 50,8 Mo ; bitrate : 8048 kb/s
Vemos que es mas pesado que el original y con un bitrate superior lo que es contra-productivo.
Normalmente hacemos rip para bajar el tamaño de archivo, teniendo una fuente de calidad DVD. Entonces, tome esas decisiones como base de prueba :
1-obtener un archivo alrededor de tres veces inferior al original (seria mas o menos un rip de 1,5 Go para un DVD de 4,7 Go)
2-privilegiar la calidad sobre el tiempo de rip a condición que se nota visualmente en el rip obtenido
Para eso no cambie la resolución, el AR ni el frame rate del original y busque los parámetros X264 mas conocidos por influir sobre la calidad, tomando como base los presets de slow a very slow
Test 1 : Deje X264 elegir el bitrate lo que corresponde a un crf 23
x264 --me umh --subme 9 --merange 24 --ref 4 --b-adapt 2 --direct auto
Tiempo 4'48'' ; tamaño : 15,8 Mo ; bitrate : 2506 kb/s
Test 2 : bitrate impuesto para llegar a un tamaño acceptable
x264 --me umh --subme 9 --merange 24 --ref 4 --b-adapt 2 --direct auto
--bitrate 2000
Tiempo 4'42'' ; tamaño : 12,1 Mo ; bitrate : 2000 kb/s
Test 3 : bajando la codificacion aqui, sin nada, corresponde a
merange 16
x264 --me umh --subme 9 --ref 4 --b-adapt 2 --direct auto --bitrate 2000
Tiempo 4'23'' ; tamaño : 12,1 Mo ; bitrate : 2000 kb/s
Test 4 : siguiendo aqui con subme 7 es decir RD on all frame
x264 --me umh
--subme 7 --ref 4 --b-adapt 2 --direct auto --bitrate 2000
Tiempo 3'30'' ; tamaño : 12,1 Mo ; bitrate : 2000 kb/s
Test 5 : siguiendo aqui con el metodo de estimacion hexagonal
x264
--me hex --subme 7 --ref 4 --b-adapt 2 --direct auto --bitrate 2000
Tiempo 2'47'' ; tamaño : 12,1 Mo ; bitrate : 2000 kb/s
Test 6 : bajando el bitrate
x264 --me hex --subme 7 --ref 4 --b-adapt 2 --direct auto
--bitrate 1800
Tiempo 2'45'' ; tamaño : 10,9 Mo ; bitrate : 1800 kb/s
Test 7 : bajando el bitrate
x264 --me hex --subme 7 --ref 4 --b-adapt 2 --direct auto
--bitrate 1500
Tiempo 2'38'' ; tamaño : 9,0 Mo ; bitrate : 1500 kb/s
Test 8 :
ref 3 ; b-adapt 1;direct spacial que son los parámetros por defecto (significa un algoritmo de codificación mas rápido pero quizás menos eficaz)
x264 --me hex --subme 7 --bitrate 1800
Tiempo 2'18'' ; tamaño : 11,2 Mo ; bitrate : 1800 kb/s
Conclusión :
Sin perder de vista que hablo de un DVD estándar (seria diferente con un Bluray o un HD DVD), por una película de 90 min, paso de 26 horas de codificación a 4 horas mas o menos sin poder ver una diferencia realmente notable con el original.
Son solo ensayos para estimar la importancia de cada factor, esta claro que para un buen rip, es mas eficaz y seguro trabajar con dos pasadas.
En este archivo están todos los rips y el original para hacerse su propia opinión con sus propios ojos (no es que no fio en los mios, pero...):
TestX264.zip [178.79 Mb]
Por fin, para darse una idea de la capacidad del X264 a utilizar toda la potencia del CPU, he echo un test adjuntando este dato --threads 1 a la linea del test4 par limitar el uso del CPU a un solo core.
El tiempo de codificación pasa de 3'30'' con los dos core a 7'23" con un solo.
Parece importante verificar que su programa de ripeo es capaz de utilizar el multithreading....
Espero que os sirve para optimizar sus ripeos y el tiempo de codificación, avisos y experiencias bienvenidas.
