Video file issues when re-muxing (corrupted file?)

speedingcheetah

Active Member
Joined
Nov 15, 2016
Messages
368
Reaction score
175
Location
Twin Cities, MN
Country
United States
Dash Cam
VIOFO A329T 3CH (Front + Tele + Rear) + Sandisk Extreme 1TB
I use a script and ffmpeg to re-mux/append the dash cams 2 minute video files into a single video file for easy viewing.

I am occasionally having a failure of this process, when it reports a corrupted video file.

When remuxing, it stops when it gets to a problem file.

[mov,mp4,m4a,3gp,3g2,mj2 @ 00000233bd4049c0] Auto-inserting h264_mp4toannexb bitstream filter5x elapsed=0:00:00.50
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000233bd4049c0] Auto-inserting h264_mp4toannexb bitstream filter32x elapsed=0:00:01.54
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000233bd4049c0] Packet corrupt (stream = 0, dts = 9566480).ed= 136x elapsed=0:00:02.05
[h264 @ 00000233be8343c0] Invalid NAL unit size (210904 > 184684).
[h264 @ 00000233be8343c0] missing picture in access unit with size 184688
[concat @ 00000233bcb1de00] h264_mp4toannexb filter failed to receive output packet
[in#0/concat @ 00000233bcb1db80] Error during demuxing: Invalid data found when processing input
[out#0/mp4 @ 00000233bd155c40] video:2232987KiB audio:2737KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.013077%
frame=10306 fps=4277 q=-1.0 Lsize= 2236016KiB time=00:05:43.53 bitrate=53320.7kbits/s speed= 143x elapsed=0:00:02.40
Done


A separate mini bat file i made to just check each file, this is the output error for bad file.


Checking 2025_0928_205655_000209F.MP4...
[h264 @ 0000021c3060cb80] Invalid NAL unit size (210904 > 184684).
[h264 @ 0000021c3060cb80] missing picture in access unit with size 184688
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000021c2fcddcc0] stream 1, offset 0x2940666c: partial file
[h264 @ 0000021c2fd7e880] Invalid NAL unit size (210904 > 184684).
[h264 @ 0000021c2fd7e880] Error splitting the input into NAL units.
[vist#0:0/h264 @ 0000021c2fce2c80] [dec:h264 @ 0000021c306c5bc0] Decoding error: Invalid data found when processing input

mkvtoolnix also spits a warning.


Quicktime/MP4 reader: Could not read chunk number 3106/3120 with size 210908 from position 691875472. Aborting.

Quicktime/MP4 reader: Could not read chunk number 4854/4874 with size 195 from position 692086380. Aborting.



The video file in this case, is one from the main front camera, and it is the last file before i turn my car off and the cam looses power, and shuts down.
It does not do it all the time, just occasionally. In my testing since i got the cam, it has happened maybe 3 times in total across a couple dozen or so times i have processed footage from the cam.
One of those times was in just 1ch mode, and using internal SD card. But i did not think much of it at the time, and did not save or recall what footage it was with.
At this time, the cam is A329T, is in 3Ch mode, with Viofo SSD cable, connected to Sandisk Extreme 1TB ssd, Both the recommended hardware.

The single file itself plays fine, no noticed issues.

---------
EDIT:

Anyone who wants to have a go and test for themselves, here is a REMUX into one file BASIC.zip containing a simplified version of the remux/appending script I am using.
You would place your same resolution files(like all the files from your drive from Front camera Ch1) in the root folder, and launch the .bat file. It appends the files into one, called output.mp4. If any of the files had an error in the process, it would show in the CLI window, and u will notice that the output video file only contains the footage up to that file that has error. The folder has the ffmpeg.exe included as a hidden file.

Second, Dash Cam Scripts v4.zip, is my full suite at the moment. It has more advanced setup with Input and Output folder. A dedicated script to just do Error Checking of the files. And the refined, cleaner version of my remux script, that also detects what letter the video file ends with, and name the resulting remuxed file based on that. So, F = Front, T = Telephoto, R = Rear. This is customized to my needs and use with the A329T files.

These should work in Windows 11.

Disclosure: These scripts were primarily "vibe coded" using MS Co-Pilot. I do have understanding of Windows batch scripting, and past experience with it, i am just to lazy to make it all from scratch.
If you wish to customize them for your own use, feel free. You can copy the .bat file save it as a .txt doc, and upload that to MS Co-pilot, or Google Gemini etc, and ask it to modify it for your needs.
Like, if you want to replace the Parts that are Telephoto, with Interior, etc.
------
As always, do not just trust and run any scripts you randomly download on the internet.
Open the .bat file in a text editor, or on a sandboxed or Linux machine, to view its contents and what code it is running, if you are concerned about security.
Run with a COPY of your video files first to get familiar with how they work. Always have a backup copy of your data!
--------

LINK to Gdrive. (.zip is too large to post to form)
 
Last edited:
Quicktime/MP4 reader: Could not read chunk number 3106/3120 with size 210908 from position 691875472. Aborting.

Quicktime/MP4 reader: Could not read chunk number 4854/4874 with size 195 from position 692086380. Aborting.

The video file in this case, is one from the main front camera, and it is the last file before i turn my car off and the cam looses power, and shuts down.
Could it always be one of the final chunks in the last video file written by the dashcam as it is power off? Players may ignore it at the end whereas ffmpeg is letting you know the final frame(s) are corrupted. Did the output of ffmeg still look correct? You may not be able to tell if it dropped a final corrupted frame, especially if players ignore that same frame.
 
Could it always be one of the final chunks in the last video file written by the dashcam as it is power off? Players may ignore it at the end whereas ffmpeg is letting you know the final frame(s) are corrupted. Did the output of ffmeg still look correct? You may not be able to tell if it dropped a final corrupted frame, especially if players ignore that same frame.
The process does not complete. It does the files before the bad one, but stops when it gets to the bad one.
I managed to make a forced remux, via mkvtoolnix to mkv, and when i playback the resulting combined file, it gets to that part where the bad file is, and it goes into fast forward like thing, with no audio, then after a bit, the audio starts,..ie, the resulting files is messed up and way out of sync.
 
VIOFO really needs to not only optimize the boot time of the A329T/S, but also their shutdown.

I went multiple places this morning and that resulted in every other video file that was being written when the camera shuts down, being "corrupted" so that it will not re-mux/append.
 
VIOFO really needs to not only optimize the boot time of the A329T/S, but also their shutdown.

I went multiple places this morning and that resulted in every other video file that was being written when the camera shuts down, being "corrupted" so that it will not re-mux/append.
I'm loath to say this, but here goes — memory card. There, I said it. lol

The problem you have highlighted sucks.

Is it possible that the memory card needs a refresh eg format it, or swap it out for another?
I prefer to format my cards on a computer as s sort of reference point. Then in the camera.
 
VIOFO really needs to not only optimize the boot time of the A329T/S, but also their shutdown.

I went multiple places this morning and that resulted in every other video file that was being written when the camera shuts down, being "corrupted" so that it will not re-mux/append.

When you powered down, how many channels were connected at that time. The super cap is suppose to do a keep alive long enough for files to be written...but if the cap is weak, or you are doing 3 minute, 3 channel, max everything files, then the write process may not have time to complete.

If using 3 channels, go to one channel and see if the problem persists. I have no idea how long the super cap should hold power, but you may want to time it and compare with another user.
 
I'm loath to say this, but here goes — memory card. There, I said it. lol

The problem you have highlighted sucks.

Is it possible that the memory card needs a refresh eg format it, or swap it out for another?
I prefer to format my cards on a computer as s sort of reference point. Then in the camera.
Sorry if I did not specify or mention here since I have had my other dedicated thread about my upgrade to this model cam…

The Sandisk ssd is brand new. So is the internal sd card (VIOFO 512GB).

If it was the storage media itself, I would think I would have consistently bad file issues and just not repeatable specific scenario that will trigger a “bad” file. That is the one file that is in progress when cam shuts down.
 
When you powered down, how many channels were connected at that time. The super cap is suppose to do a keep alive long enough for files to be written...but if the cap is weak, or you are doing 3 minute, 3 channel, max everything files, then the write process may not have time to complete.

If using 3 channels, go to one channel and see if the problem persists. I have no idea how long the super cap should hold power, but you may want to time it and compare with another user.
3ch. 2min file.

As I mentioned though I have had this issue come up when I was just using 2ch, but I did not recognize it to be repeated issue until most recently as I have not had the cam that long.

I am not sure if the loop recording length affects how much time the cam needs at shutdown to finishing writing the files, since all but the last bits of data is already written, I don’t think length of the past written data affects that, but, I can set it to 1 min for video file length. To see if that affects anything.

Finaly, I definitely think it is the most logical conclusion that this issue has something to do with the amount of power available and or time available for the camera to fully shut down and safely write the files to disc. But it certainly is inconsistent because at first it was the front camera files. Then next it was either of the other channel files. It seems to vary and is not consistent as to which file or when might be bad. It doesn’t do it every single time the camera shuts down, so there’s some sort of other variable at play here.
 
Have you contacted Viofo directly to request support with this issue?
 
VIOFO really needs to not only optimize the boot time of the A329T/S, but also their shutdown.

I went multiple places this morning and that resulted in every other video file that was being written when the camera shuts down, being "corrupted" so that it will not re-mux/append.
Was every effected file still able to be played without issue individually, as previously…?
Whilst highly annoying for the purposes of re-mux etc, and obvioulsy something isn’t ’right’, the more important issue is that these last files are still useable….
It ‘feels’ like it’s some sort of minor file writing issue as the camera is signing off and simultaneously going through the process of shutting down – I know that’s not particularly technical (!) but hopefully it’s something that would be relatively easy to tweak in the code with a firmware update….
When you say ‘shutdown’ – I’m presuming you mean the camera transitioning into Parking Mode or does your camera shut down when you stop your car..?
Out of interest – have you tried disconnecting the SSD, same outcome..? I know you have all the recommended’ hardware etc, but just throwing it out there if its some sort of issue SD–SSD issue perhaps…?
 
Have you contacted Viofo directly to request support with this issue?
Nope. They monitor these forms though. So they may comment on it if they are interested in it. I will give it more time and usage before I seek official help. I mainly i’m just asking the community here if anyone else has experienced this issue or even bothered to thoroughly check the actual integrity of the video files the camera produces.
 
Was every effected file still able to be played without issue individually, as previously…?
Whilst highly annoying for the purposes of re-mux etc, and obvioulsy something isn’t ’right’, the more important issue is that these last files are still useable….
It ‘feels’ like it’s some sort of minor file writing issue as the camera is signing off and simultaneously going through the process of shutting down – I know that’s not particularly technical (!) but hopefully it’s something that would be relatively easy to tweak in the code with a firmware update….
When you say ‘shutdown’ – I’m presuming you mean the camera transitioning into Parking Mode or does your camera shut down when you stop your car..?
Out of interest – have you tried disconnecting the SSD, same outcome..? I know you have all the recommended’ hardware etc, but just throwing it out there if its some sort of issue SD–SSD issue perhaps…?
I believe I mentioned in the original post, but yes, the file itself that ffmpeg takes issue with plays just fine in any media player. But there is something corrupt or missing data with it even if it’s just a few bits or a header or something in the video file that technically makes the file corrupted. This is exposed when you run an error scan with ffmpeg or you try to append the video files together.

I shut down I mean the camera loses power when my accessory cigarette lighter port shuts off and thus the camera triggers its power off/shut down and finish writing. It’s active files to the drive.

I do vaguely recall running into this issue when I only use the internal SSD card and I only had the one channel but I did not note when that was or think anything of it at the time. I mainly switched to the external SSD, simply due to the fact that it is a royal pain and nearly impossible to get to the internal SD card out of the camera due to the physical housing design of the camera itself. I have already lost one expensive, micro SD card into the abyss of the interior of my vehicle. When the thing shot out, I’m not going to risk it again every time I want to test and review footage by ejecting the SD card. But I agree it is a possibility that the external SSD and its power requirements might have some sort of effect or the cause of the issue.

More testing is needed, however yes, it is a bit of a edge case since most people aren’t going to be processing the videos, as I am making them into one single length video and discovering the fact that one video file from each channel might be “corrupted “by a few bits of data that prevents such a video processing to happen.
 
Yes you did mention in your original post, I was just confirming that that was still consistently the case…
As you say, it has to be some sort of ‘header’ write or file save technicality that is effectively ‘corrupting’ the file….
It may be a ‘edge use’ case, but still a use that is perhaps potentially very useful….Besides, I’m following this with interest – the effected files may be playing OK as single files, but if there’s a degree of underlying ‘corruption’ being flagged in them by any decent video/media player, I find that a worry and something that could potentially ‘bite’ – most probably when you least need it to!

Is there any way you could hardwire your setup, even some kind of temporary rig..? Just wondering if the accessory power outlet source could be a factor here – obviously, it shouldn’t be…but….Could be something particular with the outlet/car…even a DC spike of some nature…

I’d also be curious to engage one of the parking modes for a few trips and see if the exact same corruption happens to your last ‘driving’ files…If it doesn’t, it would clearly point the finger at the full shut-down/pwr off process and final file write…..??
 
Yes you did mention in your original post, I was just confirming that that was still consistently the case…
As you say, it has to be some sort of ‘header’ write or file save technicality that is effectively ‘corrupting’ the file….
It may be a ‘edge use’ case, but still a use that is perhaps potentially very useful….Besides, I’m following this with interest – the effected files may be playing OK as single files, but if there’s a degree of ‘corruption’ being flagged in them by any decent video/media player, I find that a worry and something that could potentially ‘bite’ – most probably when you least need it to!

Is there any way you could hardwire your setup, even some kind of temporary rig..? Just wondering if the accessory power outlet source could be a factor here – obviously, it shouldn’t be…but….Could be something particular with the outlet/car…even a DC spike of some nature…

I’d also be curious to engage one of the parking modes for a few trips and see if the exact same corruption happens to your last ‘driving’ files…If it doesn’t, it would clearly point the finger at the full shut-down/pwr off process and final file write…..??
Not possible to hardware it. I do not have the kit for that, and do not have any experience in how to install that, nor do i want to pay a professional to do that.
My vehicle already has parasitic drain due to a aging aftermarket Remote Starter...and using a Parking mode, is not anything i need or want. Or would trigger anything, since i park in a single car small garage, a block away from my building.

I will note though, that I have been using the same identical setup, 12v cig outlet with a 3 way adapter (that powers other things) for 10yrs. Never had this issue with any of my past cams, ever.
Not the A119 Mini 2, even the one i use in the rear that was powered by a 16ft Active usb cable. But, that was a single channel camera model.

I can post/ add to my OP, the ffmpeg code and attach links the .bat files i am using to process the files, so anyone here can use them on their own cam files, if they want. Would be for Windows OS only use though.
 
We have over 100 installed in the field. Never heard of this challenge. I know a guy that would have found it if it was a huge problem. I have not seen this challenge and I run my dash camera everyday in the vehicle. Have not seen any video corrupted files.
I will note though, that I have been using the same identical setup, 12v cig outlet with a 3 way adapter (that powers other things) for 10yrs. Never had this issue with any of my past cams, ever.
Not the A119 Mini 2, even the one i use in the rear that was powered by a 16ft Active usb cable. But, that was a single channel camera model.
I understand what you are saying. We make videos for YouTube and part of my video creation I use 2 battery packs in my vehicle. At 1 point in time I had 3 dash cameras on 1 battery pack and 2 dash cameras on another. According to all the math the battery pack should have easily adapted and supported the 3 cameras. It had a 2 amp output and the 3 cameras added up to under 1.5 amps. But I noticed that the Vantrue in my test had all sorts of image quality issues. It even shut off multiple times. I was going to make a video slamming the Vantrue. But I thought to myself what if my power source was the problem.

So I actually changed the power source on one of the cameras. I don't remember which one and then the Vantrue operated correctly and had no more challenges.

A lot of these newer dash cameras are power hungry.
 
We have over 100 installed in the field. Never heard of this challenge. I know a guy that would have found it if it was a huge problem. I have not seen this challenge and I run my dash camera everyday in the vehicle. Have not seen any video corrupted files.

I understand what you are saying. We make videos for YouTube and part of my video creation I use 2 battery packs in my vehicle. At 1 point in time I had 3 dash cameras on 1 battery pack and 2 dash cameras on another. According to all the math the battery pack should have easily adapted and supported the 3 cameras. It had a 2 amp output and the 3 cameras added up to under 1.5 amps. But I noticed that the Vantrue in my test had all sorts of image quality issues. It even shut off multiple times. I was going to make a video slamming the Vantrue. But I thought to myself what if my power source was the problem.

So I actually changed the power source on one of the cameras. I don't remember which one and then the Vantrue operated correctly and had no more challenges.

A lot of these newer dash cameras are power hungry.

Anyone who wants to have a go and test for themselves, here is a REMUX into one file BASIC.zip containing a simplified version of the remux/appending script I am using.
You would place your same resolution files(like all the files from your drive from Front camera Ch1) in the root folder, and launch the .bat file. It appends the files into one, called output.mp4. If any of the files had an error in the process, it would show in the CLI window, and u will notice that the output video file only contains the footage up to that file that has error. The folder has the ffmpeg.exe included as a hidden file.

Second, Dash Cam Scripts v4.zip, is my full suite at the moment. It has more advanced setup with Input and Output folder. A dedicated script to just do Error Checking of the files. And the refined, cleaner version of my remux script, that also detects what letter the video file ends with, and name the resulting remuxed file based on that. So, F = Front, T = Telephoto, R = Rear. This is customized to my needs and use with the A329T files.

These should work in Windows 11.

Disclosure: These scripts were primarily "vibe coded" using MS Co-Pilot. I do have understanding of Windows batch scripting, and past experience with it, i am just to lazy to make it all from scratch.
If you wish to customize them for your own use, feel free. You can copy the .bat file save it as a .txt doc, and upload that to MS Co-pilot, or Google Gemini etc, and ask it to modify it for your needs.
Like, if you want to replace the Parts that are Telephoto, with Interior, etc.

------
As always, do not just trust and run any scripts you randomly download on the internet.
Open the .bat file in a text editor, or on a sandboxed or Linux machine, to view its contents and what code it is running, if you are concerned about security.
Run with a COPY of your video files first to get familiar with how they work. Always have a backup copy of your data!
--------

LINK to Gdrive. (.zip is too large to post to form)
 
Last edited:
Anyone who wants to have a go and test for themselves, here is a REMUX into one file BASIC.zip containing a simplified version of the remux/appending script I am using.
You would place your same resolution files(like all the files from your drive from Front camera Ch1) in the root folder, and launch the .bat file. It appends the files into one, called output.mp4. If any of the files had an error in the process, it would show in the CLI window, and u will notice that the output video file only contains the footage up to that file that has error. The folder has the ffmpeg.exe included as a hidden file.

Second, Dash Cam Scripts v4.zip, is my full suite at the moment. It has more advanced setup with Input and Output folder. A dedicated script to just do Error Checking of the files. And the refined, cleaner version of my remux script, that also detects what letter the video file ends with, and name the resulting remuxed file based on that. So, F = Front, T = Telephoto, R = Rear. This is customized to my needs and use with the A329T files.
These should work in Windows 11.
------
As always, do not just trust and run any scripts you randomly download on the internet.
Open the .bat file in a text editor, or on a sandboxed or Linux machine, to view its contents and what code it is running, if you are concerned about security.
--------

LINK to Gdrive. (.zip is too large to post to form)
This is more of a @rcg530 test. I dont even use windows machines.
 
This is more of a @rcg530 test. I dont even use windows machines.
Well, the code can be adjusted to work on Linux or MacOS, i assume.
ffmpeg exists on other platforms to.
But, your on your own for that.
Windows is what i use mainly.
 
Nice and handy suite, good work..!👍

But I was going to comment the same – a Mac OS version would be great!
If any Mac users here occasionally dabble over on the dark side and would know how to translate the scripts etc, that would be much appreciated..! 😀
 
Back
Top