EJC
New Member
Hello All,
(Sorry #1 if wrong sub-forum, couldn't see forum for older model 312G.)
(Sorry #2 for what will be a tl;dr first post.)
Background: elderly parents' dashcam, Nextbase 312G, bought mail-order, brand-new/boxed, approx 4 years ago on the basis of multiple recommendations. Only ever genuine Kingston Endurance 64GB SDHCs used in it. Almost continuously mounted in the car through its lifetime, but extremely low-mileage, and formatted every few weeks as per instructions (on the vinyl display-protector which has never even been peeled off).
Battery's healthy: from fully-charged, the standard test gives 20+ min run-time, though that needs qualifying. It's a case of if---big IF---it doesn't lock up.
It's been an ongoing (and growing) problem for more than a year: ignition on, then after the normal cheery-chime startup, they'd sooner or later notice the red LED would have stopped flashing, the device apparently frozen, all buttons unresponsive. So, they'd whip out a pen and Hard-Reset it. Sometimes needing several Hard-Resets before 'normal' operation resumed for good.
Same behaviour indoors on the workbench with just a USB charge cable! Unpredictably locks up.
Even tried it again this afternoon: charged, froze, hard reset, recorder-stop, menu-settings, screensaver off, exit menu, recorder-mode, then found the flashing red LED and the in-picture clock both froze after about five minutes, but the dashcam's little screen remained on more than an hour, 65 minutes, but more bizarre, actually showing the moving live scene in front of it, just with all buttons non-functional.
You can't be having to constantly monitor and reset it while driving, that's ridiculous - and dangerous!
But I see the forums littered with threads about these crappy devices freezing.
Far from impressive for a "recommended" item whose raison d'etre is supposedly Reliability of recording.
Still, in these four years there'd been no events actually requiring looking at the video footage.
At least, not until now. Couple of weeks back there was an incident, car damaged, recovery-trucked to garage, only just been repaired/returned.
So, dashcam footage? Yes and no!
The files are there. And the relevant video and audio are clearly there in some form, because with the SDHC card in the device, the recorded files play back on the dashcam's little screen and speaker.
But---big BUT, perplexing but---when transferred to a PC, first bad sign is they show without thumbnails or previews, and then the actual .MOV files will not play anywhere. And I say that as a Linux system nerd, who's tried all---ALL---the normal strategies and players, even ventured to the home of QuickTime and tried various utilities and players on a 10.6.8 Snow-Leopard Intel Mac. (For the sake of clarity, yes... mpv, VLC, kdenlive, handbrake, QuickTimePlayer, MPEGStreamClip, iMovie, FinalCutExpress, blah blah etc etc).
Even some basic commandline 'ffmpeg' - NOTHING (though admittedly I don't speak fluent ffmpeg)!
Worth repeating, despite nothing playing the corrupt files, the normal non-corrupt files DO all play fine everywhere.
Incidentally, the widely-mentioned media-repair utility 'untrunc' didn't work either, nor did mp4edit.
Which leaves me doubting there's A Solution out there publicly.
So I've started trying a little geek sleuthing myself.
The following script prints some core info from a selected file.
For a typical good file from the dashcam, the script's utility 'ffprobe' reveals:
All pretty much standard info-overload output in the world of AV files. And that's a good file.
But the needed file, the unplayable file, the bad file, sadly that gives zilch. Well, just an error:
I've even started looking inside the binary files with a hex-editor (Okteta), and it's clear the content is very different between good and bad files: repeated text-strings and structures are either present or absent. But I'm rapidly getting out of my depth.
I've no familiarity with MP4 containers and tracks, nor this crucial "moov atom" or whatever, beyond a rapidly-gleaned understanding that these MOV/MP4 files are fragile. They need access-enabling index-data in the file, but that index is ONLY WRITTEN AFTER they've finished recording the actual audio/video tracks. Hence why MP4 files are corrupted if a recorder fails before it's written the index stuff. It's not robust and failsafe - not like, for example, the '.TS' transport-stream formats which deliver our DVB-T FreeView Digital Terrestrial Television over the airwaves and into our PVRs.
Anyway, off-topic, that's gonna the basis for another post, the question of which dashcams record .TS files.
Back to this post, the fact the dashcam itself still plays the needed video/audio shows IT IS STILL IN THERE SOMEWHERE.
It makes me suspect the software/firmware in the dashcam is by-passing normal PC media-player higher protocols and accessing the RAW AV data, probably an optimisation for speed.
Ideally, some Nextbase engineers would help here. <:big pleading eyes, like Puss-In-Boots to Shrek and Donkey:>
How can I repair/reclaim/extract the existing video from the corrupt .MOV file???
As I said, 'untrunc' couldn't manage it. So, I've even been pondering using the commandline utility 'dd' to try to do experimental tranplants/grafts of the structures/blocks I found using the hex-editor. Pondering, but not tried yet.
So, this oversize post is all to ask:
??? Can anyone chip in and nudge me closer to extracting what's needed ???
Please, pretty please!
If you've read this far you probably deserve a medal.
Hopefully someone can help.
Many, MANY thanks!
(Sorry #1 if wrong sub-forum, couldn't see forum for older model 312G.)
(Sorry #2 for what will be a tl;dr first post.)
Background: elderly parents' dashcam, Nextbase 312G, bought mail-order, brand-new/boxed, approx 4 years ago on the basis of multiple recommendations. Only ever genuine Kingston Endurance 64GB SDHCs used in it. Almost continuously mounted in the car through its lifetime, but extremely low-mileage, and formatted every few weeks as per instructions (on the vinyl display-protector which has never even been peeled off).
Battery's healthy: from fully-charged, the standard test gives 20+ min run-time, though that needs qualifying. It's a case of if---big IF---it doesn't lock up.
It's been an ongoing (and growing) problem for more than a year: ignition on, then after the normal cheery-chime startup, they'd sooner or later notice the red LED would have stopped flashing, the device apparently frozen, all buttons unresponsive. So, they'd whip out a pen and Hard-Reset it. Sometimes needing several Hard-Resets before 'normal' operation resumed for good.
Same behaviour indoors on the workbench with just a USB charge cable! Unpredictably locks up.
Even tried it again this afternoon: charged, froze, hard reset, recorder-stop, menu-settings, screensaver off, exit menu, recorder-mode, then found the flashing red LED and the in-picture clock both froze after about five minutes, but the dashcam's little screen remained on more than an hour, 65 minutes, but more bizarre, actually showing the moving live scene in front of it, just with all buttons non-functional.
You can't be having to constantly monitor and reset it while driving, that's ridiculous - and dangerous!
But I see the forums littered with threads about these crappy devices freezing.
Far from impressive for a "recommended" item whose raison d'etre is supposedly Reliability of recording.
Still, in these four years there'd been no events actually requiring looking at the video footage.
At least, not until now. Couple of weeks back there was an incident, car damaged, recovery-trucked to garage, only just been repaired/returned.
So, dashcam footage? Yes and no!
The files are there. And the relevant video and audio are clearly there in some form, because with the SDHC card in the device, the recorded files play back on the dashcam's little screen and speaker.
But---big BUT, perplexing but---when transferred to a PC, first bad sign is they show without thumbnails or previews, and then the actual .MOV files will not play anywhere. And I say that as a Linux system nerd, who's tried all---ALL---the normal strategies and players, even ventured to the home of QuickTime and tried various utilities and players on a 10.6.8 Snow-Leopard Intel Mac. (For the sake of clarity, yes... mpv, VLC, kdenlive, handbrake, QuickTimePlayer, MPEGStreamClip, iMovie, FinalCutExpress, blah blah etc etc).
Even some basic commandline 'ffmpeg' - NOTHING (though admittedly I don't speak fluent ffmpeg)!
Worth repeating, despite nothing playing the corrupt files, the normal non-corrupt files DO all play fine everywhere.
Incidentally, the widely-mentioned media-repair utility 'untrunc' didn't work either, nor did mp4edit.
Which leaves me doubting there's A Solution out there publicly.
So I've started trying a little geek sleuthing myself.
The following script prints some core info from a selected file.
#!/bin/bash
printf "\n\n\n"
read -e -p " > Video File ? : " -i "${VIDEO_FILE}" VIDEO_FILE
printf "\n\n\n"
ffprobe -hide_banner -i "${VIDEO_FILE}"
printf "\n\n\n"
ffprobe -hide_banner -v error -show_format -show_streams "${VIDEO_FILE}" | grep -iE '(format_name|TAG:compatible_brands|codec_name=|codec_tag_string|codec_tag=|pix_fmt=)'
printf "\n\n\n"
For a typical good file from the dashcam, the script's utility 'ffprobe' reveals:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/path/to/video/files/220721_160907_084.MOV':
Metadata:
major_brand : qt
minor_version : 0
compatible_brands: qt
creation_time : 2022-07-21T16:11:08.000000Z
original_format : Nextbase
original_format-eng: Nextbase
comment : NBDVR312G-B-R00.2
comment-eng : NBDVR312G-B-R00.2
Duration: 00:02:00.00, start: 0.000000, bitrate: 15330 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 14739 kb/s, 30 fps, 30 tbr, 60k tbn, 60 tbc (default)
Metadata:
creation_time : 2022-07-21T16:11:08.000000Z
handler_name : VideoHandler
encoder : h264
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 112 kb/s (default)
Metadata:
creation_time : 2022-07-21T16:11:08.000000Z
handler_name : SoundHandler
codec_name=h264
codec_tag_string=avc1
codec_tag=0x31637661
pix_fmt=yuv420p
codec_name=aac
codec_tag_string=mp4a
codec_tag=0x6134706d
format_name=mov,mp4,m4a,3gp,3g2,mj2
TAG:compatible_brands=qt
All pretty much standard info-overload output in the world of AV files. And that's a good file.
But the needed file, the unplayable file, the bad file, sadly that gives zilch. Well, just an error:
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x5617a4887e40] Format mov,mp4,m4a,3gp,3g2,mj2 detected only with low score of 1, misdetection possible!
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x5617a4887e40] moov atom not found
/path/to/video/files/CORRUPTED_FILE_20220707_160148_075.MOV: Invalid data found when processing input
I've even started looking inside the binary files with a hex-editor (Okteta), and it's clear the content is very different between good and bad files: repeated text-strings and structures are either present or absent. But I'm rapidly getting out of my depth.
I've no familiarity with MP4 containers and tracks, nor this crucial "moov atom" or whatever, beyond a rapidly-gleaned understanding that these MOV/MP4 files are fragile. They need access-enabling index-data in the file, but that index is ONLY WRITTEN AFTER they've finished recording the actual audio/video tracks. Hence why MP4 files are corrupted if a recorder fails before it's written the index stuff. It's not robust and failsafe - not like, for example, the '.TS' transport-stream formats which deliver our DVB-T FreeView Digital Terrestrial Television over the airwaves and into our PVRs.
Anyway, off-topic, that's gonna the basis for another post, the question of which dashcams record .TS files.
Back to this post, the fact the dashcam itself still plays the needed video/audio shows IT IS STILL IN THERE SOMEWHERE.
It makes me suspect the software/firmware in the dashcam is by-passing normal PC media-player higher protocols and accessing the RAW AV data, probably an optimisation for speed.
Ideally, some Nextbase engineers would help here. <:big pleading eyes, like Puss-In-Boots to Shrek and Donkey:>
How can I repair/reclaim/extract the existing video from the corrupt .MOV file???
As I said, 'untrunc' couldn't manage it. So, I've even been pondering using the commandline utility 'dd' to try to do experimental tranplants/grafts of the structures/blocks I found using the hex-editor. Pondering, but not tried yet.
So, this oversize post is all to ask:
??? Can anyone chip in and nudge me closer to extracting what's needed ???
Please, pretty please!
If you've read this far you probably deserve a medal.
Hopefully someone can help.
Many, MANY thanks!
