Recuperación de video desde formatos propietarios con técnicas low-level

En trabajos reales con CCTV y evidencia digital, existen varios problemas al momento de “convertir un archivo a MP4”.

¿Cuáles son esos problemas?

• archivos propietarios que nadie documenta
• exportaciones rotas
• contenedores truncados
• herramientas del fabricante que no abren nada
• y un requisito innegociable: no perder ni un byte de evidencia

En ese contexto, cuando un conversor dice “cannot open file”, la conclusión apresurada suele ser “el video está perdido”.

Pero esto casi nunca es cierto.

La mayoría de las veces no se rompió el video.
Se rompió el contenedor.

El stream comprimido —los frames reales— suele seguir ahí, intacto, mezclado con basura, headers raros o metadata propietaria.

Este artículo describe el enfoque que suele funcionar cuando todo lo demás falla: dejar de pensar en “archivos multimedia” y empezar a mirar bytes crudos.

Bajar de capa.

1. Cambiar el modelo mental: el archivo y el video

Algo que ayuda mucho es separar dos conceptos que normalmente se mezclan.

Un “video” en disco es la fusión de dos cosas:

El contenedor

MP4, MKV, AVI o el formato propietario de turno.

Ahí viven:

• índices
• timestamps
• tablas
• metadata
• multiplexado de pistas

Es la parte “administrativa”. Y también es la parte más frágil.

Si el índice se rompe o falta un header, ningún player puede demuxear.
Aunque los frames estén perfectos.

El stream

Esto es el video real. H.264, H.265, etc.

Una secuencia de bloques comprimidos.

Nada más.

Si esta capa sobrevive, el video es recuperable, aunque el contenedor esté completamente muerto.

Toda la estrategia low-level nace de esta idea simple:

el contenedor puede fallar, el stream muchas veces no.

2. Qué estamos buscando realmente: NAL units

En H.264/H.265 el stream está formado por NAL units.

Son bloques independientes que contienen:

• parámetros (SPS/PPS)
• keyframes
• frames intermedios

Todas empiezan con un patrón muy característico:

00 00 01 o 00 00 00 01

Incluso en un archivo propietario, lleno de basura, esos bytes siguen ahí.

Y cuando los ves repetirse, sabés que hay video.

No necesitás que ningún player te lo confirme.

3. Antes de ffmpeg: mirar los bytes

Una costumbre útil: no empezar con herramientas high-level.

Primero abrir el archivo como binario.

Ver los primeros bytes:

xxd -l 256 archivo.bin

o

hexdump -C archivo.bin | head

Muchas veces ya ves:

• strings como h264 o avc1
• padding raro
• bloques repetidos
• o directamente los start codes

Solo con eso te das cuenta de qué tan “sano” está el archivo.

Después conviene buscar offsets automáticamente:

grep -oba $'\x00\x00\x00\x01' archivo.bin | head

Eso te devuelve posiciones donde podrían empezar NALs.

Si aparecen cientos o miles, casi seguro hay stream válido.

Para archivos grandes y desconocidos, binwalk también ayuda a detectar firmas embebidas.

Nada sofisticado. Solo reconocimiento de patrones.

4. Recortar y quedarse con lo que importa

Un caso típico: el archivo tiene 1–2 MB de headers propietarios antes del video real.

Los players se mueren intentando interpretar eso. La solución no es “otro conversor”. Es recortar.

Algo tan simple como:

dd if=archivo.bin of=stream.h264 bs=1 skip=1048576

Descartás todo lo anterior y te quedás solo con el flujo.

Ahora sí tenés un stream elemental. Mucho más fácil de tratar.

5. Recién ahora: decodificar

Con el stream limpio, recién ahí tiene sentido usar FFmpeg.

Por ejemplo:

ffmpeg -f h264 -i stream.h264 -c copy out.mp4

O para HEVC:

ffmpeg -f hevc -i stream.h265 -c copy out.mp4

Si el stream está medio roto, sumar tolerancia:

-fflags +genpts  
-err_detect ignore_err  
-probesize 100M  
-analyzeduration 100M

La diferencia es grande: ahora ffmpeg no está luchando contra un contenedor inválido. Solo lee frames.

6. Recuperar por partes también es válido

A veces el archivo está parcialmente corrupto. En esos casos conviene extraer segmentos:

dd if=archivo.bin of=segmento.bin bs=1 skip=2000000 count=50000000

Y probar decodificar solo eso.

Muchas veces terminás con varios clips recuperables. Perder un minuto es mejor que perder todo.

7. ¿Por qué fallan herramientas como HandBrake?

Vale la pena entender esto.

HandBrake y FFmpeg funcionan muy bien… mientras el contenedor esté sano.

Su pipeline depende de:

demux → decode → encode → mux

Si el demuxer no puede leer índices o timestamps, aborta. Lo que significa: “no entiendo el contenedor”.

Pero el problema es de metadata, no de datos.

8. El cambio de mentalidad

Cuando varios conversores fallan, insistir con más software rara vez ayuda. Lo que cambia el resultado es cambiar de nivel.

Dejar de pensar: “¿qué programa lo abre?” y empezar a pensar: “¿dónde empiezan los frames?”.

Es una pregunta mucho más fundamental.

Y mucho más confiable.