Page MenuHome

Rendered frame shifted while using sequencer
Closed, InvalidPublic


Hello guys...

Frame rendering is shifted while using the scene in the sequencer.

In my file, i render an image in the viewport : current frame 60
If the start sequence is set to 60 for exemple, the rendered frame will be 120

In fact, the amount of the start sequence and the current frames are added.

If i delete the scene in the sequencer, render is normal.

Blender: 2.62.2 r45110

CPU: AMD Phenom II X6 1100T
RAM: 8Gb
GFX: nVidia GTX 580, 1536MB
OS: Ubuntu 11.04 x86_64
Kernel : 2.6.38-13-generic
Drivers: Forceware 290.10

Event Timeline

Behavior was changed in svn rev44068 and now scene strips are using start frame from scene's settings. In your case you're putting the same scene into a sequencer and changes start frame of this scene. This introduces that offset you're talking about.
In fact both of current and old behavior makes sense, but old behavior implied storing start frame on a time when you're adding new scene strip and you cannot change it anymore which si weird. New behavior is much more useful for animators' workflow.
Wouldn't actually consider this is a bug.

Ok, thank you Sergey to investigate. I might be wrong but i'm afraid that the things are not so... simple for me.

For you information... In fact, i'm using the time remapping and the superposition of rendered step frames to obtain a motion blur effect with cycles.
I'm using the frames steps offset and the sequencer to combine 16 channels of the same scene in the sequencer. Each scene or channel has an offset of -1 frame.
For exemple channel zero start à 0, channel 1 start at -1, channel 2 at -2, etc.... until 15.

(originally from Max Hammond works :

So... Everything worked fine until the revision 45110 i presume.. maybe before. I noticed a commit in the sequencer at r45068...
Anyway, before this revision i was able to use the same scene in the sequencer without having an offset trouble. And i was able to start my animation at any desired point too. And its far after the revision 44068. (I update blender every two days or so.)

For the time being, i'm unable to start my animation as before this build at a random start point without this start point being doubled internally.
Start point 10480 makes the rendered frame equal to 20960 but saved as number 10480. I'm ok to consider that is not a bug but.. there's something wrong for my own opinion.

If i deactivate the sequencer checkbox in the Post-processing section of the render panel. I can start my animation at the frame desired but the other frames (frame steps) are not rendered.

Another thing i've noticed while writing those lines. In my sequencer, and since recently, two of my channels (13 & 14) are superposed on the same channel. (13) You are OK with me that if you grab manually a scene and want to put it over another scene, this grabbed scene is automatically placed before (maybe occasionally after) the one you wanted to "mix or override". That never happen that two scenes are on the same time on the same channel... Am i wrong ? Anyway, i really carefully placed my scenes on each channel when i set up my animation. And now two of them have collapsed into one.

And.. a new 16th scene on the 15th channel has been created. .. I've never added this channel because i only needed 16. So with the zero channel + 16 other channel, i have 17 channels of the same scene for a frame step of 16. something is wrong here...

An alternative i've found to continue my actual work is to render the new frames in an other folder and start at half the point i want to restart my animation. This way, the rendered frames don't override the other i've rendered before..

For your information too. I have 850 images in my animation and each combined images takes approximately 15 minutes to render. Because I can't let my computer working day and night at the moment, i have to restart each day at the point i stopped the day before.

So.. I hope that everything make sense and you would consider reopen this bug report. Beause there is a bug for my own perpective.

Thank you.

Well, still don't think it's indeed a bug, for me it works in much more predictable way as it was before. Using such a tring to deal with moblur in cycles is more a workaround way and shouldn't actually be solved in such a way.
But discussed with Campbell and probably it'll be useful to have independent setting for start/end frame.
Peter, i hope you can handle this report.

Hello Peter and Sergey...

Returning back sfra property in the sequence structure didn't changed anything for me. So i don't think that the offset come from here.
But, you already knows that i'm not a dev.
I tried today on a windows 32 bit system with a build from graphicall. rev 45201 and my report.blend react as in my own build on linux. (rev45133)

One thing i wanted to know... Do you actually have the same frame offset with my report.blend ?
I begin to wonder if i'm not dealing with a wrong way to make such things...
I mean, it's not an incorrect way to use blender if you put your actual scene in the sequencer... right ?
So... i should be able to start my animation at 30 without having the 60th frame being rendered and saved as the 30th.

If i do something incorrectly, please let me know...

About my moblur workaround. I precise that this way to obtain it is a efficient way because you can have reflection and refraction too.
Anyway... workarounds are commonly used in the community... Result is the goal. ( ^_ - )

Than you

Hello All !!

First... I want to apologize if i messed up the buildslave and rebuilded the 45065 as the latest build in buildbot this day.
I was pretty sure to rebuild it for myself ONLY. You should have seen me turning to green behind my screen when i saw my build in the buildbot...
(Saying that, i should not have access to that function... : / )
Sorry for that !!

So... I rebuilded r45065 and the issue is not present in that build. I can start my animation at any desired point and render an image without encountering an offset issue.
That makes me think that the commit 45068 has something to do with that bug report.

For being as clear as possible... The issue is easily reproducible.
- Create a new scene.
- Add the current scene in the sequencer.
- clic the Checkbox sequencer in the port-processing section of the render panel.
- Start a render animation at any desired point above 1.
- You should have the rendered frame with an offset of twice the amount of the "start frame" value.
- Rendered frames will be saved normally but with that offset.

Thank you for your time and sorry again for my "rookie" mistake.

Hi Jérôme,

problem is: the behaviour you want to restore, I actually consider a misbehaviour.

To make it more clear, why the old thing was actually a bug:

when you added a SCENE strip to the sequencer, the start frame was pulled from the scene and pushed into the scene strip data, left there unchangeable.

That means: if you wanted to change the start point within the scene afterwards there was no way to propagate that change into the SCENE strip within the sequencer (well, there was, you could always change the scene back and forth to force a reload, but that isn't that nice).

And: adding the same scene into the sequencer isn't such a bright idea either. Most people just use that for testing purposes and I think, displaying a black frame to prevent an eternal loop could be just as well justified for that use case.

So: may I ask, why you don't just add another scene and put that into your timeline?


... maybe something you haven't tried (you can try that with an older release, to see the same "offset problem"):

* start up blender
* change the start frame of the scene to 60
* add your little cube animation
* go to the sequencer timeline and add your scene strip
* be surprised, that you will see the same offset, you opened the bug report to begin with.

I hope we can agree, that the start of a SCENE strip shouldn't be dependend on the order of operations, right?


Hello Peter,

Well i made my tests with those new informations and as i expected... And since r45068, i don't use the sequencer as it should be used.

If i summarize correctly, the new normal way is :
- to create a new scene to put the sequence on
- to create a new scene of linked objects to be used in the sequencer of the current scene

Well.. I always used the sequencer in the now called "old" behavior manner and i always found logical to set my start frame to zero before importing my scene. The reason why i never had a problem with that "old" behavior is that you instantly see where the problem is.

Since two days i was wondering why anyone would consider that there's a bug... And sincerely, i didn't thought one second that this wasn't a bug. I never expected that the simple use of the sequencer could be complicated that way... And you actually have to resolve an offset issue unlogically. Unless you are aware on how to make an efficient set up.

For my humble opinion, this new behavior act as it is bugged if you use the sequencer logically. I'll not be surprised that this behavior could be debated in the future. (Just think to the newbies )

So.. i guess that this "false bug" report can be closed but there's one thing i have to request before... Now that you have changed that behavior, at least.. make the importing of the current scene in the current scene sequencer not possible. Such like the current scene not appearing in the add scene selection menu.

Thank you guys for your time and efforts.
Jérôme A. Scaillet.

Oops... "Unlogically" (AH AH) ... I meant "Illogically" of course !

Peter Schlaile (schlaile) changed the task status from Unknown Status to Invalid.Aug 6 2012, 7:37 PM