x264

Desde hace tiempo, los usuarios de x264 han hecho peticiones para que el encoder tenga opciones para ofrecer mayor compatibilidad con BluRay. Esto es debido a las especificaciones estrictas que contiene, y algunas opciones buenas de x264 quedan fuera de este rango.

Lo último parcheado ha sido con B-Pyramid, ofreciendo la posibilidad de utilizar esta gran opción con compatibilidad Bluray. Sin duda alguna un trabajo excelente por parte de los desarroladores. Veamos que datos obtenemos a la hora de codificar con él:

B-PYRAMID – r1296

• –b-pyramid none: Desactivado.
• –b-pyramid normal: El b-pyramid de siempre, el cual no es totalmente compatible con la estructura bluray, pero si el que mejor trabaja a la hora de mejorar la compresibilidad. Se ha mejorado los problemas con DPB de la versión anterior (DPB = ref * resolución. El tamaño de buffer especifico en  ciertos aparatos físicos hacen que sea necesario vigilar este valor)
• –b-pyramid strict: b-pyramid adaptado a las especificaciones de Bluray. Únicamente indicado para vídeos en los que se quiera compatibilidad con las especificaciones de Bluray.

PRUEBA

• x264-x264.nl –pass 1 –bitrate 3700 “J:\Source\video.yuv” –bframes 6 –no-mbtree –stats stats.tmp –b-pyramid XXX –psnr –ssim -o pyramid-off.mkv 1920×1080
• x264-x264.nl –pass 2 –bitrate 3700 “J:\Source\video.yuv” –bframes 6 –no-mbtree –stats stats.tmp –b-pyramid XXX –psnr –ssim -o pyramid-off.mkv 1920×1080

Las XXX se cambian por none, normal y strict. Los resultados de PSNR y SSIM son:

PSNR

• none = PSNR Mean Y:42.689 U:46.283 V:48.544 Avg:43.478 Global:40.545
• normal = PSNR Mean Y:42.859 U:46.422 V:48.651 Avg:43.642 Global:40.625
• strict = PSNR Mean Y:42.842 U:46.419 V:48.652 Avg:43.627 Global:40.611

SSIM

• none = 0.9711436
• normal = 0.9715685
• strict = 0.9714916

Esta es una mini-prueba de fuerza bruta sobre el uso de CPU a la hora de comprimir vídeo.

ORDENADOR UTILIZADO EN AMBOS CASOS

• CPU: 2.33 QUAD 8200 sin OC
• RAM: 6GB DDR – 1066
• T.Gráfica: ATI HD2600 XT
• Monitor: ASUS / 1920 x 1080 de resolución
• Disco Duro: 500Gb seagate para Windows 7 y 250Gb para Ubuntu, ambos con SATA.
• Source de Vídeo: Utilización de los primeros 10.001 frames de Elephants Dreams de la RAW PNG a 1920×1080. Utilizado avs2yuv para convertir los frames en PNG a formato YUV para ser interpretado directamente por el encoder x264 sin la necesidad de un interprete adicional.

LINUX – Ubuntu 9.04 64bits (Instalado)

En Linux no existe la facilidad para encontrar el x264 compilado, así que se ha obtenido compilando con GCC 4.4.0 mediante los siguientes pasos:

sudo apt-get update
sudo apt-get install build-essential subversion git-core checkinstall yasm

cd
git clone git://git.videolan.org/x264.git
cd x264
./configure
make
sudo checkinstall –fstrans=no –install=yes –pkgname=x264 –pkgversion “1:0.svn`date +%Y%m%d`-0.0ubuntu1″ –default

WINDOWS 7 -RTM – 64Bits

En windows he decidido probar dos versiones:

• Compilado con GCC 4.2.4: gcc 4.3.4 20090220 Komisar make fprofiled
• Compilado con ICC (Intel C++ Compiler (icc) v11.1.038)

PREPARACIÓN DE EQUIPO

En WINDOWS 7 y en UBUNTU 9.04 esta todo lo no indispensable desactivado:

• Antivirus
• Cualquier tipo de mensajería
• Navegadores
• Salvapantallas

Y en ambos casos se han realizado las pruebas después de un reinicio, para evitar cualquier problema con programas mal cerrados.

Leer más…

Bastantes novedades en esta versión, ya que me ha llevado un poco acabarla. Todo es debido al problema de los Presets, que son bastante liosos de implementar. Yo lo he hecho de manera sencilla, aunque aplicaré en la siguiente versión algunas mejoras en este aspecto.

Lo mas interesante es la opción  de conocer el tiempo de la compresión de manera individual. Una buena opción, junto a PSNR y SSIM, para realizar comparaciones entre distintas configuraciones.

• Añadido tiempo de cada compresión de manera individual.
• Añadido –no-psy para desactivar la opción PSY-RD.
• Añadido AQ-Mode 3 en modo experimental.
• Añadido Subme 10
• Añadido MB Tree
• Añadida la opción RC-lookhead.
• Mientras comprime, si se cancela, aparece un cuadro de verificación.
• Ahora mientras se comprime si se cierra, pregunta para verificar la salida.
• Añadida una opción mas a partitions.
• Añadido el icono del 66% para el Systray. Faltaba en la versión 0.54.
• Añadida la opción de Primera pasada Rápida.
• Incorporado los profiles nuevos de las versiones posteriores de x264 +1176.
• Actualizada la configuración para la nueva configuración de x264 +1176

Para descargar, en Divxhouse

Una entrada de hace pocos días hacía hincapié en la calidad ofrecida por los distintos Presets introducidos en x264. Ahora se os presenta la gráfica con el porcentaje de velocidad con respecto al Preset Medium.

ULTRAFAST   306%

VERYFAST   214%

FASTER   151%

FAST   120%

MEDIUM   100%

SLOW   57%

SLOWER   38%

VERYSLOW   28%

En los Presets se ha pospuesto Placebo debido a problemas con x264 y 32bits.

ENTRADA DE CALIDAD DE PRESETS

http://www.x264.info/2009-08/pequeno-test-de-los-distintos-presets

AQ-MODE sirve para redistribuir el bitrate a lo largo de los macrobloques, mejorando la calidad de estos. Esto ocurre en escenas muy uniformes: cielos, suelos, oscuridad, claridad,  etc.

Dentro de las novedades del x264-experimental, contamos con una muy interesante: AQ-Mode 3. Este nuevo modo mejora sensiblemente los macrobloques en los Fade Out-In (transiciones de escena), reduciendo los macrobloques en estos frames.

NECESARIO

Una versión de x264 con el parche de aq-mode 3 aplicado:

• http://komisar.gin.by La versión kMod-CLI versión 32 o 64 bits

En la línea de comandos añadir –aq-mode 3

EJEMPLO

“x264.exe” –pass 1 –bitrate 800 –preset medium –aq-mode 3 –psnr –ssim –stats “stats.tmp” “aqmode-3.avs” -o NUL

RESULTADOS

Se han marcado los frames donde empiezan y acaban los FADE. Se puede apreciar como la curva de SSIM en AQ-MODE 3 es mucho mas alta, mejorando la calidad visual de una manera evidente. Esto se ve en las imágenes siguientes.

Leer más…

Una de las grandes ventajas de utilizar un SO de 64 bits es su capacidad de utilizar una mayor cantidad de memoria RAM, tanto a nivel general (4GB) como a nivel individual (2GB). Otra es la optimización de programas en 64bits, mejorando ligeramente al equivalente de 32bits.

Por desgracia, no existe ninguna versión de avisynth estable a 64bits, con lo cual tenemos que utilizar programas externos para utilizar el x264. En este caso utilizamos el avs2yuv, el cual convierte el script de avisynth (AVS) a una RAW de vídeo. Este archivo puede ser leído sin problemas por x264-64Bits.

Pero una de las grandes ventajas del x264 es la posibilidad de enlazar programas (pipe), evitando de este modo un paso intermedio. Con esto podremos utilizar el avs2yuv junto con las últimas versiones de x264.

NECESARIO

• avs2yuv:  http://akuvian.org/src/avisynth/avs2yuv
• x264-64: www.x264.nl (cualquier versión 64bits)

Es importante conocer la resolución del vídeo de salida y el FPS del mismo. Estos dos valores son importantes para añadir a la línea de comandos.

EJEMPLO: Comprimiendo (1 y 2 pasadas)

“avs2yuv.exe” “video.avs” -raw – | “x264-64.exe” – 1920×1080
–fps 24 –pass 1 –bitrate 4500 –preset medium –stats “stats.tmp” -o NUL

“avs2yuv.exe” “video.avs” -raw – | “x264-64.exe” – 1920×1080
–fps 24 –pass 2 –bitrate 4500 –preset medium –stats “stats.tmp” “” –output “video-arx264.mkv”

Sin duda alguna los Presets han servido para reducir las complejas líneas de código a la hora de comprimir por este método. Esto ha supuesto una ayuda para los usuarios noveles y que no utilizan ningún programa visual (GUI) para el x264 (ARx264 o MeGui).

Los Presets no sobreescriben las opciones siguientes a él, de tal forma que si añadimos:

–Preset Ultrafast –bframes 8

Ultrafast aplica 0 bframes, pero al añadir bframes 8, se aplicará esta opción.

TEST

El test que se ha aplicado no es totalmente objetivo, ya que se ha utilizado únicamente 8min de vídeo tipo Animación. De todas formas, esto sirve para ver las diferencias entre los tipos de Preset de una manera totalmente visual.

• Encoder: x264 32bits – r1222
• Datos del vídeo: 8min de RAW a 1920 x 1080 de Elephants Dreams.

RESULTADOS

Se puede apreciar que los Presets Ultrafast, Veryfast y Faster, se alejan del resto de grupos, ofreciendo una calidad inferior al resto, pero con una muy buena velocidad final.

Medium, el cual es la opción por defecto, permite aunar en una opción tanto buena velocidad como buena calidad, quedando Slower, Veryslow y Placebo como opciones no recomendables.

SubME

Es el encargado de controlar la precisión en la estimación de movimiento. Cuanto mayor sea este valor, mejores serán los resultados y peor será la velocidad de codificación. No es recomendable el utilizar valores por debajo de 6, ya que se pierde optimización en calidad y también se pierden algunas opciones (psy-rdo, trellis a 2, etc).

Diferencias entre niveles 6,7,8,9 y 10.

• SubME 6: Rate Distortion en I-Frames y P-Frames.
• SubME 7: Rate Distortion en todos los frames.
• SubME 8: Rate Distortion mejorado en I-Frames y P-Frames.
• SubME 9: Rate Distortion mejorado en todos los frames.
• SubME 10: Qpel en Rate Distortion.

Pruebas de los distintos niveles

En la prueba realizada se ha hecho uso de la RAW a 1920 x 1080 de Elephants Dreams, utilizando los 5000 primeros frames. El original esta en PNG, así que se ha hecho uso de avisynth como interprete para la codificación:

ImageSource(“D:\source\ED-1080-png\%05d.png”, start=000001, end=005001, fps=24, pixel_type=”rgb32″)
converttoyv12()

Resultados de las pruebas

Se han utilizado varios bitrates para las pruebas: 4500, 6000, 7500 y 9000. Y todos mezclados con los distintos niveles de SubME: 6,7,8,9 y 10.

Como en la anterior entrada de x264.info, he utilizado tanto PSNR como SSIM para las pruebas de calidad.

Leer más…

En versiones posteriores a la r1197, se ha añadido un nuevo método para el control de la curva de bitrate. En diversas pruebas la mejora es muy buena, siendo mejor, cuanto menor sea el bitrate aplicado. Una muestra es este gráfico realizado sobre un bluray a 1080p > 720p y con la opción -preset slower

Las gráficas utilizadas son SSIM y PSNR. Segun ciertos experimentos, la medida SSIM es mucho mas precisa que la PSNR. De todas formas aquí estan las dos:

Se puede observar en ambas gráficas, que la opción MB-Tree ofrece mejores resultados, aun sin poder utilizar bpyramid, ya que el nuevo método aun siendo experimental, es totalmente funcional.

Esta página habla casi en exclusiva sobre el encoder x264, pero no esta de mas el ver otras posibilidades. En este caso Divx nos sorprende con una nueva versión de su encoder de H264 por linea de comandos (como x264). El funcionamiento es similar y las características estan limitadas en ciertos aspectos. Veamos cuales:

• Limitación a máximo de frames sin un Keyframe (GOP) : 4 Segundos | Según los desarrolladores esto sirve para mejorar la búsqueda en la barra de tiempos al haber un Keyframe cada poco tiempo. En cierta manera tienen razón, pero limita la posibilidad de aprovechar bitrate malgastado en alguna escena fija (slow motion).
• Limitado a Level 4.0 | Segun comentan desde Divx, se ha optado por el Level 4.0, y no 4.1 (bluray) para así evitar excesivas zonas de bitrate. Realmente esto no modifica nada salvo el máximo bitrate aplicado.
• Posibilidad de enlazar ffmpeg por pipe al encoder | Esto es muy interesante para realizar compresiónes utilizando los filtros de FFMPEG. Desde Divx explican como se puede hacer esto. x264 lo permite desde hace muchas versiones.
• Reparto de bitrate | De lo poco que he probado, he visto que la curva de SSIM que realiza a cualquier vídeo, lo hace desde un punto de vista equilibrado. Es decir, la propia curva es muy estable. En x264 se utilizan otros factores para realizar esta distribución de calidad, mejorando el total al atribuir la calidad en zonas donde visualmente son mas evidentes.
• Limitaciones en B-Frames (3) y Ref-Frames (4) | Aquí descubrimos otras limitaciones debido al uso exclusivo del Level 4.0

Las sensaciones son interesantes, pero Divx sigue pecando de resultados algo borrosos, dando la impresión de haber aplicado algún filtro para evitar la aparición de macrobloques. A pesar de estas limitaciones, es bueno disponer de competencia y ver que Mainconcept, (el encoder de Divx proviene de esta compañía) ha superado a otros encoders de pago.

Habrá que estar atentos a futuras versiones donde implementen alguna opción similar al AQ-Mode, el cual es indispensable para bajo bitrate, y así aprovechar las posibilidades de MPEG4-AVC.

Divx H264 Beta2 Encoder