x264

He añadido un pequeño script que informa de la última versión de x264 disponible (arriba a la derecha). En este caso se refiere siempre a la versión que exista en www.x264.nl

Como comentaba en el anterior articulo, desde el grupo que lleva x264 se intenta mejorar las funcionalidades del encoder, añadiendo mayor soporte que el de enocoder x264. En primera instancia recuerda un poco al binario de ffmpeg, pero quizás la diferencia sea que en este caso, estará totalmente optimizado para girar en torno a x264 y con otras funcionalidades específicas.

Desde el blog de Darkshikari (Jason Garrett-Glaser), nos comenta en una entrada como será el futuro de x264.

1º – Mejoras en el algoritmo del encoder

Parte del futuro se basará en optimizar y mejorar los algoritmos de ciertas funciones dentro del encoder. Estas optimizaciones pueden ser de cualquier aspecto y estarán siempre sujetos a la base de H264. Dentro de estas se podrán encontrar desde mejoras en la codificación como mejoras en la decodificación.

2º – Mejoras en el uso del encoder por línea de comandos.

Dentro de este futuro prometedor, se intentará incluir ciertos elementos interesantes al proyecto como estos:

• Resizing: Gracias a libswscale
• Soporte para distintos dispositivos: Será similar a la opción de Presets pero para dispositivos muy determinados (PSP, IPOD, etc)
• Soporte para codificación de audio: Gracias a libvacodec (vorbis-ogg y aac)
• Soporte para desentrelazar: Gracias a Decomb.
• Muxer compatible con DVB-compatible TS muxer
• Opción para elegir múltiples posibilidades de -tune

3º – Futuros añadidos

• CBR y VBR NAL-DRH con soporte para VFR. Esto asegurará compatibilidad 100% con las especificaciones bluray.
• OPEN-GOP: Mejora para codificaciones con intervalos cortos entre Iframe (bluray).
• Mejoras en el soporte de VFR.
• Mejoras en la API (libx264) para facilitar el uso en otras aplicaciones.
• Disable_deblock_idc = 2: Desactivar el deblocking en los slices. Esto mejorará la latencia y la calidad del frame a recuperar si se utiliza “slices” al codificar.
• Cambio de Ratecontrol al vuelo: Permite ajustar el bitrate/sg sobre la marcha, haciendo esto ideal para streaming.

FUENTE ORIGINAL: http://x264dev.multimedia.cx/?p=270

No todas las mejoras de x264 son a nivel de resultados visuales. También existe esfuerzo en crear una interface sencilla (siempre hablando de la linea de comandos). Dentro de esta modalidad se ha visto la inclusión de los PRESETS, PROFILE y TUNE, facilitando el uso de la línea de comandos para los usuarios nuevos o no tanto.

x264 permitía la carga de vídeos por tres métodos: YUV (4:2:0), script Avisynth (necesario Avisynth instalado) y AVI (necesario el decoder del archivo a cargar, instalado en su modalidad DSHOW). Salvo que tengamos el archivo en YUV, el resto de casos implica tener instalado alguna aplicación, ya sea avisynth o el decoder del vídeo a cargar (por AVI).

Ahora esto ha cambiado y se ha añadido FFMS2, conocido dentro del mundo de Avisynth ya que tiene un filtro aprovechando esta API de FFMPEG, y libavformat de FFMPEG.

FUNCIONAMIENTO

El funcionamiento es realmente sencillo. Desde www.x264.nl podemos bajar las últimas “build” donde vienen ya compilados con estos decoders. Y será posible comprimir un vídeo en Matroska, OGM, AVI, etc.. sin la necesidad de tener nada instalado. Sin duda el beneficiado será para aquellos que no utilicen Windows (Linux, Mac, etc) o los que no quieran instalar nada adicional para comprimir.

• x264.x64 –crf 21  –output “Video-Final.mkv” “Entrada.mkv”

La carga es automática y en la mayoría de los casos el funcionamiento es perfecto. Al esta en evolución, es posible que exista problemas a la hora de comprimir con FPS no habituales o con VFR (variable framerate).

FUTURO

Próximamente veremos algo que estoy esperando desde hace tiempo: Filtros internos para resize de vídeos, filtros para desentrelazar, codificación de audio (aac, ogg, mp3,etc), etc.

Estas novedades serán analizadas en profundidad muy pronto.

Esta versión contiene gran cantidad de mejoras. Sin duda alguna es el referente para aquellos que deseen crear un HTPC con alguna placa con ATOM + ION, ya que el decoder hace uso de CUDA para acelerar la decodificación de vídeo, permitiendo la visualización perfecta de vídeos a 1080.

- Soporte para Windows 7 y sistemas 32 y 64 bits.
- Mejoras en el soporte de CUDA NVIDIA.
- Hasta 16 cores de uso.
- Resolución QuadHD (3840×2160) soportado
- Incluye Haali Media Splitter de diciembre (19/12/2009)
- Soporte total para vídeos entrelazados.
- Arreglado problemas con los vídeos creados con WeightP.

Ahora mismo tienen una oferta en la página web, quedando a 9.95$.

http://corecodec.com/products/coreavc

Nueva versión de este encoder en castellano para comprimir en HD utilizando el encoder x264. Las novedades son limitadas, pero contienen las últimas opciones del encoder.

• Añadido soporte para los dos tipos de B-Pyramid: normal y strict.
• Añadido soporte para weightp y sus 2 niveles.
• Actualizado x264 x32 a la versión r1352.
• Añadido soporte para utilizar el contenedor FLV en la salida.

Más información para su descarga en Divxhouse.com y aquí un manual sobre el mismo programa -> AQUÍ

Deadzone y Trellis son dos algoritmos para averiguar el coeficiente ideal de cada bloque basado en DCT (Transformada de coseno discreta). Estos dos algoritmos sirven para minimizar la perdida de calidad en base a un bitrate de entrada.

Por defecto Deadzone tiene estos valores:

• deadzone-inter: 21
• deadzone-intra: 11

Y por defecto trellis: 1.

Ahora mismo el funcionamiento de ambos algoritmos es simultaneo, quedando trellis siempre  por encima de deadzone. Pero existen varias opciones, donde trellis=0 deja a deadzone como algoritmo en exclusiva y trellis=2 como en exclusiva sobre deadzone.

Deadzone permite utilizar valores de 0 a 32. Este algoritmo establece el nivel de detalle a descartar a la hora de codificar, ya que ciertos detalles que no son apreciables a simple vista, precisan de gran cantidad de bits para su codificación . Este descarte permite preservar bits en otras zonas de mayor necesidad. Los valores cercanos a 0 tienden a preservar los detalles, en cambio los cercanos a 32 tienden a descartarlo. Los valores intermedios (los que trae por defecto), son los mas adecuados para una calidad optima.

EJEMPLOS

Evaluar el funcionamiento de este algoritmo es realmente complicado, ya que la fuente influye en el comportamiento del mismo. Veamos unos simples ejemplos con diversos valores de Deadzone.

BITRATE 2700 y configuración por defecto.

Desactivado: PSY-RD, TRELLIS, DEBLOCK

Leer más…

Nueva página en x264.info donde hay una selección de lo mejor para visualizar y comprimir x264.

Tambien se ha hecho una selección para los SO que no son Windows.

http://www.x264.info/codecs

Recientemente se ha estrenado weightp dentro del encoder x264. Entre las mejoras, se destaca en los fade o variaciones de luminosidad. El problema llega ahora a la hora de reproducirlos sin problemas y se ha detectado que algunos decoders no lo reproducen correctamente.

Leer más…

Una de las nuevas características de x264-r1327 es la posibilidad de activar weightp en la codificación. Esta opción proporciona mejoras a la hora de distribuir bitrate mientras se codifica, en este caso en los P-Frames.

Las mejoras aparecen cuando existen transiciones FADE IN-OUT. Con esta opción, la calidad durante las transiciones es mayor, ya que se premia mas a la distribución de bitrate de frames adyacentes. Y esta es una de las razones por las que en los FADE es mayor esta mejora.

Para verificar esta opción he realizado una pequeña prueba con un script preparado para provocar transiciones (FADE OUT-IN).

SCRIPT AVISYNTH

LoadPlugin(“F:\Programas\ARx264 0.56\filter\DGAVCDecode.dll”)
AVCSource(“F:\Transformers 2007 \Transformers.dga”, deblock=false)

a=trim(4400,5100).FadeIn(120).Fadeout(120)
b=trim(5101,5600).FadeIn(120).Fadeout(120)
c=trim(5601,6000).FadeIn(120).Fadeout(120)
d=trim(6001,7000).FadeIn(120).Fadeout(120)
e=trim(7001,7500).FadeIn(120).Fadeout(120)

a+b+c+d+e
crop(0,144,0,-144)

Leer más…

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