Formato XFS

Como dice Francisco de la Torre: me encanta el olor a borrado de particiones por la mañana.

 

He descubierto un formato para discos duros que no conocía, el XFS.

Todos conocemos Fat 32, ExtFat, HFS, Ext4… pero XFS…

Un formato veterano y de origen en Silicon Graphics.

Interesante para uso con archivos de vídeo. Es un sistema de archivos que puede soportar hasta 8 exabytes.

He comprobado que Red Hat y Centos formatean su disco duro con este sistema de archivos. En cambio Fedora, siendo de la misma familia, trabaja con Ext4.

Sería interesante averiguar su rendimiento en trabajo con vídeo. Si consigo hacer pruebas, publicaré resultados.

Aquí un test de un usuario de Arch Linux probando varios formatos, entre ellos XFS y Ext4. Son pruebas de rendimiento de sistema (benchmarks) pero pueden dar pistas.

Raw is Not Magic

Raw vs Log

Interesante artículo de Stu Maschwitz.

No todo es blanco y negro. Siempre hay grises. Raw tiene sus defensores y Log también.

He rodado y postproducido con los dos tipos de archivos. Últimamente me gusta utilizar el Log-C de la Alexa y Amira. Me da unos resultados increíbles y la comodidad de no necesitar un software específico para el debbuging del Raw.

Escalar vídeo con FFMpeg. Avanzado.

Hay formas sencillas para escalar un vídeo con FFMpeg:

ffmpeg -i input.mov -filter:vscale=1080:-1 output.mp4

Con -1 indicamos que conserve el aspecto (proporción) del original.

El problema viene cuando quiero escalar un vídeo dentro de una operación compleja de ffmpeg. Al usar, por ejemplo -filter_complex, no permite usar el cambio de escala de la manera normal.

Quería compartir este código que me ha costado bastante sacar a base de muchas pruebas y consultas en la web.

La idea era poder hacer un script para poder crear un vídeo con frames negros al comienzo y al final (esto es tema de una entrada anterior) y poderlo escalar al tamaño deseado. En este caso de 1920×1080 a 1280x 720

Para ello primero hay que indicar el tamaño que queremos en el generador de frames negros…

-f lavfi -i color=c=black:s=1280×720:r=25:d=1

… y luego escalar el vídeo que interesa dentro de -filter_complex

-filter_complex “[0:v] trim=start_frame=1:end_frame=5 [blackstart]; [0:v] trim=start_frame=1:end_frame=5 [blackend]; [2:v] scale=1280:-1 [scaled]; [1:a] atrim=duration=0.2 [audiostart]; [1:a] atrim=duration=0.2 [audioend];

Aquí el código completo:

ffmpeg -f lavfi -i color=c=black:s=1280×720:r=25:d=1 -f lavfi -i “aevalsrc=0:c=stereo:d=1” -i input.mov -filter_complex “[0:v] trim=start_frame=1:end_frame=5 [blackstart]; [0:v] trim=start_frame=1:end_frame=5 [blackend]; [2:v] scale=1280:-1 [scaled]; [1:a] atrim=duration=0.2 [audiostart]; [1:a] atrim=duration=0.2 [audioend]; [blackstart] [audiostart] [scaled] [2:a] [blackend] [audioend] concat=n=3:v=1:a=1[v][a]” -map “[v]” -map “[a]” -c:v libx264 -crf 22 -preset slow -profile:v high10 -pix_fmt yuv420p -c:a aac -strict -2 -b:a 128k -timecode 00:01:00:00 -tune zerolatency output.mp4

 

 

Sincros A/V con FFMpeg

ffmpeg

He realizado unas pruebas de compresión con FFMpeg en Mac. La idea era crear un script parecido a otro que realicé anteriormente para insertar frames de negro al comienzo y final del vídeo y comprimirlo para poder ser enviado por mail.

Al hacer estas pruebas me he dado cuenta que el resultado tenía un desfase entre audio y vídeo.

Describo las conclusiones de las pruebas por si son de utilidad para alguien y como recordatorio para mí.

Normalmente la entrada de vídeo que uso suele ser un master en alta, bien usando QT Animation o bien ProRes 444.

Quería probar qué codec es el idóneo para comprimir a mejor calidad y con menos “peso”

El problema que me encontré es que el resultado desfasaba dos frames el audio del vídeo.

Esto ocurría codificando con libx264 y aac

Para la prueba he creado un vídeo con un sólido de color que tenía un frame de barras y tono en varios puntos para poder ver los sincros a/v

Confirmé que había 2 frames de desfase con la librería libx264.

Resultado de pruebas con distintos codecs de audio y vídeo:

  • Con -c:v libx264 y -c:a aac — hay 2 frames de desfase. — .mp4
  • Con -c:v v408 (prores444) y -c:a aac — hay 1fr de desfase.  — .mov
  • Con -c:v v408 y -c:a pcm_s24le — audio y vídeo ok.  — .mov
  • Con -c:v qtrle y -c:a pcm_s24le — audio y vídeo ok.  — .mov
  • Con -c:v mpeg1video y -c:a mp2 — audio y vídeo ok. (Codecs por defecto de ffmpeg)  — .mpg
  • Con -c:v mpeg1video y -c:a aac –Fallo. No abre en QT  — .mpg
  • Con -c:v libxvid (mpeg4) y -c:a aac — audio y vídeo ok. — .mp4
  • Con -c:v libxvid (mpeg4) y -c:a pcm_s24le — audio y vídeo ok. — .mov

Por otro lado he comprobado que el h264 usado con libx264 es un codec MUY superior a mpeg1video o  libxvid (mpeg4). Comprimiendo el mismo vídeo y a igual tamaño, el h264 da mucha más calidad que el mpeg4 y mpeg1… con diferencia.

Por tanto interesaba arreglar la falta de sincros entre audio y vídeo porque interesa más usar libx264.

Si añadimos -tune zerolatency despues de los settings de compresión con libx264, conseguimos que vayas a sincro el audio y vídeo.

Aquí os muestro los comandos usados con ffmpeg desde el terminal para crear 5 frames de negro delante y detrás del vídeo y comprimirlo en h264 en una relación aproximada de 12:1 Mb

Al utilizar el codec aac he tenido que añadir el comando” -strict -2″ para poderlo usar.

ffmpeg -f lavfi -i color=c=black:s=1920×1080:r=25:d=1 -f lavfi -i “aevalsrc=0:c=stereo:d=1” -i test_sincro.mov -filter_complex “[0:v] trim=start_frame=1:end_frame=5 [blackstart]; [0:v] trim=start_frame=1:end_frame=5 [blackend]; [1:a] atrim=duration=0.2 [audiostart]; [1:a] atrim=duration=0.2 [audioend]; [blackstart] [audiostart] [2:v] [2:a] [blackend] [audioend] concat=n=3:v=1:a=1[v][a]” -map “[v]” -map “[a]” -c:v libx264 -crf 40 -preset slow -profile:v high10 -pix_fmt yuv420p -c:a aac -strict -2 -b:a 128k -timecode 00:01:00:00 -tune zerolatency mail_low.mp4

No conozco la razón de la falta de sincros entre audio y vídeo del codec libx264 en Mac. Cualquier explicación o aporte será bien recibido.