Mac Pro vs PC

 

Acabo de ver esta comparativa entre Mac Pro y HP Z840… sin comentarios. Los Benchmarks son incontestables. Como Apple no se ponga las pilas pronto, el mercado pro de la producción audiovisual se les va a la… competencia. Yo me incluyo.

Los últimos Mac Pros son del 2013. Dicen las malas lenguas que algunos procesos en vídeo son más rápidos con el Mac book pro.

De todas formas, hace tiempo que Apple perdió el interes por el sector profesional del vídeo.

The Pixellab es uno de los últimos estudios que han dado el salto al lado oscuro. Aquí nos lo cuentan.

 

Anuncios

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.

 

Linux y El Capitan

Cómo conseguir que nuestro Mac, recién actualizado a Yosemite o El Capitan, pueda darnos a elegir en el arranque varios sistemas operativos, en mi caso El Capitan, Debian y CentOs.

Por un lado tengo cada sistema operativo en un disco duro interno. Podría usar particiones en uno pero prefiero que cada distro Linux esté en un disco distinto.

Desde Mac descargamos rEFInd Boot Manager. Aquí hablan de cómo instalarlo en Yosemite.

Una vez descargado el A binary zip file, lo descomprimimos en el escritorio.

El problema es que Yosemite y El Capitan tienen activado el SPI (Sistema de Protección de Integridad)

Aquí explican como desactivarlo. Es sencillo. Hay que arrancar el Mac en modo recuperación, abrir el Terminal y escribir csrutil disable; reboot

Una vez reiniciado, vamos a la carpeta descargada y descomprimida que tenemos en el escritorio, en mi caso “refind-bin-0.10.0” Ejecutamos el archivo refind-install y se ejecutará un script que desde el Terminal instalará rEFInd.

Reiniciamos y aparecerá algo como esto. Sencillo.

IMG-20151121-WA0000

Pruebas con FFMPEG en Mac

ffmpeg

Quería compartir y comentar unas pruebas que he realizado con ffmpeg.

En realidad, lo hago para tener un documento que agrupe lo que he aprendido de FFMPEG y para que me sirva cuando todo esto se me olvide (posiblemente mañana).

Una de las cosas que más me interesaba era encontrar virtudes y aspectos que lo hicieran superior a otras aplicaciones de codificación de vídeo como Adobe Encoder, Compressor, HandBrake o MPEG Streamclip. Buscaba alguna carácterística que lo hiciera diferente al resto ya sea porque escala vídeo a más calidad, porque es más rápido o porque ofrece más calidad por menos peso de archivo. Las aplicaciones con las que comparo FFMPEG son muy buenas. Las he usado, trabajo con ellas a diario y hacen muy bien su trabajo.

compresordescargaencodermpeg

En este post no pretendo enseñar el manejo de FFMPEG ya que hay muchos recursos en la red. Lo que me interesa ahora es fijarme en sus características generales.

La primera gran diferencia es el entorno gráfico. Todas las aplicaciones son sencillas de usar y tienen un entorno gráfico que facilita el manejo. FFMPEG no tiene entorno gráfico y se opera desde el terminal. Por tanto la primera consideración es que es menos práctico y más complejo.

NOTA: Para instalar FFMPEG en Mac hay que instalar XCode y Homebrew. Hay muchas referencias en la red.

CODECS

El primer punto interesante es que admite y trabaja con casi todos los codecs conocidos. Al ser software de código abierto pensé que solo usaría codecs libres como en HandBrake pero en Mac trabaja bien con prores y puede multiplexar en .mov perfectamente.

En el caso de usar FFmpeg en Linux la cosa cambia porque no usa los codecs privativos de Apple y otras marcas. Por ejemplo, para H264 utiliza la librería libx264. Otros codecs de código abierto son mp4, VP8 y Theora

La lista de codecs es muy grande. Para verla:

ffmpeg -codecs

Para ver formatos:

ffmpeg -formats

En HandBrake solo se utilizan los formatos Matrioska .mkv y .mp4 y los codecs h264, h265 VP8 y Theora.

En Mac, FFMPEG puede emplear muchos codecs pero no puede exportar a prores 4444. Solo podremos exportar prores 422, no otros tipos de prores como HQ o 4444.

Lo que sí podemos es usar prores 4444 de entrada y pasarlo a cualquier otro formato o mantenerlo como está.

Ejemplo de paso de cualquier formato a prores:

ffmpeg -i INPUT.avi -c:v prores OUTPUT.mov

Si queremos trabajar en alta calidad en Mac hay muchas posibilidades. He probado hacer archivos .mov en Animation y funciona perfectamente:

ffmpeg -i INPUT -codec:v qtrle -codec:a copy OUTPUT.mov

Otra posibilidad es usar el v408. -c:v v408. Es un codec 444 muy bueno pero muy pesado. Un segundo de vídeo en prores 4444 pesa unos 35Mb, con -c:v qtrle (animation) pesa 133 Mb y con -c:v v408 pesa 215 Mb.

CALIDAD

Hay casos en los que queremos mantener la calidad del vídeo, no procesarlo, y simplemente añadirle un audio. Entonces tendremos que escribir -c:v copy. Con esta instrucción indicamos que el codec de vídeo se mantenga igual. Ej:

ffmpeg -i INPUT.mov -i AUDIO.aif -c:v copy -c:a copy OUTPUT.mov

Si queremos conservar la calidad de un vídeo podemos usar  –qscale 0. Es el sustituto, tal vez, del obsoleto -sameq

-qscale lo he probado con un archivo .mov Animation y he generado un .mpg de bastante calidad y mucho menos peso. Aparentemente parece no haber perdido calidad aunque sabemos que sí. El vídeo de 1s en Animation pesaba 117 Mb y el resultante en mpg es de 6Mb. Con algo más de banding (normal) en el mpg y cierta pérdida de calidad aunque aceptable para la pérdida de peso que supone.

ffmpeg -i INPUT.mov -qscale 0 OUTPUT.mpg

Animation .mov:

test_animation.Still001

.mpg:

test_mpg.Still001

Otras opciones interesantes relacionadas con la calidad de la imagen y audio:

-hq  Activa los settings high quality

-c:v  -c:a o -codec:v -codec:a Dos formas de forzar el codec que utilizará de salida.

-pix_fmt Formato del pixel. Introduciendo este código podemos ver listado de opciones: ffmpeg -pix_fmts

Si trabajamos en Mac con FFMPEG es importante incluir en las conversiones que hagamos a H264, la opción -pix_fmt yuv420p ya que eso nos permite que el vídeo resultante se pueda ver en Quick Time sin problemas. Si no hacemos esto solo lo podremos ver en VLC. Como dicen por ahí: “…make sure the pixel format is compatible with dumb players”

-qp 0 Máxima calidad. En mis pruebas va de 0 a 70, a partir de 70 no comprime más. Se usa como opción lossless

-b:v o -b:a Bit rate para vídeo y audio. Tasa de bits o tasa de transferencia.

Para H264 podemos codificar en CBR o VBR (bit rate o tasa de bits constante o variable) para ello usamos -crf  en constante o -pass 1 y -pass 2 si queremos hacer la codificación de dos pasadas en bit rate variable.

La diferencia entre constante o variable es que con VBR se optimiza más la compresión a base de comparar los cambios en la película y lo hace en uno o dos pases (mejor 2), por lo tanto, conseguimos la misma calidad con menos peso. Si no nos importa lo que ocupe el archivo usaremos CBR.

Ojo a lo que dicen los de Adobe:

“Al comparar archivos CBR y VBR del mismo contenido y del mismo tamaño, puede hacer las siguientes generalizaciones: Un archivo CBR se puede reproducir con más fiabilidad en una gama de sistemas más amplia porque la velocidad de datos fija exige menos del reproductor de medios y el procesador del equipo. Sin embargo, un archivo VBR suele tener una calidad de imagen superior porque VBR se adapta la cantidad de compresión al contenido de la imagen”

Con ambos métodos y teniendo settings similares, podemos conseguir la misma calidad. Sabemos que en VBR pesará menos, luego, a dos archivos que pesen igual, uno en CBR y otro en VBR, el de VBR tendrá más calidad.

Ejemplo usando tasa de transferencia constante.

ffmpeg -i INPUT.mov -c:v libx264 -crf 28 OUTPUT.mp4

La tasa de bits variable también es llamada ABR (Average bit rate)

Ejemplo sencillo de tasa de bits variable:

ffmpeg -i INPUT.mov -c:v libx264 -b:v 1000k OUTPUT.mp4

Con tasa mínima y máxima:

ffmpeg -i INPUT.mov -c:v libx264 -b:v 4000k -minrate 1000k -maxrate 4000k -bufsize 1835k out.mp4

Para codificar con tasa de bits constante en libx264 usaremos -crf de 0 a 51 siendo 0 la más alta calidad (lossless) y 51 la más baja. Normalmente se recomienda de 18 a 28. Si usamos -pix_fmt yuv420p no podremos usar -crf 0, tendremos que usar a partir de 1.

Para hacernos a la idea de tamaños, un vídeo de 1s con -cbf 18 pesa 2.2Mb, con -cbf 1 pesa 17Mb, con -cbf 28 pesa 896kb. 20s de vídeo con -cbf 18 son 61Mb, con -cbf 28 son 15Mb, con -cbf 40 son 4.2Mb.

Para comparar, en ffmpeg, un -cbf de 38-37 equivale en el Adobe Encoder a un CBR de 2Mbps.

En la red hay muchos ejemplos de codificación en h264 en tasa de bits constante y variable.

COMPRESIÓN DEL ARCHIVO/VELOCIDAD

Como he ido descubriendo, FFMPEG tiene muchísimas posibilidades y opciones.

Para optimizar la compresión de un vídeo existen presets que nos facilitan bastante el trabajo.

Los presets marcan la velocidad de codificación. Cuanto más lento, más y mejor comprime; el archivo será menos pesado. No afecta a la calidad. Tipos: ultrafast, superfast, veryfast, faster, fast, medium (the default), slow, slower, veryslow. Por tanto un ultrafast tendrá la misma calidad pero pesará más que un veryslow.

Ejemplo de un lossless en H264 multiplexado en Matrioska y preset rápido (pesará más):

ffmpeg -i INPUT.mov -c:v libx264 -preset ultrafast -qp 0 OUTPUT.mkv

Ejemplo de un lossless en H264 multiplexado en Matrioska y preset lento (pesará menos):

ffmpeg -i INPUT.mov -c:v libx264 -preset veryslow -qp 0 OUTPUT.mkv

Compruebo que FFMPEG es bastante rápido al codificar vídeo y audio. En términos generales creo que supera al Encoder, por lo menos en H264.

Ya que hablo de rapidez quiero comentar que me ha asombrado la velocidad con la que codifica FCPX en H264. Sin duda, creo que es el más rápido. Ni Premiere ni Encoder lo superan en esto.

FILTROS

Otro campo que conviene investigar son los filtros. Con ffmpeg -filters podremos ver el listado de filtros. Existe bastante documentación sobre el tema.

Esta es la lista de filtros que considero más interesantes:

Filters:
  T.. = Timeline support
  .S. = Slice threading
  ..C = Command support
  A = Audio input/output
  V = Video input/output
  N = Dynamic number and/or type of input/output
  | = Source or sink filter
 …       copy                 V->V       Copy the input video unchanged to the output.
 …       null                  V->V       Pass the source unchanged to the output.
 …      nullsink            V->|         Do absolutely nothing with the input video.
 …      concat           N->N       Concatenate audio and video streams.
 TS.     dctdnoiz           V->V       Denoise frames using 2D DCT.
 TS.     noise               V->V       Add noise.
 T..      hqdn3d            V->V       Apply a High Quality 3D Denoiser.
 T..     owdenoise       V->V       Denoise using wavelets.
 …       compand          A->A       Compress or expand audio dynamic range.
 T..      codecview        V->V       Visualize information about some codecs
 …       dejudder           V->V       Remove judder produced by pullup.
 …       deshake           V->V       Stabilize shaky video.
 …       field                  V->V       Extract a field from the input video.
 …       format              V->V       Convert the input video to one of the specified pixel formats.
 T..      gradfun            V->V       Debands video quickly using gradients.
 T..       il                     V->V       Deinterleave or interleave fields.
 …       interlace          V->V       Convert progressive video into interlaced.
 …       kerndeint         V->V       Apply kernel deinterlacing to the input.
 …       mcdeint           V->V       Apply motion compensating deinterlacing.
 T..     w3fdif               V->V       Apply Martin Weston three field deinterlace.
 TS.    yadif                 V->V       Deinterlace the input image.
 …       mpdecimate    V->V       Remove near-duplicate frames.
 …      palettegen        V->V       Find the optimal palette for a given stream.
 …      paletteuse        VV->V      Use a palette to downsample an input video stream.
 …      pixdesctest      V->V       Test pixel format definitions.
 …      split                  V->N       Pass on the input to N video outputs.
 …      scale                V->V       Scale the input video size and/or convert the image format.
 …      super2xsai       V->V       Scale the input by 2x using the Super2xSaI pixel art algorithm.
 .S.     xbr                   V->V       Scale the input using xBR algorithm.
 .S.      hqx                  V->V       Scale the input by 2, 3 or 4 using the hq*x magnification algorithm.
 .S.     signalstats       V->V       Generate statistics from video analysis.
 …      mandelbrot       |->V       Render a Mandelbrot fractal.
 …      mptestsrc         |->V       Generate various test pattern.
 …      smptehdbars    |->V       Generate SMPTE HD color bars.
 …      testsrc              |->V       Generate test pattern.
 …      avectorscope   A->V       Convert input audio to vectorscope video output.
 …      showcqt           A->V       Convert input audio to a CQT (Constant Q Transform) spectrum video output.
 …      showspectrum   A->V       Convert input audio to a spectrum video output.
Como se puede ver con los filtros tenemos muchas posibilidades. Estabilizar vídeo, añadir ruido, generar vectorscopios…
He probado los filtros de escalado para comprobar si alguna de las opciones utiliza un algoritmo milagroso que consigue ampliar la imagen sin pérdida alguna. He realizado la prueba con un vídeo pal ampliando a 2k. Lo he escalado con Adobe Encoder, con Mpeg Streamclip y con 4 métodos de escalado de FFMPEG. Ninguno es milagroso. Todos dan un resultado similar, incluido el Encoder. El único que destaca un poco es el procesado con Mpeg Streamclip porque parece que gana más de nitidez añadiendo algo de sharpen, pero es el que más rompe los colores. Por tanto no hay milagro. Aunque FFMPEG tiene un mínimo de 4 métodos de escalado, ninguno supera a Encoder.
Original en Pal
pal
Escalado con Encoder
encoder
Escalado con Mpeg Streamclip
mpegstreamclip
Escalado con FFMPEG scale
ff scale
Escalado con FFMPEG super2xsai
ff super2xsai
Escalado con FFMPEG xbr
ff xbr
Escalado con FFMPEG hqx
ff hqx
OTRAS OPCIONES
Al ser un programa abierto, las posibilidades son ilimitadas.
Podemos añadir pista de subtítulos, generar vídeo sin audio, hacerlo a partir de secuencia de imágenes, generar frames negros al comienzo de vídeo o al final, insertar textos, insertar un código de tiempo, rotar, escalar, cambiar aspecto, cropear, unir varios clips, separar las pistas de vídeo y audio…

PARA ACABAR YA DE UNA VEZ…

FFMPEG tiene muchas posibilidades. Podemos tener un control total en el proceso de codificación.

Calidad del vídeo de salida. No he encontrado diferencias en calidad de imagen con otras aplicaciones de codificación de vídeo. Utilizando bien los parámetros del Encoder podemos conseguir la misma calidad de vídeo que con FFMPEG. Posiblemente encontremos alguna diferencia en cuanto a velocidad de codificación entre las distintas aplicaciones pero dependerá de los parámetros que introduzcamos. La única ventaja de FFMPEG en cuanto a calidad es que podemos usar más parámetros para garantizar una calidad óptima.

Para usuarios de Mac que tienen posibilidad de usar Encoder o Compressor, la opción de uso de FFMPEG es incómoda y más lenta en la introducción de parámetros y no por ello consiguen mejores resultados. Aún así, hay funciones de FFMPEG como unir un vídeo y audio o insertar un timecode que se pueden realizar de manera más rápida y eficaz con FFMPEG.

Un aspecto importante para usuarios de Mac: FFMPEG es de código abierto y libre, por tanto, es accesible y podemos programar scripts en Mac que automaticen ciertas operaciones de FFMPEG. Entonces sí que FFMPEG se puede convertir en una herramienta rápida, cómoda y muy potente.

Si el usuario es de Linux la cosa está clara. FFMPEG es su mejor y más potente herramienta. No conozco ninguna aplicación con entorno gráfico, salvo HandBrake, que ofrezca buenas posibilidades y un buen control de los parámetros de codificación.

Como usuario de Debian y CentOs lo tengo claro.

MOX File format

Una buena noticia. Próxima aparición de un códec open source de vídeo profesional.

Gracias al crowdfunding, el programador Brendan Bolles y su equipo han conseguido desarrollar un códec abierto y compatible con Windows, Mac y Linux.

Mox utilizará el contenedor MXF y codecs open source como Dirac, OpenEXR, DPX, PNG y JPEG.

Esperemos que Adobe, Microsoft y Apple no pongan piedras en las ruedas de Mox…

Debian y CentOs en Mac Pro

Después de muchos intentos… ¡por fin lo consigo!  He instalado en un Mac Pro Early 2008 intel, Debian y CentOs, las dos distros de Linux que quería junto al Mac OS X.

Creo que hoy por hoy, el SO de Mac va muy bien y no necesitaría más… pero de GNU Linux me gusta su filosofía, la rebeldía frente a Microsoft y Apple que imponen sus criterios y, sobre todo, que es una plataforma abierta a todos, gratuita y modificable. Siempre recomiendo este doc emitido en la 2,  viejuno pero vigente hoy día.

La distro Debian porque me gusta bastante más que Ubuntu y tiene una comunidad muy grande. Quiero trastear con él en plan doméstico.

CentOs porque es la mejor distro free de Linux para trabajar con vídeo. Viene de Red Hat y eso es una garantía. Con esta distro me interesa investigar con los códecs de vídeo y comprobar hasta donde puede llegar linux como estación de trabajo “pro” para producción audiovisual.

Mi intención era conseguir que al arrancar el mac me ofrezca elegir cualquiera de los tres sistemas operativos. Instalaría cada SO en un disco interno distinto, nada de particiones con varios SO.

Hay mucho en internet sobre el tema. Aquí uno de los muchos enlaces que consulté.

No voy a colgar un tutorial porque en mi caso la cosa no ha sido muy lógica y porque no tengo mucha experiencia en esto de linux, me considero un novato.

He usado los DVD iso de cada distro de 64 En teoría con instalar Reflt valdría. Esta aplicación hace que mac busque otros SO que estén instalados. Solo me reconocía CentOs. Su Grub parece que se instalaba bien pero en Debian era imposible, por más que le decía que instalara el grub en el disco de Debian, Reflt no lo reconocía.

Llegué a instalar Refind en vez de Reflt. Investigué en todo tipo de foros. Usé el terminal. Al final, al hacer un mix entre el GPT y MBR perdí toda opción de arrancar nada salvo Mac Os porque al elegir una opción distinta a mac me salía este mensaje “Missing operating sistem”

Por una casualidad, me di cuenta que mi única forma de conseguirlo era a lo bruto. Instalando ese sistema como único. El sistema operativo tenía que arrancar por sí solo al arrancar el mac usando solo ese disco, sin empezar enseñando la BIOS primero. Creo que en el fondo es instalarlo como estaba el OsX, con su EFI. Una vez conseguí esto, Reflt ya los reconocía y me dejaba elegir.

Siento no poder dar detalles más concretos pero después de tantas pruebas…

El gran fallo es que Reflt no funcionara bien desde el principio y no detectara los Grub de ambos sistemas, a partir de ahí todo se complicó. Por lo que he leído por ahí, cada modelo de Mac es distinto en sus EFIS o BIOS (si es de antes del 2006) y no se comportan igual según modelo y año.

Siempre los dos grandes han puesto impedimentos para que se puedan instalar otros sistemas operativos libres en sus máquinas y cada vez nos lo complican más.

En el pantallazo que adjunto se pueden ver los símbolos de Mac, Debian y Centos y luego una serie de iconos de windows y linux que los considero heridas de guerra porque no llevan a ningún SO, están muertos y no se como eliminarlos de Reflt. Son antiguos restos de Grubs desaparecidos…

Ahora a trastear con ellos… ¿se podrá usar prores en Centos? ¿DaVinci irá tan bien en CentOs como en mac? ¿podré instalar Google Drive en Debian? ¿conseguiré asignar botón derecho a mi lápiz wacom?

IMG_20140731_190545

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