Romper el video
para entender la máquina

Concepto Capas de abstracción, encapsulamiento

ffprobe -hide_banner clip.mp4

# Cambiar de contenedor sin tocar los píxeles
ffmpeg -i clip.mp4 -c copy clip.mkv

Esa segunda operación tarda menos de un segundo y no pierde absolutamente nada de calidad. Comparala con una recodificación real y que alguien explique por qué la diferencia es de dos órdenes de magnitud.

Hay tres contratos apilados y uno solo contiene imágenes:

1. Contenedor (mp4, mkv, avi): quién va primero, dónde está cada pista, cuánto dura. Es un índice.
2. Códec (h264, mpeg4, av1): cómo se comprimieron los píxeles.
3. Bitstream: los bytes concretos que el decodificador va a leer.

El momento Renombrar .mp4 a .mkv rompe el archivo; remuxear no. Probá las dos cosas. "Formato de archivo" no es una cosa: son al menos tres contratos independientes, y confundirlos es el 80% de los problemas de video que alguien va a googlear en su vida.

Concepto Representación de datos, framing, registros de tamaño fijo

ffmpeg -f rawvideo -pix_fmt gray -s 128x128 -r 12 \
       -i /usr/lib/x86_64-linux-gnu/libavcodec.so.60 \
       -frames:v 42 -r 12 -c:v libx264 -crf 34 -pix_fmt yuv420p \
       -vf "scale=480:-2:flags=neighbor" binario.mp4

ffplay binario.mp4

Elegimos la biblioteca y no el ejecutable /usr/bin/ffmpeg por una razón que vale la pena contar en clase: ese ejecutable pesa 342 KB porque está enlazado dinámicamente, o sea 5 fotogramas y se termina. El código de verdad vive en libavcodec, 15,8 MB. Enlazado dinámico, explicado sin una sola diapositiva.

El comando además tira una advertencia si lo dejás leer hasta el final, y es la parte más valiosa:

[rawvideo] Invalid buffer size, packet size 14808 < expected frame_size 65536

El archivo no se dividía en fotogramas enteros. Un fotograma de 256×256 en escala de grises son exactamente 65.536 bytes y sobraron 14.808. Ahí aparece el problema del framing: cómo sabe un lector dónde termina un registro y empieza el siguiente. Un contenedor de video existe, entre otras cosas, para responder esa pregunta que acá tuvimos que contestar a mano.

Después, mirar píxeles como números:

ffmpeg -f lavfi -i "testsrc2=s=640x360:r=25:d=1" \
       -vf "crop=16:10:74:40,datascope=mode=color2" \
       -frames:v 1 datascope.png

Tema de discusión: por qué el video se guarda en YUV y no en RGB, y por qué el croma se submuestrea. La respuesta no es informática, es biológica — el ojo humano tiene mucho menos resolución para color que para luminancia, así que el formato tira información que no vas a poder ver. Es la primera aparición de una idea que gobierna todo el resto del taller.

El momento No existe "el archivo de imagen". Existen bytes y un acuerdo sobre cómo interpretarlos. Cambiás el acuerdo y los mismos bytes son otra cosa.

Concepto Tasa–distorsión, con y sin pérdida, teoría de la información

for b in 50k 200k 1000k; do
  ffmpeg -y -i clip.mp4 -c:v libx264 -b:v $b -pix_fmt yuv420p q_$b.mp4
  ffmpeg -i q_$b.mp4 -i clip.mp4 -lavfi psnr -f null - 2>&1 | grep average
done

Resultado medido sobre un clip de prueba de 3 segundos:

Que cada uno grafique tamaño contra calidad. No es una recta: es una curva logarítmica con rendimientos decrecientes. Multiplicar el tamaño por 16 no multiplicó la calidad por 16. Esa curva tiene nombre — tasa–distorsión — y es la razón por la que ninguna plataforma de streaming te da el máximo bitrate posible.

Después, el experimento que cierra el módulo. Mismo codificador, mismos parámetros, misma duración, misma resolución. Solo cambia el contenido:

# Ruido aleatorio puro
ffmpeg -f lavfi -i "nullsrc=s=640x360:r=25:d=5,geq=random(1)*255:128:128" \
       -c:v libx264 -crf 23 -pix_fmt yuv420p ruido.mp4

# Negro absoluto
ffmpeg -f lavfi -i "color=black:s=640x360:r=25:d=5" \
       -c:v libx264 -crf 23 -pix_fmt yuv420p negro.mp4

ls -l ruido.mp4 negro.mp4

El momento Comprimir es apostar a que los datos son predecibles. El ruido aleatorio es lo único que no se puede comprimir, porque no hay nada que predecir. Y de ahí sale, sin escala intermedia, la respuesta a una pregunta que parece de otra materia: por qué un archivo cifrado no se comprime. Un buen cifrado produce salida indistinguible del ruido. Si tu archivo cifrado se comprimiera, tu cifrado sería malo.

Concepto Redundancia temporal, codificación delta, el GOP como máquina de estados

Hasta acá comprimimos cada imagen por separado. Pero el fotograma 100 de un video se parece muchísimo al 99. Ahí hay otra apuesta para hacer.

# Ver el tipo de cada fotograma
ffprobe -select_streams v -show_entries frame=pict_type -of csv=p=0 clip.mp4 | tr -d '\n'

IPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP...

Ahora la medición. Mismo material, misma calidad, única diferencia: cada cuántos fotogramas insertamos una imagen completa.

# -g 1: cada fotograma es independiente
ffmpeg -y -f lavfi -i "testsrc2=s=640x360:r=25:d=5" -c:v mpeg4 -g 1   -bf 0 gop1.avi

# -g 250: un fotograma completo y 249 diferencias
ffmpeg -y -f lavfi -i "testsrc2=s=640x360:r=25:d=5" -c:v mpeg4 -g 250 -bf 0 gop250.avi

ls -l gop1.avi gop250.avi

Qué es cada letra:

• I (intra) — una imagen completa. Se decodifica sola, sin depender de nada. Es un punto de entrada.
• P (predicho) — no contiene una imagen. Contiene instrucciones: "tomá estos bloques de 16×16 del fotograma anterior, movelos a estas coordenadas, y sumales esta corrección chica". Guarda movimiento, no imagen.
• B (bidireccional) — igual que P pero puede referirse al pasado y al futuro. Sí: para decodificarlo hay que haber decodificado un fotograma que todavía no se mostró.

El momento El decodificador es una máquina de estados. Cada fotograma P es una transición que asume que el estado anterior es correcto. Nadie verifica esa suposición: verificarla costaría exactamente lo mismo que no comprimir. Toda la eficiencia del video moderno se apoya en una suposición no verificada. Guardá esa frase, porque el módulo que sigue es lo que pasa cuando la suposición es falsa.

Concepto DAG, dataflow, pipelines

ffmpeg -i clip.mp4 -filter_complex "\
  [0:v]split=2[base][fx]; \
  [fx]hue=s=0,edgedetect,negate[ghost]; \
  [base][ghost]blend=all_mode=difference[out]" \
  -map "[out]" -c:v libx264 -crf 20 -pix_fmt yuv420p grafo.mp4

Que alguien nombre en voz alta lo que está viendo, porque la respuesta es un concepto que ya conoce con otro nombre:

• split es una bifurcación (fan-out)
• blend es una unión (join)
• Las etiquetas [base], [fx], [ghost] son aristas
• El conjunto es un grafo dirigido acíclico, ordenado topológicamente y evaluado fotograma por fotograma

Es la misma forma que un sistema de build, un job de Spark, un árbol de render de React o un pipeline de CI. Distinto dominio, misma estructura de datos.

Después, la comparación que cierra:

# Un proceso, un grafo interno
ffmpeg -i clip.mp4 -vf "hue=s=0,edgedetect" -f null -

# Dos procesos, un pipe del sistema operativo
ffmpeg -i clip.mp4 -vf "hue=s=0" -f nut - | ffmpeg -i - -vf edgedetect -f null -

El momento Semántica idéntica, planificador distinto, y consumo de memoria medible y distinto. La diferencia entre esas dos líneas es la diferencia entre un runtime que administra el flujo de datos y el sistema operativo haciéndolo por vos. Es la misma pregunta que resuelven Airflow, make y las tuberías de Unix.

Concepto Cierre y evaluación

Cada persona exporta 10 segundos y los proyectamos todos seguidos. Antes de que se reproduzca el suyo, dice una sola frase: qué suposición viola su clip.

Esa frase es toda la evaluación del taller. Si puede decirla, entendió una máquina de estados, propagación de errores y compresión con pérdida. Si no puede, el clip queda igual de lindo — pero volvemos 20 minutos al módulo 3.

ffmpeg -y -i final.mp4 -t 10 -c:v libx264 -crf 20 -pix_fmt yuv420p \
       -vf "scale=1280:-2" entrega.mp4

El momento El que aparece cuando alguien mira el clip de otro y dice, sin que se lo pidan, "ah, a ese le sacaste los keyframes del segundo clip". Ahí dejaron de ver un efecto y empezaron a ver un mecanismo.