Page MenuHome

Blender 2.70a regression crash during image sequence animation rendering
Closed, ResolvedPublic


System Information
Operating system and graphics card
winxp sp3

Blender Version
Broken: Blender 2.70a stable (and some buildbot i tried, though not tried latest one as the win32 builds are missing dll as reported already)
Worked: (optional) : Blender 2.70 stable

Short description of error
A simple image sequence animation rendering very badly crash in stable Blender 2.70a while worked perfectly on previous 2.70 stable.

Exact steps for others to reproduce the error

  • Extract the 233 png files from this archive into a folder (don't right click -> save as on the link, it's leading to dropbox download page, not directly to the file)

  • In Blender click on File then Load Factory Settings
  • Make sure you're in Blender Render mode (should be with factory settings)
  • On the top header select the Video Editing layout
  • On the upper right window (the video sequence editor panel that in the layout is set by default to "Preview" ) split the window vertically, and set the new window to the right of it to be the Properties panel
  • In the Properties panel at the Dimension tab change the default "Y:1080" into "Y:1883" and change the default "50%" into "30%"

Change the Framerate to 29.97
Scroll down and disable Antialiasing
Scroll down and change the output from the default "PNG" to "H.264" and enable "RGB"

  • Now Back to the video sequence editor window (the window on the bottom, above the timeline) that is set by default to "Sequencer"
  • Click on Add then on Image, and go select all the 233 png files in the browser and click on the Add Image Strip button to load them all into the sequencer.
  • Now in the Properties panel click on the animation button to render as an animation file.

In stable Blender 2.70 stable you will obtain the desired .avi file without a problem.

In Blender 2.70a stable it will crash before rendering anything with the classic window message "blender encountered a problem etc..."
AppName: blender.exe AppVer: ModName: blender.exe
ModVer: Offset: 00e510a0



Event Timeline

Sanc Tuary (sanctuary) updated the task description. (Show Details)
Sanc Tuary (sanctuary) raised the priority of this task from to Needs Triage by Developer.
Sanc Tuary (sanctuary) set Type to Bug.

I've followed exactly your steps. Results:

XP SP3 (32 bit), Blender 2.70a official: Crash
Win7/64, Blender 2.70a 32 bit: Crash
Win7/64, Blender 2.70a 64 bit: works

thanks for trying, so it looks like this 2.70a nasty regression is affecting 32 bits builds only.

Bastien Montagne (mont29) triaged this task as Normal priority.Apr 20 2014, 9:34 PM
Bastien Montagne (mont29) raised the priority of this task from Normal to Confirmed, High.

This bug did not work for me & I'm using a Windows 7 Professional, and what I recommend to make it work for you is after you set the format to H.264 is go the the encoding panel & set the format from AVI to Quicktime to render the sequence out as a Quicktime movie file. This probably won't work for you if you set it to AVI, since AVI make huge files depending on what codec you use. So, try that and see what happens.

If it's working for you, to confirm that this nasty regression bug is affecting 32bits only, are you using the 64bits version of Blender on your system ?

Yes. I forgot to mention that. I am using the 64-bit version of Windows 7 Professional, but it should work on any version & system of Windows if you set the format to Quicktime and not AVI. It's always worth a try.

the problem is not about finding a workaround with different format as it's not a support question but a bug report, the problem is that this is a very bad regression bug that lead into a crash on 32bits builds (confirmed by you not having a problem with it on 64bits ones) on the stable 2.70a release, while it worked perfectly on the stable 2.70 one.

Let me see if I can reproduce this on MinGW

Some update as i think this could be useful as it shows something strange to add on that bug :

After reading psy_fi mention of MinGW it reminded me that i never tried this on a vs2012 win32 buildbot i am using (as the vc2008 win32 version is currently broken with missing dlls) .

So i used the blender-2.70-1e39046-win32-vc12 i got from the buildbot from some days ago , and followed the steps i mentionned on the bug report opening.
Then i pressed the Animation button ... and it worked without crashing to my surprise.

Then i made another test, i used the "stable" win32 2.70a (the vc2008 version i guess) that is crashing 100% of the time on those steps, and before pressing the Animation button i saved as a blend.
Pressing "Animation" as expected lead to a direct crash.

Now i loaded that blend in blender-2.70-1e39046-win32-vc12 (with load ui enabled) and while it does not crash, it does not render the animation, and after a few seconds of being stuck once pressing the Animation button it will display an error message i never saw before :
in the case the image does not work :
Error setting option flags2 to value fastskip.

For convenience of reproducing, i uploaded a blend here (don't right click and save as, this link is going to the dropbox download page) :

As i can't pack the image sequence apparently, in the videocrashtest5.rar archive you can download, i added the folder seq402 that contain the png images required.

Because paths are relative, make sure to have the folder named seq402 in the same location in which you'll put the blend for testing so it can find the images without problems.

Can't reproduce on MinGW either.

looks like it's related to the vc2008 version of 2.70a stable then, i wonder what was different from the 2.70 stable (that unless i'm mistaken was vc2008 too).

But do you obtain the "Error setting option flags2 to value fastskip" message in your MinGW if you load the blend i added in my previous post and press the Animation button ?

Back to the original bug, as the "Error setting option flags2 to value fastskip" is very likely a different one.
I tried the latest vs2008 buildbot on win32, blender-2.70-d964bad-win32 , ( after renaming the dll to make it work as mentionned in my last post of that report ) and i found out that following exactly the steps i mentionned on the original bug report (and that previously insta-crashed Blender on "stable" 2.70a and further vs2008 builbots) is now delivering the wanted result without crashing now.

So i guess one of the many commits since the last time i tried a vs2008 build has solved the problem without knowing. Odd that it has always worked perfectly on the vs2012 builds tough.

Bug report can probably be closed now as it does not crash anymore.