Repair fails for a damaged 4K quicktime recording from a DJI Phantom 3 Professional

[frispete]

Dear Federico,

I try to use untrunc from current git with ffmpeg 2.7.1 on a capable openSUSE 13.2 x86_64 system in an attempt to repair these files:

The good one: http://treewater.net/DJI_0000.MOV (1.5G)
The bad one: http://treewater.net/DJI_0003-defect.MOV (2.5G)

The first problem is, that untrunc doesn't find a codec, quite possibly due to the fact, that these quicktime footages contain video only, no audio.

Here's the output of just untruncing the good file:

Reading: DJI_0000.MOV
Composition time offset atom found. Out of order samples possible.
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'DJI_0000.MOV':
Metadata:
major_brand : qt
minor_version : 538182144
compatible_brands: qt
creation_time : 2015-07-18 19:50:42
location : +49.945756+7.908624+0.000
location-{ : +49.945756+7.908624+0.000
comment : 0.9.137
Duration: 00:03:36.98, start: 0.000000, bitrate: 59939 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 59936 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)
Metadata:
creation_time : 2015-07-18 19:50:42
handler_name : DJI.AVC
encoder : Dji AVC encoder
No codec found!

Using larger reference files result in:
Reading: DJI_0001.MOV
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Terminated

This might be due to the "large file" issues, others noticed already in this forum..
The setup described below generally produces huge file chunks (3.9G), hence this is a great source for getting testing files. I can provide you with them. My C++ brain is rusty at best, but I'm able to debug stuff. Here's the backtrace from above error condition:

(gdb) bt
#0 0x00007ffff567c187 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff567d538 in __GI_abort () at abort.c:78
#2 0x00007ffff5f6b145 in __gnu_cxx::__verbose_terminate_handler ()

at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95

#3 0x00007ffff5f692e6 in __cxxabiv1::__terminate (handler=)

at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38

#4 0x00007ffff5f69313 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#5 0x00007ffff5f69532 in __cxxabiv1::__cxa_throw (obj=0x7fffec000940,

tinfo=0x7ffff61f0b00 <typeinfo for std::bad_alloc>, dest=0x7ffff5f679f0 <std::bad_alloc::~bad_alloc()>)
at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:87

#6 0x00007ffff5f69a1d in operator new (sz=18446744073614107753) at ../../../../libstdc++-v3/libsupc++/new_op.cc:56
#7 0x000000000040b129 in File::read(unsigned long) ()
#8 0x0000000000405898 in Atom::parse(File&) ()
#9 0x0000000000408a9d in Mp4::open(std::string) ()
#10 0x0000000000402877 in main ()

Well, even my system doesn't have this amount of memory available ;)...

The good files can be played with vlc and mplayer(2) without any issues.
For the bad one, ffmpeg and friends spits out:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x121ea00] moov atom not found
DJI_0003-defect.MOV: Invalid data found when processing input

Obviously, it's missing essential metadata (at least).

Be assured, that due to the very subject above, you will have more attention with your project than ever before(!). I hope, you don't mind ;). That copter is great for a couple of reasons, but suffers from several teething troubles at the same time... I harvested the damaged file with a clean landing and shutdown procedure without any signs of technical trouble whatever. Oh well, strange, but I'm not alone.

[frispete]

Some more data points: adding largefile to untrunc.pro:CONFIG changes behavior slightly:

Reading: DJI_0000.MOV
Composition time offset atom found. Out of order samples possible.
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'DJI_0000.MOV':
Metadata:
major_brand : qt
minor_version : 538182144
compatible_brands: qt
creation_time : 2015-07-18 19:50:42
location : +49.945756+7.908624+0.000
location-{ : +49.945756+7.908624+0.000
comment : 0.9.137
Duration: 00:03:36.98, start: 0.000000, bitrate: 59939 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 59936 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)
Metadata:
creation_time : 2015-07-18 19:50:42
handler_name : DJI.AVC
encoder : Dji AVC encoder

Note: no "No codec found" complaint, and a repair attempt resulted in:

$ untrunc DJI_0000.MOV DJI_0003-defect.MOV
Reading: DJI_0000.MOV
Composition time offset atom found. Out of order samples possible.
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'DJI_0000.MOV':
Metadata:
major_brand : qt
minor_version : 538182144
compatible_brands: qt
creation_time : 2015-07-18 19:50:42
location : +49.945756+7.908624+0.000
location-{ : +49.945756+7.908624+0.000
comment : 0.9.137
Duration: 00:03:36.98, start: 0.000000, bitrate: 59939 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 59936 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)
Metadata:
creation_time : 2015-07-18 19:50:42
handler_name : DJI.AVC
encoder : Dji AVC encoder
Nal type: 9
Length for first packet = 6 / 800000
Nal type: 6
Length for first packet = 36 / 800000
Nal type: 5
Length for first packet = 1847567 / 800000
Found 2 packets

Well some progress at least as it started to do something. Great.
Unfortunately, it creates just a file with 1801 bytes. A tad small for a repaired 2.5G source file:
-rw-r--r-- 1 hp xxxx 2682257408 20. Jul 19:49 DJI_0003-defect.MOV
-rw-r--r-- 1 hp xxxx 1801 20. Jul 23:27 DJI_0003-defect.MOV_fixed.mp4

Please let me know, if I can do anything to help you to resolve the issue(s).