About 20 minutes into a shoot the laptop I was using to record locked up.
Subsequent recordings were done without GPU video encoding, so that problem is solved.
What I’m left with is a 6GB Sensor01.mp4 which is not playable in in the DepthKit app, Windows Media player, VLC…
I’m beginning to look into using ffmpeg to help create a new video file from the corrupt one.
Has anyone had a similar situation and came up with a solution? I’ll share mine if I find one
@AndrewStephenson Thanks for sharing, and sorry to hear your recording was corrupted. To confirm, this was while capturing with a single sensor, correct?
If disabling GPU acceleration solved the issue, can you share the spec’s of the laptop, particularly the GPU model and driver version?
You can try using VLC’s convert function to repair the h.264 MP4 video, and if that doesn’t work, there are a handful of other third-party tools which claim to be able to repair corrupted MP4 videos. Let us know if any of them work.
This was a single sensor setup connected to a 2020 Razer 15 laptop. The laptop has a history of locking up during other ‘workloads’ specifically someone else playing Warzone! I don’t think it’s a spec issue, more of an issue with this particular laptop.
For the subsequent takes with the GPU disabled I had no issues.
While I’m here, during testing 4k shooting I was getting frame drops every 300ms or so… this turned out to be MS OneDrive running - not that I was writing to a OneDrive folder… just simply OneDrive running was enough to introduce some additional latency ¯_(ツ)_/¯ Preventing OneDrive from launching at startup was enough to record in 4k. I assume it’s the writing of pngs which was sensitive to the additional latency.
As for the recovery attempts… I tried the VLC method, I also tried using a combination of ffmpeg and a command called untrunc (which I had to build from source!) but sadly nothing worked.
Ultimately I tried a trial version of a program called Repairit ([Wondershare] [Official] Wondershare Repairit: Fix Corrupted Data Easily). I’m normally quite hesitant of such tools but it worked!
During the recovery process the application seemed to make heavy use of ffmpeg so perhaps with more time and effort I could have recovered using it… I did have to provide a working file from the same sensor which is similar to untrunc’s behaviour.
Anyway, hope this clarifies and maybe helps someone else.