Visualizador de estructura de GOP

Visualiza y analiza los patrones de GOP (Group of Pictures) en la codificación de video. Ajusta el tamaño de GOP, los fotogramas B y la velocidad de fotogramas para ver los compromisos de eficiencia de compresión y latencia de búsqueda.

Ejemplo resuelto — Visualizador de estructura de GOP

Tamaño de GOP	12 fotogramas

Estos son los valores que muestra la calculadora al abrir la página. Cambia cualquier entrada de arriba para recalcularlos.

Cargando simulación interactiva...

Una longitud de GOP no significa nada hasta que la divides por la tasa de fotogramas 🖖

La lectura de búsqueda es la cifra que importa, porque es lo que un reproductor espera antes de poder mostrar algo tras un salto o un cambio de canal. streaming usa 24 fotogramas a 30 fps, o sea 800 ms. bluray usa 48 a 24 fps: el doble de fotogramas, pero 2000 ms, dos veces y media la espera, porque una tasa más baja estira la misma GOP más en el tiempo. allIntra pone la GOP en 1 y convierte cada fotograma en fotograma clave: buscar cuesta entonces un solo fotograma, 33 ms, y se paga con tasa de bits en cada fotograma que envíes.

Por qué al arrastrar el vídeo a veces salta 🖖

Un vídeo rara vez guarda cada fotograma completo. Solo los fotogramas I (keyframes) contienen una imagen completa; los fotogramas P y B solo describen lo que cambió respecto a los fotogramas vecinos. Un GOP es el tramo que va de un keyframe al siguiente. Al arrastrar la barra de reproducción, el reproductor solo puede reiniciar la decodificación en el keyframe anterior y reconstruir hacia adelante hasta tu objetivo, así que un GOP largo ahorra espacio pero hace la búsqueda más lenta y menos precisa.

Datamoshing: arte a partir de keyframes rotos 🖖

Como los fotogramas P solo llevan movimiento y no el contenido real, los videoartistas borran a propósito los fotogramas I para que el decodificador siga arrastrando píxeles antiguos a lo largo de los nuevos vectores de movimiento. Así surge el aspecto derretido y difuminado del «datamosh» visto en videoclips como Welcome to Heartbreak (2009) de Kanye West y Evident Utensil de Chairlift. La misma corrupción que arruina un stream con un keyframe perdido se convierte en una estética deliberada.

UNA ETAPA DE UNA CADENA: QUÉ LLEGA, QUÉ SALE Y QUÉ SE ROMPE DESPUÉS

Dónde encaja esto en la tubería de codificación

Un codificador de vídeo no es un algoritmo, sino ocho etapas en un orden fijo, y el orden no es arbitrario: cada etapa existe porque la anterior hizo posible su trabajo. Esta herramienta modela una de ellas. La cadena de abajo enlaza con las otras siete.

Visualizador de estructura de GOP — decide qué fotogramas se codifican solos y cuáles como diferencias

Qué llega: Una tira de fotogramas muestreados, ninguno codificado todavía.
Qué sale: Una asignación: fotogramas I codificados solos, y P y B codificados contra fotogramas de referencia.
Qué supone la etapa siguiente: La estimación de movimiento se ejecuta solo en fotogramas P y B. Un fotograma I la salta por completo.
Qué se estropea aquí: Esta etapa decide si la siguiente se ejecuta siquiera para un fotograma dado, así que controla la etapa 04 en lugar de solo precederla. Los huecos largos entre fotogramas I comprimen mucho mejor y empeoran la búsqueda, porque el reproductor debe decodificar hacia delante desde el último fotograma I para llegar a cualquier punto.

Etapa anterior: Submuestreo de croma Etapa siguiente: Estimación de movimiento

Problema resuelto al detalle

Mezcla de fotogramas y tamaño medio de fotograma para 48 fotogramas a 24 fps 6 pasos
Un grupo de imágenes (GOP) al estilo Blu-ray: 48 fotogramas, 3 fotogramas B consecutivos entre referencias, reproducido a 24 fps. Suponga que un fotograma I cuesta 100 unidades relativas, un fotograma P 12 y un fotograma B 6. Calcule la combinación de fotogramas y el tamaño medio por fotograma, y determine cuánta compresión adicional podría aportar un GOP más largo.
1. Un fotograma I abre el grupo, lo que deja 47 huecos. Esos huecos repiten una unidad de 4 fotogramas (3 fotogramas B y el fotograma P que los ancla) y 47 no es múltiplo de 4. 47 = 11 × 4 + 3, por lo que hay 11 unidades completas y un resto de 3 fotogramas B al final.
  
  $N_{GOP} - 1 = 47, 47 = 11 \times 4 + 3$
2. Eso da 11 fotogramas P y 33 + 3 = 36 fotogramas B. Comprobación: 1 + 11 + 36 = 48.
  
  $N_{P} = 11, N_{B} = 11 \times 3 + 3 = 36, 1 + 11 + 36 = 48$
3. Pondere cada tipo según su coste. 100 + 132 + 216 = 448 unidades para todo el grupo, y 448 / 48 = 9,3 por fotograma. Un flujo compuesto exclusivamente por fotogramas intra paga 100 por cada fotograma, de modo que esta estructura es 10,7 veces más pequeña para las mismas 48 imágenes.
  
  $\overset{ˉ}{S} = \frac{1 \times 100 + 11 \times 12 + 36 \times 6}{48} = \frac{448}{48} = 9.3$
4. El precio a pagar por ello se presenta en forma de latencia. No se puede iniciar la decodificación en mitad de un grupo (cada fotograma P y B está definido de forma relativa a otra referencia), por lo que la búsqueda sitúa la reproducción en el fotograma I y se decodifica hacia adelante a partir de ahí. El peor caso son los 48 fotogramas completos, que a 24 fps suponen 2 s.
  
  $T_{seek} \leq \frac{N _{GOP}}{f} = \frac{48}{24} = 2 s = 2000 ms$
5. Calculemos ahora el límite inferior. Cada unidad repetitiva cuesta 3 × 6 + 12 = 30 unidades para 4 fotogramas, o 7,5 por fotograma, y alargar el GOP únicamente añade más de estas unidades. Restando esa tasa al grupo, quedan 448 - 7,5 × 48 = 88 unidades sobrantes.
  
  $\frac{3 \times 6 + 12}{4} = 7.5, 448 - 7.5 \times 48 = 88 = 100 - 12$
6. Esas 88 unidades son una sola cantidad: 100 - 12, el sobrecoste del fotograma I respecto al fotograma P al que sustituye. Este sobrecoste no crece con el grupo, por lo que sigue siendo 88 independientemente de la longitud, y la media es S̄ = 7,5 + 88/N. Comprobándolo con el doble de longitud: N = 96 da 7,5 + 88/96 = 8,4 unidades por fotograma.
  
  $\overset{ˉ}{S} = 7.5 + \frac{88}{N} ⟹ N = 96 : 7.5 + \frac{88}{96} = 8.4, T_{seek} = 4 s$
Respuesta

9,3 unidades por fotograma, frente a un límite inferior de 7,5 del que ninguna longitud de GOP puede bajar. Las dos partes del compromiso escalan en direcciones opuestas y ninguna es lineal en la forma en que lo parece: lo que aún queda por ganar disminuye como 88/N mientras que la latencia de búsqueda aumenta como N/24. Con 48 fotogramas se está 1,8 unidades por encima del mínimo. Duplicar a 96 recupera 0,9 de eso (menos del 10 % del tamaño del fotograma) a costa de otros 2 s de latencia de búsqueda en el peor de los casos. Volver a duplicar recupera 0,46 y cuesta otros 4 s. De modo que la longitud de GOP conveniente queda fijada por la latencia que se esté dispuesto a aceptar, no por la compresión que se continúe persiguiendo: más allá de unas pocas docenas de fotogramas, un fotograma I amortizado un poco más es todo lo que queda disponible.

$\overset{ˉ}{S} - 7.5 = \frac{88}{N} \propto N^{- 1}, T_{seek} = \frac{N}{f} \propto N$

Referencias (1)

Where I, P and B pictures and the GOP structure are specified: ITU-T Recommendation H.264, Advanced video coding for generic audiovisual services.

Por el equipo de 42Math · Actualizado 2026-05-24

Contrastado con fuentes publicadas. Se agradecen correcciones. Política editorial · Correcciones

Todas las lecciones de Informática →

Problemas de ejemplo

Baja latencia (IP) - GOP=4, sin fotogramas B: máxima velocidad de búsqueda, compresión mínima; común en transmisión en tiempo real
Transmisión web (IBBP) - GOP=24, 2 fotogramas B: ~800 ms de latencia de búsqueda, buena compresión; típico en streaming VOD
Blu-ray (IBBBP) - GOP=48, 3 fotogramas B: ~2 s de latencia de búsqueda, mejor compresión; estándar en Blu-ray
All-Intra (solo I) - Todo intra: cada fotograma es un fotograma I; máxima calidad, 5–10× más grande que una transmisión con fotogramas B