search

ponchio / untrunc

Restore a damaged (truncated) mp4, m4v, mov, 3gp video. Provided you have a similar not broken video.
GNU General Public License v2.0
1.62k stars 227 forks source link

Recovering Sony A7R3 Files - Audio Codec is EVIL #146

Open hipur opened 5 years ago

hipur commented 5 years ago

Hi, I'm having the following error:

Composition time offset atom found. Out of order samples possible. Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/mnt/c/Users/purch/Desktop/recover/C0117.MP4': Metadata: major_brand : XAVC minor_version : 16785407 compatible_brands: XAVCmp42iso2 creation_time : 2018-09-19 01:49:35 Duration: 00:00:12.59, start: 0.000000, bitrate: 98569 kb/s Stream #0:0(und): Video: h264 (High) [avc1 / 0x31637661] yuv420p, tv, unknown/unknown/bt709 3840x2160 [PAR 1:1 DAR 16:9], 96722 kb/s 23.98 fps, 24k tbn (default) Metadata: creation_time : 2018-09-19 01:49:35 handler_name : Video Media Handler encoder : AVC Coding Stream #0:1(und): Audio: pcm_s16be [twos / 0x736F7774] 48000 Hz, 2 channels, s16, 1536 kb/s (default) Metadata: creation_time : 2018-09-19 01:49:35 handler_name : Sound Media Handler Stream #0:2(und): Data: rtmd / 0x646D7472, 196 kb/s (default) Metadata: creation_time : 2018-09-19 01:49:35 handler_name : Non-Real Time Metadata Track codec: avc1 avc1: Match with 0 header

Buffer size exceeded Track codec: twos This audio codec is EVIL, there is no hope to guess it.

But is known that Sony uses AAC as audio codec. Any way to fix it?

SuslikV commented 5 years ago

For different modes/quality of filming (at manual mentioned as "format") - your camera uses different codecs. So, nothing wrong with it.

PCM is hard to recover, because sample size will change during recording 2 or 3 times (usually), so files needs to be recovered manually (by splitting and finding next audio sample size at each change). Automation of this task is possible but it is hard to implement.

garnio commented 5 years ago

How do you find where to split the file? even manually?

SuslikV commented 5 years ago

@garnio by packet "header" and flow of uncompressed data (that is PCM) that follows highly compressed data (that is h264 packet). If size is wrong, the recovery will be interrupted at next sample instead of group of samples (until next change). Encoder rarely changes this sample sizes, but unfortunately it happens.

anthwlock commented 4 years ago

from https://github.com/anthwlock/untrunc/issues/31#issuecomment-534185772:

I added some logic to dynamically (at runtime) detect and use some characteristics from the healthy file. If you want, you can see them all via untrunc -is <good.mov>. Importantly, this enables untrunc to recover whole chunks, rather than just frame by frame. In case of the sowt/twos codec, this is the only way possible.

For such audio codecs, the actual chunk information (found in 'stsc' atom) is needed. So I did something similar to this..

Also, oftentimes the different tracks are alternating in a predictable pattern. This fork https://github.com/anthwlock/untrunc/commit/505853d6a167dadaefc46b332da66fa7c2e912ec takes advantage of this.