Page MenuHome

Adding a corrupt video crashes/confuses Blender
Closed, ResolvedPublic

Description

System Information
Operating system: Windows 7
GPU: Radeon Vega 64, Divider version: 19.4.1
CPU: Intel Core i7-5960X

Blender Version
Broken: blender-2.81.0-git.d8fb63661b32-windows64
Broken: 2.80
Worked: 2.79b

Short description of error

Loading a corrupted video in 2.80 will crash Blender, in 2.79b the video simply won't load.

  • This can happen in two ways:
    1. When first opening the VSE, having the frame rate try to match the first video that's imported.
    2. If the frame rate is already set, once the playhead reaches the corrupt part of the video.

Exact file for others to reproduce the error from scratch

I can't find a corrupt video other than this one (and I didn't have the heart to upload 4 gigs to phab)

The video stream in intact upto about 2:20. Download Here

See description for reproduction steps.

Event Timeline

Christopher_Anderssarian triaged this task as Waiting for Developer to Reproduce priority.

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

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.

Sybren A. Stüvel (sybren) lowered the priority of this task from Waiting for Developer to Reproduce to Confirmed, Medium.EditedThu, Sep 19, 1:51 PM

I can confirm problems with this video file, but I cannot confirm the crash of Blender. I have some ideas to handle the corruption, though.

Here is a smaller example file that's corrupted in a similar manner: the number of frames is way too high: F7758185. The patch in D5853 has a heuristic that corrects this error.

Sybren A. Stüvel (sybren) renamed this task from Adding a corrupt video crashes Blender to Adding a corrupt video crashes/confuses Blender.Thu, Sep 19, 1:53 PM

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.