Panorama II crash test - current video file completely lost

Lielap

Member
Joined
Jun 24, 2014
Messages
60
Reaction score
26
Country
Latvia
Dash Cam
Prestigio RoadRunner 530, Powerucc Panorama II S
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:

panorama_crashtest.png
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.
 
This is the third thread (4th post) you created for the same problem. (except not sure what a "crash test" means, ejecting while recording is a no no on ANy cam)
https://dashcamtalk.com/forum/threads/panorama-ii-s-occasional-reboot.7380/
https://dashcamtalk.com/forum/threads/panorama-ii-s-broken-video-clips.6669/
https://dashcamtalk.com/forum/threa...er-tool-utility-how-to.3693/page-3#post-90538

We've been selling/supporting Panorama's with >32GB cards all year long. (No problems on FAT32 even 256GB). How many >32GB cards did you try? What are the make/models? It sounds like you have an isolated incident or nonstandard controller on the particular SD card you have. (Which brands??) If you've exhausted all troubleshooting then it is time to RMA/replace your camera.
 
Last edited by a moderator:
This is the third thread you created for the same problem.

Nope. Try it out yourself and come back with the results.
 
SanDisk has known problems if you're using certain SanDisk cards. (Firmware engineers reported SanDisk has a Controller bug) I asked what brand/model you are using in the other 3 threads. More importantly, ejecting any memory card while recording on ANy camera is a no no.
 
Last edited:
Have you tried running dosfsck (you may need the dosfstools package installing) or fsck.fat against the card to see what happens when it's checked the filesystem? Likewise if you're able to boot into Windows what happens when you run chkdsk against the card?
 
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.

I don't understand why you call this a "crash test".
I don't know of any kind of crash that would simply remove the SD card from the camera.
I strongly suspect that the g-force sensor would trigger saving the cache video to the Events folder of the card before the camera was damaged, and SD cards are known to survive very difficult circumstances.
 
pointless test as remove the sd on any camera and it will lose the file it was recording..

point is in a real crash the battery or capacitor will enable the camera to save the file in the event of a sudden power loss.
 
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.

May I ask: have you tried to do same "crash-test" on other dashcams ? How they behave ? You will get same "error" result and even can damage a memory card with those silly "crash tests".

Dashcam video data processed and stored temporary in RAM memory with so called "portions" ( video length of clip you have selected: 1,2,3,5 min etc ). After each "portion" is reached ( 1,2,3,5 min ) or after so called "crash" ( power loss ) data is saved from RAM memory to Flash memory ( SD Card ). If you going to remove suddenly a SD card, - then there is no place where last portion of the RAM data can be saved to. This is pure logic.
 
As I said, if your dashcam if hit in the accident, your G sensor and flushing data to card might be too late.

I have tested this crash test with two other dashcams:
Prestigio 530 (saves in .mov): file contains 0 bytes - same as with Panorama II.
Prestigio 520 (saves in .avi): video stream saved up to the second when the card was removed.

Maybe there is something common with H.264 - they don't flush data frequently.
 
How many videos have been posted from Russia, or any were else for that matter, where the vehicle carrying the camera is destroyed yet there it is posted for the world to see? Popping the SD card out of a camera while it is running is not any sort of "crash test"; to do that you need to crash something, like a car, truck, motorcycle, bicycle, train etc. Now if you are talking about crashing the camera operating system that is different. I would imagine that almost all cameras that you pull the SD card from while running will crash the operating system. But what does that prove exactly?
 
As I said, if your dashcam if hit in the accident, your G sensor and flushing data to card might be too late.

.

Best explained by..

my camera takes 4 seconds to shut down and save the file using power from the battery and if it had a capacator from that....

you are wrong to call it a crash test as its misleading in name and what you are doing by removing the sd card while the camera is recording is cutting the power instantly , just as you would be doing if you turned the camera off while recording - in both cases you have taken away the ability for it to use the 4 seconds of power to close the file successfully.

Its not suprising in the least that it doesnt save the file as that is what the battery or capacitor is there to do !!!!!!!!!!!!
 
How many videos have been posted from Russia, or any were else for that matter, where the vehicle carrying the camera is destroyed yet there it is posted for the world to see?
Indeed!

Popping the SD card out of a camera while it is running is not any sort of "crash test";
Removing memory card is equivalent to situation when dashcam is crashed such that nothing more can be written to memory card. And this is the moment of truth - what is actually inside your memory card in this moment.
 
You're meaning crash test as in software failure test right and not as in you crashed your car?

Did you do the check on the filesystem as I'm guessing it will find lost file fragments on there - pulling the card like that will hose the filesystem in any case though as Mp4 files would have the header created at the end once the video data is complete which is when the filesystem would be updated to show the correct file size.

RV has a couple of options to recover data so probably worth giving those a go.

Recovering of damaged video files
If video record process failed, the file's header is not saved and file will broken. This happens, for example, when the camera is crashing or memory card cannot handle too much data flow. This video file cannot be played, however, it can be recovered. It requires another good (not damaged) video file, recorded with the same frame size, to set parameters for the search and copy specific information to create new file's header.
Implemented two independent methods for restoring broken files:
  • Repair header.
    Seek a well-known structure of MOV / MP4 file, locate the frame borders and write lost header straight to the source file. The method works for most popular modern FullHD DVR, especially on the Ambarella chip.
  • Full scan.
    All bytes of the file passed through decoder, which performs decoding, only if the data was sent is valid frame. The method works, no matter the structure of the damaged file, and even able to recover video from the data files of lost clusters. This creates new video file, which contains all recognized frames. Need free space as size of broken file.
    Both methods are not exclusive and may be used together, in any order.
    As a test, the repairing can be applied to the working file. The result, in theory, should remain playable. This will give you a confirmation that the recovering works for your type and format of files.

Where was this camera from though as sounds like you've got more basic problems with it which you're trying to replicate here?
 
You're meaning crash test as in software failure test right and not as in you crashed your car?
How likely is that in case of car crash your smashed dashcam will be able to use supercap that has have fallen off for 4 seconds to finish saving video?

Did you do the check on the filesystem as I'm guessing it will find lost file fragments on there - pulling the card like that will hose the filesystem in any case though as Mp4 files would have the header created at the end once the video data is complete which is when the filesystem would be updated to show the correct file size.
Good idea! Don't see easy way to test this.
As I said before, I have tested this with dashcam which stores H.264 in .AVI container and there the filesize is updated every second and that broken video is easily recoverable using VLC player. Maybe that is a wise idea for dashcam manufacturers to use .avi container that allows such easy recovery without analyzing filesystem byte-by-byte.
 
If you're in Linux just use dosfsck or fsck.vfat - if you can boot into Windows just use chkdsk and see what it says as odds are it's going to fix a few things with the way the card is pulled out.

I'm sure I read recently that when doing AVI it doesn't support seamless clips so it would be swings and roundabouts.

Like the guys have said it all depends on the crash - if it's bad enough to obliterate the dash cam odds are you're not going to be around to worry about it either :(
 
Very strange design of a "crash test". I would understand if you remove the power-cable, but ejecting a memory card... Why?! Obviously modern dashcams will have some RAM where it will record the video, writing it to memory card only in certain portion. Writing video-stream "as you go" is just impossible, due to how video compression works. Yes, raw-video could be written in such manner, but size will be enormous.

As I said, if your dashcam if hit in the accident, your G sensor and flushing data to card might be too late.
In that case you need to adjust your testing method - try throwing the camera at the wall. Even smashing it with hummer would be wrong as it will be different type of impact, compared to a car crash.
 
Actually I see some point what OP probably meant under "crash test". In trully heavy crash, where memory card can "pop out" ( disconnects ) and will not be able to save last file. In those cases need to look for dashcams with so called dual-save technology where dashcam has internal hardware memory: RAM + internal flash-memory ( hardware ) + normal / regular removable SD or MicroSD flash memory. Thinkware range has dual save yechnology.
 
Last edited:
In trully heavy crash, where memory card can "pop out" ( disconnects ) and will not be able to save last file.

I just don't see that kind of crash being possible. The Panorama has the latching/ejecting type of SD card retainer. That means the crash would have to have:
  • Enough acceleration to push a 2.6 gram SD card into the SD card slot, overcoming both the spring and the friction.
    • My Panorama needed more than 10 Newtons of force to push the card in.
    • That means you would need more than 400 Gees of acceleration in an exact direction to achieve a card ejection.
      • Any other direction else makes it impossible to eject the card. (I'm an engineer; I just did the math)
  • The solder on the circuit board can easily withstand 40-50 N of force, and the parts weigh even less than the SD card. (I design circuit boards)
    • This makes the SD card the 'weakest link'.
Let's put that in perspective:
  • The highest acceleration ever survived was 214 Gees, was moving 220 MPH at the time, had racing safety gear to protect him, and was at a raceway, so emergency personnel were there in seconds.
  • The guideline for a 'survivable' (50% survivable) impulse in a car accident is 100 Gees.
    • This is about the same as crashing a car at 100 km/h (62 MPH) into an immovable concrete wall.
    • Any crash harder than that and your heart, lungs, liver, and other vital organs will burst. Neither airbags or seat belts will save you.
So, in short, the OP is talking about a crash that would be so violent that:
  • Everyone in both cars would be very, very dead.
  • The guy at fault was the one moving faster than a Bugatti Veyron's top speed.
    • A head-on collision of two cars at 100 MPH would still be 100 MPH to 0 MPH. Hitting head on is not "worse" than hitting a solid stationary wall.
So, unless the OP is trying to get hit on the Bonneville Salt Flats, about the only thing that can hit him hard enough to disable his camera is a crashing airliner.
 
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