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.

 

Anuncios

FFmpeg and H.264 Encoding Guide

Una de las razones para usar FFmpeg para codificar vídeo es su potencia. Podemos hacer cosas que con otros métodos como Compressor, Adobe Encoder o Mpeg Streamclip sería imposible.

Es verdad que estos últimos son más cómodos y fáciles de usar.

Es verdad que usar el terminal no es lo más idóneo cuando hay prisa y tienes que convertir rápidamente un lote de vídeos…

… pero mola tener el control de todo. Y eso solo lo tienes usando FFmpeg.

En esta interesante guía podemos ver como hacer H264 finos, finos.

Una de las cosas más útiles que nos enseña la guía es a limitar el peso del archivo de vídeo que queremos codificar. Por ejemplo: quiero que mi vídeo de 10 min ocupe 6Mb ¿cómo lo hago?

Interesante la fórmula: bitrate = file size / duration

También podemos descubrir que en FFmpeg hay presets como en Encoder, Compressor… y que los podemos modificar.

Test de codecs de vídeo en alta.

El otro día decidí hacer unas pruebas rápidas para comparar codecs con los que trabajo bastante. Todo en entorno QT.

El motivo de las pruebas eran mis sospechas de que el codec Animation subía de gamma un poco.

Al final los codecs que he comparado son:

-Secuencia TIFF

-None

-Animation

-Prores4444

-Photojpeg 100%

-Photojpeg 90%

-H264 con bitrate a 240Mbps

No he descubierto nada nuevo pero quiero compartir mis pruebas ya que  he dedicado un tiempo a ello.

A mi me ha servido para aclarar ciertas cosas.

He hecho pruebas con vídeo de 1s. Los he generado en AE a 16bpc con MacPro Early 2008

Pesos sobre vídeo de 1s:

Secuencia Tiff  161Mb.

None 161Mb

Animation 120Mb

Prores 4444 35Mb

Photojpeg 100% 20Mb

Photojpeg 90% 9Mb

H264 6Mb

Conclusiones de las pruebas:

El codec Animation no sube de gamma. Hace tiempo hice una prueba en la que pensé que “Animation” subía de gamma pero creo que fue debido a un error mío. Después de estas pruebas confirmo que ni Animation ni None suben de gamma el render final.

Para grafismo la secuencia de tiff, animation y none son los mejores con diferencia. Solo hay que ver la forma de onda. La forma de onda en animation y tiff es más limpia que en none. Animation es una buena opción ya que pesa un poco menos y la calidad es casi la misma.

Pensaba que el codec prores 4444 serviría para hacer masters (versión en alta) de trabajos pero viendo su forma de onda creo que es preferible gastar más en disco duro y usar codecs más pesados como el none o animation. La diferencia de 120Mb a 35Mb es por algo. Esto se nota sobre todo en material gráfico, banding y color… en imagen real creo que sería más imperceptible. La calidad de emisión en TV con el prores HQ va que chuta, luego todo lo que le supere… bienvenido sea…

Por otro lado es un lujo disponer de un codec prores 4444 que te da tanta calidad pesando tan poco.

Mi gozo en un pozo: Siempre pensé que el codec photojpeg era muy bueno para grafismo y motion graphics. Era el típico codec que usas cuando necesitas enviar un master en alta pero que no ocupe mucho. Vamos, la típica emergencia. El photojpeg de 90% pesa 9Mb frente a 120Mb del animation. Algunos colegas de trabajo me decían que este codec al 90% se comportaba muy bien pero viendo la forma de onda y los test… deja mucho que desear, incluso el 100%. De todas formas, si tengo que comprimir un vídeo y conservar calidad como si fuera un master… tal vez este sea mi codec.

Ojo que photojpeg al 100% es 4:4:4 y al 90% es 4:2:2. No soporta alfa al 100% como animation , tiff o none pero la diferencia de peso lo hace tentador…

En cuanto al H264 tiene un comportamiento parecido al photojpeg, dependiendo del bitrate, aunque en trabajos gráficos me quedo con photojpeg. Nunca usaría un h264 como versión en alta de un trabajo.  Como todos sabéis, es útil para web, envíos por mail, etc… Esos sí, prefiero hacer H264 en .m4v que en .mov. Un H264 con el mismo bitrate en .mov se ve peor que en .m4v

OneRiver Media tiene un estudio y comparativa de codecs muy completo aquí. Aunque tiene unos años es muy útil.

Veamos imágenes:

Sobre todo podemos distinguir entre la diferencia de calidad del grupo de los animation,tiff , none y el prores 444. Y luego la otra GRAN diferencia entre la segunda categoría que son los photojpeg y H264

Animation:


animation_v animation_rgbparade animation

None:

none none_rgbparade none_v

Tiff:

tiff_rgbparade tiff_v tiff

Pores 4444

prores44444_v prores4444_rgbparade prores4444

Photojpeg 100%

photojpeg100 photojpeg100_rgbparade photojpeg100_v

Photojpeg 90%

photojpeg90 photojpeg90_rgbparade photojpeg90_v

H264

h264_v h264_rgbparade