Repáralo ahora
- Suelta el archivo
- La reparación ocurre en local
- Descarga el resultado
Los teléfonos Android —Pixel, Samsung, Xiaomi, OnePlus y el resto— graban vídeo a través de las APIs MediaRecorder y MediaMuxer de la plataforma, que escriben un .mp4 estándar en el contenedor ISO base-media. La imagen y el sonido se van volcando en una caja mdat a medida que grabas, pero el átomo moov —el índice que mapea cada fotograma— solo se escribe cuando la app llama a MediaMuxer.stop() al final. Si la app nunca llega a esa llamada, te queda un archivo lleno de datos HEVC o H.264 válidos y sin índice, y cualquier reproductor lo rechaza. Suelta el archivo arriba y la herramienta comprueba exactamente eso, en tu navegador, y reconstruye el contenedor cuando el material es recuperable.
Por qué Android deja un .mp4 sin finalizar
La pila multimedia de Android es explícita sobre cuándo una grabación pasa a ser reproducible. Durante la captura, MediaRecorder (o una app de cámara que usa MediaCodec + MediaMuxer directamente) va añadiendo muestras codificadas al mdat. El átomo moov —tamaños de muestra, offsets de fragmentos (chunks), tablas de sincronización y los conjuntos de parámetros del códec— se monta en memoria y se vuelca al final del archivo solo cuando se ejecutan stop() y release(). Si te saltas ese paso, los bytes del disco son un MP4 sin cabeza: fotogramas reales, sin mapa.
Lo provocan tres interrupciones. La app Cámara se colgó o el sistema la cerró. Un fallo, o el "asesino" de bajos recursos de Android (low-memory killer) reclamando una app en segundo o primer plano bajo presión de memoria, termina el proceso antes de stop(), así que nada escribe el índice. El almacenamiento se llenó a mitad de grabación. El 4K en HEVC escribe muy rápido; cuando el almacenamiento interno o la tarjeta SD llega a cero bytes libres, la escritura del muxer falla a medias y el archivo queda truncado sin moov. El teléfono se apagó. Una batería agotada o un reinicio forzado durante la captura se salta la finalización de la misma manera.
El códec de dentro es HEVC/H.265 (el predeterminado para los modos de alta resolución en la mayoría de los Android modernos, elegido por su eficiencia) o H.264/AVC (la alternativa por compatibilidad). El comportamiento del contenedor es idéntico en ambos, y por eso la vía de reparación es la misma sea cual sea el códec.
Qué se puede reconstruir y qué no
Como los datos de los fotogramas sobreviven en el mdat, la solución es reconstruir el índice que MediaMuxer.stop() nunca escribió. La herramienta escanea el flujo que ha sobrevivido, recupera los límites y la sincronización de cada fotograma y rehace las tablas de muestras para que un reproductor pueda decodificar desde el principio, convirtiendo un archivo sin cabeza en un MP4 normal por el que se puede navegar. Cuando el archivo además quedó truncado por un disco lleno, rescata los fotogramas que se escribieron por completo antes del corte y cierra un contenedor reproducible a su alrededor, de modo que un clip que capturó el 80% de una toma devuelve ese 80% en lugar de fallar entero. Todo esto se ejecuta en tu navegador a medida que el archivo se lee del almacenamiento.
El límite honesto es que los fotogramas escritos después de la interrupción no existen: un disco lleno detiene la escritura, un cuelgue detiene el codificador, y ninguna herramienta puede inventar bytes que nunca se almacenaron. Cuando solo queda la copia truncada, rescatarla es lo correcto; pero si el archivo original sigue en el teléfono y basta con volver a copiarlo de forma limpia, hazlo primero, porque una copia buena supera a cualquier reparación.
Por qué ayuda un clip del mismo teléfono y la misma app
Reconstruir el índice es más fiable cuando la herramienta conoce la configuración exacta del códec que el archivo dañado omitió. Un clip en buen estado del mismo teléfono, grabado por la misma app en el mismo modo, aporta justo eso: los conjuntos de parámetros de HEVC (VPS/SPS/PPS) o los SPS/PPS de H.264, además de la resolución y la cadencia de fotogramas, de modo que la reconstrucción reproduce el original en lugar de aproximarlo.
En la práctica: graba unos segundos prescindibles con la misma app de cámara y los mismos ajustes de calidad, y tenlo a mano. Haz que el códec coincida (una referencia HEVC para un clip HEVC, H.264 para H.264) y solo se te pedirá si la reparación lo necesita. Una muestra de otro teléfono o de otra app normalmente no encaja, porque los conjuntos de parámetros son distintos.
Qué puede y qué no puede reparar
Puede reparar
- Una grabación que la app Cámara o una app de vídeo nunca finalizó porque se colgó o el sistema la cerró antes de MediaMuxer.stop() (falta el moov)
- Clips cortados cuando el almacenamiento interno o la tarjeta SD se llenó a mitad de grabación
- Grabaciones interrumpidas por una batería agotada o un reinicio forzado durante la captura
- Archivos .mp4 HEVC y H.264 que no abren en Google Fotos, la Galería, VLC o un editor a pesar de contener fotogramas reales
No puede reparar
- El material posterior a la interrupción: esos fotogramas nunca se escribieron en el almacenamiento
- Un archivo que se lee como 0 bytes o casi todo ceros tras una copia fallida o una tarjeta SD defectuosa
- Contenido protegido con DRM o cifrado
- Un clip HEVC dañado sin una referencia HEVC equivalente del mismo teléfono y la misma app
Si una reparación falla, te decimos por qué (datos que faltan frente a estructura dañada), y nunca se te cobra por una reparación fallida.