Can't you reproduce this messing with a smaller file in a text editor?

In T68091#765463, @Dalai Felinto (dfelinto) wrote:

Can't you reproduce this messing with a smaller file in a text editor?

Thing is: other corrupt videos give errors like in 2.7X, but I'll give it a go...

I will have to ask @Sergey Sharybin (sergey) if he will be able to look into this.
Unfortunately I don't have enouh RAM(4gig) to debug this.

I will hopefully have new workstation, but that would be near 2.82 cycle

I don't think you need a huge amount of ram to debug this, just set a breakpoint in startffmpeg and step through until anim->duration is assigned.

The video file is claiming to have 5,175,604,057,416 frames, which is obviously wrong.
The average framerate is set to weird value of 2603 / 902820173.
The deprecated framerate field is set to 30 / 1.

Blender's logic is so that:

• If the frame number is specified explicitly in the file, we use it.
• Otherwise, use avg_frame_rate unless either of those are true:
  • Blender is compiled using FFmpeg, and the input video is encoded with FFmpeg.
  • Blender is compiled using FFmpeg and avg_frame_rate is set to 0.
  • Blender is compiled using older Libav.

In other cases r_frame_rate is used.

In order to solve the issue we need to make it so duration in frames is deducted to some sane value in startffmpeg.
If we somehow use r_frame_rate in this case then the duration will be calculated to 0, making Blender to show corrupted/unsupported warning (which is kind of expected).
But it is unclear to me what should the policy be between using nb_frames, r_frame_rate and avg_frame_rate. Someone need to dig into the history and see why those were added and possibly tweak code around.

P.S. There is no-so-much-comprehensive tests which one can run with ctest -R ffmpeg.
P.P.S. CCing Sybren, he was solving some of the duration detection issues not so far in the past.
P.P.P.S. We should be able to cut the video after few kilobytes and add it to the regression suit once we're done with this if that's ok with @Christopher_Anderssarian.

ffprobe -v error -hide_banner -print_format json -show_streams -show_format shows the following framerate/time related fields for the video stream in that file:

"codec_time_base": "902820173/2603",
"r_frame_rate": "30/1",
"avg_frame_rate": "2603/902820173",
"time_base": "1/90000",
"duration_ts": 32119692,
"duration": "356.885467",
"nb_frames": "5175604057416",

So Blender "correctly" reads the fields from the video file at least. The question now is how to recognise that the data is useless, or to turn the at-the-moment-useless data into correct data. ffplay thefile.mp4 does play back the file correctly, so there must be a way to handle this.

ffplay thefile.mp4 does play back the file correctly

I can confirm problems with this video file, but I cannot confirm the crash of Blender.

Are you saying you can play the entire video?

For me playing the video in Blender and VLC work upto ~2:20 then both crash...

On my system both Blender and ffplay play the video until ~2:20 and then stop playback. Neither of them crash.