Lihat dulu di mana videonya rusak, baru perbaiki

Yang sebenarnya diperiksa halaman ini

Di dalam MP4 atau MOV, setiap frame H.264 atau HEVC disimpan sebagai rantai: sebuah angka panjang, lalu sebanyak itu byte data gambar, lalu angka panjang berikutnya, dan seterusnya sampai data frame itu habis. Rantai itu harus berakhir tepat di ujungnya. Kalau ada panjang yang bernilai nol, atau menunjuk melewati batas datanya, byte frame itu bukan seperti yang diklaim file-nya.

Hanya itulah yang diukur halaman ini, frame demi frame, untuk seluruh file. Itu juga sebabnya ia bisa memberi tahu **di mana** kerusakannya, bukan cuma bahwa videonya tidak mau diputar: setiap frame yang rusak punya posisi dan penanda waktu, sehingga kerusakannya bisa digambar di garis waktu.

Kalau Anda pernah menjalankan video rusak lewat ffmpeg dan melihat `Invalid NAL unit size (0 > 1241)` berlarian di layar, itu kondisi yang sama yang dilaporkan. Pemutar biasanya menanggapinya dengan tersendat, melompat, atau menampilkan kotak-kotak berantakan — karena hanya itu yang bisa dilakukan terhadap byte yang tidak ada.

Pemeriksaan ini tidak butuh dekoder video, itulah kenapa ia tetap bekerja pada file yang browser Anda sendiri tidak bisa memutarnya. Yang dibaca adalah byte, bukan gambar.

Dua jenis kerusakan, dan bentuknya berbeda

**Frame yang datanya rusak.** Ada sesuatu yang menuliskan byte yang salah — penyalinan ke flash disk yang terputus, kartu memori yang mulai bermasalah, sinkronisasi yang mati di tengah jalan. Panjang dan indeks file-nya utuh dan videonya terbuka normal, tapi sebagian frame di dalamnya tidak bisa dipakai. Di garis waktu, ini tampak sebagai tanda-tanda yang tersebar di tempat kerusakannya terjadi.

**Video yang terputus di tengah.** Pengunduhan atau pemindahan berhenti lebih awal. Header-nya masih mengklaim durasi aslinya, jadi pemutar menampilkan bilah geser sepanjang penuh, tapi data gambarnya begitu saja berhenti di tengah. Halaman ini mendeteksinya dengan membandingkan durasi yang diklaim file dengan frame terakhir yang benar-benar bisa dijangkau — di garis waktu bentuknya satu blok kelabu di bagian akhir.

Keduanya perlu dibedakan karena harapannya berbeda. Kerusakan yang tersebar biasanya hanya memakan satu detik di sini dan satu detik di sana. Sementara file yang terputus di titik 40% kehilangan 60% videonya, dan tidak ada alat yang bisa mengarang sesuatu yang memang belum pernah ditulis.

Kenapa file hasil perbaikan jadi lebih pendek

Frame video tidak berdiri sendiri-sendiri. Sebuah keyframe utuh dengan sendirinya, tapi frame-frame sesudahnya disimpan sebagai selisih terhadapnya — jadi kalau data sebuah keyframe rusak, semua frame yang bersandar padanya juga tidak bisa dipakai, meski byte mereka sendiri sempurna. Itu sebabnya file dengan sepuluh frame rusak bisa kehilangan jauh lebih dari sepuluh.

Perbaikan hanya menyimpan frame yang benar-benar bisa didekode, lalu menutup jeda-jedanya supaya hasilnya diputar utuh dari awal ke akhir alih-alih membeku di titik kerusakan. Imbalannya, hasilnya lebih pendek dari aslinya sebanyak yang dibuang. Halaman ini menyebutkan angka itu sebelum Anda memutuskan, dan menyebutnya lagi di hasilnya.

Tidak ada penyandian ulang. Frame yang selamat disalin byte per byte, jadi kualitas gambar dari yang tersisa persis sama dengan aslinya — dan keseluruhannya selesai dalam hitungan detik, bukan menit.

**Suaranya dipertahankan, dan tetap sinkron.** Menutup jeda berarti gambarnya tidak lagi cocok dengan suara yang panjangnya masih asli, jadi audionya dipotong mengikuti batas yang sama persis — setiap bagian gambar yang disimpan membawa bagian suaranya sendiri, digeser sebanyak yang sama. Di dalam satu bagian keduanya terpaut mati; hanya di sambungan antar-bagian audionya bisa bergeser, dan tidak akan lebih dari setengah paket audio, yaitu sekitar sepuluh milidetik. Itu satu tingkat besaran di bawah apa yang bisa dirasakan siapa pun sebagai suara yang tidak sinkron.

Yang tidak bisa dilakukan halaman ini

**File yang sama sekali tidak mau terbuka berada di luar jangkauan.** Setiap MP4 membawa indeks yang menjelaskan letak tiap frame. Kalau indeks itu rusak atau hilang — hal yang biasa terjadi saat perekaman berhenti tanpa ditutup dengan benar — tidak ada peta untuk disusuri, dan halaman ini akan mengatakannya alih-alih berputar-putar. Memulihkan file semacam itu butuh sumber aslinya, atau alat yang membangun ulang indeksnya dengan menebak-nebak batas antar-frame.

**Kerusakan audio tidak terdeteksi.** Trek suara dibawa serta dan dijaga tetap sinkron, tapi ia tidak pernah *diperiksa* — menemukan paket audio yang rusak berarti menjalankannya lewat dekoder, pekerjaan yang berbeda dan jauh lebih lambat daripada membaca prefiks panjang. Video yang gambarnya sempurna tapi suaranya rusak akan keluar dari pemindaian ini dengan status bersih.

**Hanya H.264 dan HEVC.** Itulah codec yang menyimpan frame dengan prefiks panjang, dan itu yang dibaca pemeriksaan ini. MJPEG, MPEG-4 Part 2 dan lainnya menyusun frame secara berbeda — diukur dengan penggaris ini, semuanya akan tampak rusak, jadi halaman ini memilih menolak.

FAQ