Videos appear truncated unless with VLC and Films & TV video readers

[Mathilda]

I apologize in advance for this long message. I have videos of maximum 24h each that I suspect to be corrupted because on every video there are specifically 13h15m22s missing, no matter the length of the video. I know the ~13h part is not completely broken because I can see it in VLC media player and in the default video player in Windows (Films & TV).

But actually when I tried to check if the videos were corrupted using ffmpeg, I didn't get any issues as outputs :

ffmpeg.exe -v error -i "/Users/myname/Desktop/myvideo.mp4" -f null >error.log 2>&1
    ffmpeg.exe -v error -i "/Users/myname/Desktop/myvideo.mp4" -f null - >error.log 2>&1
    ffprobe -show_entries stream=r_frame_rate,nb_read_frames,duration -select_streams v -count_frames -of compact=p=1:nk=1 -threads 3 -v 0

I also tried to see if Python was reading my videos length correctly :

 from moviepy import VideoFileClip
    clip = VideoFileClip("C:/Users/myname/Desktop/myvideo.mp4")
    duration = clip.duration
    print ("duration : ", duration)

But there are still these 13h15m22s missing according to Python. So I still considered these videos as corrupted, and I tried to repair these videos with many ffmpeg command lines.

What I tried with ffmpeg :

I tried just copying the video to see if it solved the problem :

ffmpeg -i "/Users/myname/Desktop/myvideo.mp4" -c copy "/Users/myname/Desktop/myvideo_repaired.mp4"

But there were the ~13h missing. And apparently there was a problem with key frames so I tried re-encoding it and forcing the key frames creation :

ffmpeg -i "/Users/myname/Desktop/myvideo.mp4" -c:v libx264 -c:a copy -force_key_frames "expr:gte(t,n_forced*2)" "/Users/myname/Desktop/myvideo_repaired.mp4"

But there were still ~13h missing. And I also tried reencoding completely the video :

 ffmpeg -i "/Users/myname/Desktop/myvideo.mp4" -c:v libx264 -c:a aac "/Users/myname/Desktop/Test export vidéos/myvideo_reencoded.mp4"

And I still had the same problem. I also tried the mkv extension :

  ffmpeg -i "/Users/myname/Desktop/myvideo.mp4" -c:v libx264 -c:a aac "/Users/myname/Desktop/Test export vidéos/myvideo.mkv"

And the ~13h are still missing. I also tried to generate new timestamps, and used the `-loglevel debug` parameter to print all the hidden messages :

 ffmpeg -fflags +genpts -i "/Users/myname/Desktop/myvideo.mp4" -c copy -loglevel debug "/Users/myname/Desktop/Test export vidéos/myvideo_timestamps.mp4"

I got outputs saying "Invalid DTS/PTS Combination" and "EOF while reading input" which apparently means that there is a problem with timestamps and that the end of the input file has been reached quicker than expected. So I tried regenerating the timestamps :

  ffmpeg -i "/Users/myname/Desktop/myvideo.mp4" -vf "select='eq(pict_type,I)'" -fps_mode vfr "/Users/myname/Desktop/Test export vidéos/keyframes_%04d.png"

Which only gives me the frames as an output, with the ~13h of frames missing. And I also tried forcing the 1st frame to be a key frame :

   ffmpeg -i "/Users/myname/Desktop/myvideo.mp4" -vf "select='eq(pict_type,I)'" -force_key_frames "expr:gte(t,n_forced*10)" -fps_mode vfr "/Users/myname/Desktop/Test export vidéos/keyframes_%04d.png"

And still had ~13h of missing frames in my output frames. I eventually tried to analyse deeper the problems :

 ffmpeg -report -i "/Users/myname/Desktop/myvideo.mp4" -f null -

And got as an output hundread of lines looking like :

[null @ 0000020391541580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1293 >= 1293

I've not listed all that I tested but this is a pretty good summary. I'm running out of ideas at this point (my last idea is explaned at the end of this message).

I'm listing here the weird points I found about these videos :

- If my video is longer than 13h15m22s, there are always the last 13h15m22s missing. Otherwise, there is no missing part.
- The 13h15m22s problem occurs with different cameras (all from the same brand, I don't have its name but I can check if it's important).
- There are always 13h15m22s missing, no matter which software I use (except for VLC and Films & TV) : ffmpeg, python (with cv2 and moviepy), Movavi (or any other video edition software), etc.
- The fps are variable and sometimes their value has a lot of decimals (like 18.122...) so maybe it can cause an issue. But if I set the broken video to constant fps it doesn't give me back the missing 13h15m22s, I just have a truncated video with fixed fps.

And here is what I think about it :

- The problem should come from within the camera encoding, since the cameras were old
- However, the truncated data is not lost because I can still read it on VLC and Films & TV apps
- But the usual ways to repair corrupted videos do not work (I tried Video Repair, ffmpeg, and Untrunc)
- The only thing I managed to do is using Untrunc to repair my 24h video using a shorter working video as reference sample (length is 4h which is < 13h15m22s so it's working well). The output video file has a length of 24h and contains all the missing frames.

But to do that I had to set the variable fps of the working 4h video to the mean fps value of the broken 24h video, using ffmpeg :

 ffmpeg -i "/Users/myname/Desktop/myvideo.mp4" -r 20 "/Users/myname/Desktop/myvideo_20fps.mp4"

And once I repaired the 24h video using the 4h video with constant fps, the "repaired" 24h video was setting the video time depending on the frames amount. For example let's say the mean fps of the 24h video was 20 fps, then the repaired video was like "ok so each 20 frames there is 1second". But this is not true : since the fps mode is variable, sometimes a second gets only 5 frames and sometimes it's 30 ! So my video eventually lengths 24h, but the seconds with a lot of frames are counted as several seconds, while the seconds with few frames are counted as less than a second.

So about this point, I was wondering if I could use ffmpeg to set the fps rate to variable for the 4h video (after setting the fps rate to constant by giving it the mean fps value of the 24h video). This would allow the 24h video to keep a variable frame rate when I use the 4h video as a sample to repair it with Untrunc. At this point this is my last hope to get back these missing ~13h, unless you guys have other guesses about this issue.

Thanks a lot for every piece of advice !

[LigH.de]

I suspect some players to handle only 32 bit values of chunk sizes. Or 64 bit with a signed type. Just a guess without much substance.

[Mathilda]

I suspect some players to handle only 32 bit values of chunk sizes. Or 64 bit with a signed type. Just a guess without much substance.

Thanks @LigH.de for your answer! I investigated on this side by trying to change the codecs. I used VLC to encode in either H264 or H265 formats. Unfortunately, the H265 encoding (recommended for long videos) stretches the video, making it longer than it should. I suspect some seconds to last a bit longer that they should, depending on their fps value (since it is variable). Moreover, the H264 encoding does not result into stretching, but a video lasting more than 21h is shortened to the first hour of video only.

I don't know if you have any other leads, but if so I would be happy to test them.

Thanks !