Panorama II crash test - current video file completely lost

Well, there is a possibility that doesn't involve super car or airline crashes, but I agree it's very remote and the OP's testing methodology is unrealistic. Ever drop a cell phone and have the cover, battery, sim and memory card all fly off in different directions? I do however have a solution that should make it virtually impossible for the memory card to pop out unless the camera was completely crushed, piece of soft foam and tape over the card slot.

KuoH

Wow haha I think that just about wraps up this debate/concern.
 
The key difference is that when a car crashes, it crumples, which spreads out the change in speed over a much, much greater period of time (even if it is still a fraction of a second)

Anything in the car (occupants, electronics, a dash cam) benefits from the car(s) crumpling.

Seat belts work because they clamp your body into the car -- and the car's frame (ie. 'crumple zones') take the damage instead of you. Dash cams are also firmly clamped into the car. The twisting metal decreases the acceleration from tens of thousands to generally less than a hundred gees.

When you drop a cell phone onto hard cement, the 'stopping time' is much, much closer to zero. This results in as many, or even more gees, even though the speed is much, much lower.

An unprotected cell phone easily experiences at least hundred gees when dropped from a 'hand hold' height onto concrete, which is why they tend to break apart, shatter, etc. There's no "give" in the phone's frame.

It's a bit counter intuitive, but dropping a cell phone actually approaches kind of accelerations you'd expect in an auto accident. The speed is lower, but the time to stop is also much, much lower.
 
I'm not suggesting that the camera experiences the same deceleration as a phone hitting the pavement during the initial crash, but rather the camera coming loose from the crash and impacts some other hard object inside the car. Like I said, a remote possibility, but easily remedied with some tape or a very secure mount.

KuoH

When you drop a cell phone onto hard cement, the 'stopping time' is much, much closer to zero. This results in as many, or even more gees, even though the speed is much, much lower.

An unprotected cell phone easily experiences at least hundred gees when dropped from a 'hand hold' height onto concrete, which is why they tend to break apart, shatter, etc. There's no "give" in the phone's frame.
 
Last edited:
The irony of fate.
Yesterday was a sad day in my life.
My car frontally crashed into another vehicle. My MB did not suffer much, but front airbags inflated:
mb_crash.jpg


From the impact "Panorama II" broke off the mount.
In this image you can see the point where it came off:
panorama_S_tearoff_point.jpg

From the scratches on the camera it seems that camera hit windshield with memory card slot side:
panorama_S_scratches.jpg

As a result memory card fell out of Panorama II and was later found stuck between the front panel and windshield.

As suspected, the last video clip which should cover the incident (~15 seconds till the incident) has 0 byte size:
Code:
-rwx------ 1 544M May 30 14:14 20150530_130940.MP4
-rwx------ 1 543M May 30 14:19 20150530_131440.MP4
-rwx------ 1 375M May 30 14:23 20150530_131940.MP4
-rwx------ 1 543M May 30 14:38 20150530_133326.MP4
-rwx------ 1 543M May 30 14:43 20150530_133827.MP4
-rwx------ 1 543M May 30 14:48 20150530_134327.MP4
-rwx------ 1 0 May 30 14:48 20150530_134827.MP4
Memory card was 128GB formated exFAT.
After the crash Panorama II still works fine and the clip which holds in the memory card seems to function fine.

I have created disk image of the memory card and will try to see if the lost recording can be somehow recovered. Will report about the success in the following post.
I never thought that I will have to perform this "very theoretical" Panorama II crash test on my skin. :(
 
Sorry to hear about your accident.
How low was your Panorama G mounted ?
From your observations - did airbag pushed / hit dashcamera ?
 
this highlights an issue with any camera attached in this manner, inertia

odd that it managed to fall off, hit the dash or whatever without the power wire coming out, must have been a bit of slack in the cable to have that happen
 
I asked about airbags, because something had to push memory card in, in order to release it so it jumped out.
1. when air bag deployed, it pushed memory card to click-release
2. dashcam felt the way it hit something on dash which also pushed to click-release sd card.

The good and bad thing about SD cards used in dashcams:
a good: it is easy to insert / eject them
a bad: on most dashcams which uses full size SD cards, the edge surface of SD card is flat to surface of memory card dashcam body slot, and full size memory card width is about 3 times wider than MicroSD card, which makes them more vulnerable to be click-released in accidents. For example in SG9665GC, the MicroSD card ( when inserted ) is about 1mm inside from dashcam shell surface, which has very little risk to be click-release by accident.
 
Whatever happened to rubber covers on all slots as seen in GS600, GS2000 etc in the past

23032013683.jpg
 
Panorama X2 has very strong memory carda rubber cover which I dont like to be honest, but now I see why its must be there.
 
Simple crash test: remove memory card while the dashcam is recording and check how much of the video footage made before the removal is recoverable from memory card.

For Panorama II it seems that the whole video file is lost. Even when cycle size is 5 minutes, if the card is removed on 4:55 the whole 5 minute video file is lost - memory card contains 0 byte sized file:

View attachment 8189
This might be the secret of relatively low Panorama current consumption - video stream is not frequently flushed to memory card.

This is fine unless you want to obtain video footage from accident whose impact might be fatal to dashcam.


Edit: The same "crash test" was performed also with 32GB memory card formated to FAT which in constant recording mode works without issues.

Use a sling shot and pull it back as hard as you can and throw the dashcam with SD card against a concrete wall.
If the SD card flies out, your crash theory makes sense, if it doesn't, it won't happen in a crash.
 
In the case of significant side impact the click-release clip will not hold the card in:
 
Rubber band will fixe this problem in second. [emoji6]
 
panorama_crashtest-png.8189

Finally succeeded to recover the video footage losing just about 0.5 sec until the crash. As far as I know there is no single tool available that can do it automatically, but I hope the instructions below might help to someone in a similar situation.


Recovering video data from the file system

The good news is that video and audio is constantly flushed to the data region of the file system (memory card). The bad news is that Panorama links the 0 byte file entry to the actual data only after the file has been fully written. In case the fragmentation was not needed to store the video data (i.e., there were X contiguous free clusters available at the time of writing), the recovery of video data should be relatively easier.

Before running any repair tools on the memory card first create the "disk image" of the card so that it would be possible to revert to the original state. You can create the image using:

In Linux (assuming /dev/sdb is the device of the connected card reader):
Code:
$ sudo dd if=/dev/sdb of=~/memcard.img bs=1M
Later if you need to revert the memory card to the original state use:
Code:
$ sudo dd if=~/memcard.img of=/dev/sdb bs=1M

In case of FAT32 (<= 32GB)

If the size of the memory card is 32GB or less, it is formated by Panorama built-in formater using FAT32 file system and 32KB cluster size. The camera starts writing the video file by first creating a file entry in the directory. Only after the file is fully written the file entry is updated by specifying the file size and pointer to the first cluster of the data region where the file is stored. The video data is constantly written to the data region, however, the FAT table is updated only time to time.

The easiest solution is to salvage unused cluster chains (FAT chains which are allocated, but which are not used by any directory or file entry) to files. This can be done in Windows using DSKCHK or in Linux using fsck.fat:

In Windows:
Run "Check this drive for errors" from the "Tools" tab on the disk:
chkdsk_scan.png


To see the hidden directory "FOUND" created by DSKCHK, the directory permissions have to be changed running these commands as "administrator":
Code:
E:\>dir
Volume in drive E is GLG320
Volume Serial Number is 201D-1EEC
Directory of E:\
12/29/2014  11:14 PM    <DIR>          JPEG
12/29/2014  11:14 PM    <DIR>          EVENT
05/30/2015  01:48 PM    <DIR>          VIDEO
               0 File(s)              0 bytes
               4 Dir(s)   1,620,180,992 bytes free
E:\>attrib -h -r -s /s /d *.*
E:\>dir
Volume in drive E is GLG320
Volume Serial Number is 201D-1EEC
Directory of E:\
12/29/2014  11:14 PM    <DIR>          JPEG
12/29/2014  11:14 PM    <DIR>          EVENT
05/30/2015  01:48 PM    <DIR>          VIDEO
06/01/2015  07:06 PM    <DIR>          FOUND.000
               0 File(s)              0 bytes
               5 Dir(s)   1,620,180,992 bytes free
In FOUND.000 you will see files in the format "FILE0000.CHK" which contain clusters of the unassigned FAT chains.

In Linux (assuming /dev/sdb is the device of the connected card reader):
Code:
$ sudo fsck.fat -a /dev/sdb
fsck.fat 3.0.26 (2014-03-07)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be
corrupt.
Automatically removing dirty bit.
FATs differ but appear to be intact. Using first FAT.
Reclaimed 1402 unused clusters (5742592 bytes) in 1 chain.
Performing changes.
/dev/sdd1: 6 files, 1406/479298 clusters

$ ls -alh /media/user/4C94-FC0C/
total 5.5M
drwx------  5 user user 4.0K Jan  1  1970 .
drwxr-x---+ 5 user user 4.0K Jun  9 21:37 ..
drwx------  2 user user 4.0K Jun  8 20:49 EVENT
-rw-r--r--  1 user user 5.5M Jan  1  1980 FSCK0000.REC
drwx------  2 user user 4.0K Jun  8 20:49 JPEG
drwx------  2 user user 4.0K Jun  8 20:49 VIDEO
The root folder of the memory card will contain files in the format "FSCK0000.REC" which contain clusters of the unassigned FAT chains.

The problem with this approach is that since the FAT chain is updated by Panorama only time to time, there will be more video available in the data region than referenced in the unused FAT chain. One approach is to recover X unallocated clusters following right after the last cluster referenced in the unused FAT chain (custom tool needed).

Alternative approach is to release the unused FAT chains as free space (by running fsck.fat interactively) and look for video data in the unallocated space. This approach should be used also when fsck.fat and DSKCHK does not recover any unused FAT chains (in case the camera did not update FAT at all). There are several tools that can extract unallocated clusters from the data region (FTK,Autopsy/Sleuthkit).

Then in the unallocated data look for clusters starting with this MP4 header and extract the following X clusters to the recovered_candidate.mp4 file:

Code:
00000000  00 00 00 1c 66 74 79 70  4d 53 4e 56 01 29 00 46  |....ftypMSNV.).F|
00000010  4d 53 4e 56 6d 70 34 32  69 73 6f 6d 00 00 00 94  |MSNVmp42isom....|
00000020  75 75 69 64 50 52 4f 46  21 d2 4f ce bb 88 69 5c  |uuidPROF!.O...i\|
00000030  fa c9 c7 40 00 00 00 00  00 00 00 03 00 00 00 14  |...@............|
00000040  46 50 52 46 00 00 00 00  00 00 00 00 00 00 00 00  |FPRF............|
00000050  00 00 00 2c 41 50 52 46  00 00 00 00 00 00 00 02  |...,APRF........|
00000060  6d 70 34 61 00 00 02 0f  00 00 00 00 00 00 00 80  |mp4a............|
00000070  00 00 00 80 00 00 bb 80  00 00 00 01 00 00 00 34  |...............4|
00000080  56 50 52 46 00 00 00 00  00 00 00 01 61 76 63 31  |VPRF........avc1|
00000090  01 4d 00 28 00 02 00 02  00 00 3a c0 00 00 3e 80  |.M.(......:...>.|
000000a0  00 1e 00 00 00 1e 00 00  07 80 04 38 00 01 00 01  |...........8....|
000000b0  00 00 00 08 66 72 65 65  00 00 00 00 6d 64 61 74  |....free....mdat|

In case of exFAT (> 32GB)
If the memory card is larger than 32GB it will be formated in the Panorama using exFAT file system and 128KB cluster size. The same recovery logic applies also to exFAT with minor differences:
  • Linux fsck.fat does not support exFAT file system (use Window's DSKCHK instead).
  • In case fragmentation is not needed Panorama will not update FAT at all. In this case there are good chances that the file starts from the first unallocated cluster and follows in X consecutive unallocated clusters.

Repairing unfinalized video file

Panorama uses QuickTime media container to store the video and audio. The video and audio data is dumped into MP4 "mdat" atom, and after video is fully captured, the size of the "mdat" atom is updated and at the end of file is appended MP4 "moov" atom which contains information about codecs used and the information about all the frames contained in "mdat" atom.

The recovered unfinalized video file will have no "moov" atom at the end of file and thus will not be playable by any video player. There are tools out there which will reindex video and audio stored in "mdat" atom and write a proper "moov" atom if given a working reference file taken by the same camera and using the same video settings.

On Linux:
Code:
$ sudo apt-get install libavformat-dev libavcodec-dev
$ wget https://github.com/ponchio/untrunc/archive/master.zip
$ unzip master.zip
$ cd untrunc-master/
$ g++ -o untrunc file.cpp main.cpp track.cpp atom.cpp mp4.cpp -L/usr/local/lib -lavformat -lavcodec -lavutil
$ ./untrunc
Usage: untrunc [options] <ok.mp4> [<corrupt.mp4>]
$ ./untrunc ./good.mp4 ./recovered.mp4

Warning: Panorama uses different H264 codec PPS profile for every file (I guess based on the amount of light at the time of video capture). Most likely the file captured before the crash will contain the same H264 PPS profile and can be used as a correct reference file, but this is not guaranteed. In the worst case there are only 15 different H264 PPS profiles which can simply be bruteforced (see untrunc-master/track.cpp line 393). If reference file with a wrong PPS profile is used the fixed video will have sound, but the video will be all green.

There is also a commercial online service (http://mp4repair.org) which will fix the unfinalized file by correctly guessing codecs and H264 PPS profile used.
 
Last edited by a moderator:
Oops, it looks like Lielap already linked a video demonstrating how an SD card can pop out, but it also applies to microsd and in other axis / directions as well.

I don't have a Panorama to check, but I do believe the latching mechanism on many SD/microsd slots operate by engaging a small piece of plastic or metal perpendicularly (vertically) to the insertion/removal axis of movement. If the card slides in, then the retaining latch either pushes from the top or bottom of the card. This means a major impact on the front of back of the camera near the card slot can indeed cause the latch to pop out of position, allowing the spring to shoot the card out. Anybody with an old/dead camera can probably test this by banging one against the kitchen table. Also most cards are only held in by friction, despite the latching mechanism. One can easily verify this by pulling the card out with tweezers instead of pushing in to disengage the latch. This means that the card can be shaken loose by a strong impact in the direction of normal card removal. The manufacturers could remedy this with a simple rubberized, easily movable cover, but knowing how cheap most are, it'll probably be attached with a very thin rubber or plastic retainer that'll break after a few uses.

My wishlist for future dashcams would be a multichannel system with a remote mountable main unit, normal SD slots with secure covers AND USB connections to allow expanded storage via a variety of inexpensive devices like flash drives, normal and SSD hard drives. Even better would be if they would incorporate automatic wifi offloading to a home PC when the car is parked in the garage.

KuoH

I asked about airbags, because something had to push memory card in, in order to release it so it jumped out.
1. when air bag deployed, it pushed memory card to click-release
2. dashcam felt the way it hit something on dash which also pushed to click-release sd card.
 
Last edited:
Thread starter Similar threads Forum Replies Date
P II / S 2
C II / S 1
D II / S 4
D II / S 19
L II / S 2
Back
Top