Page MenuHome

Strip keyframes not respected for scenes rendered by other scenes
Closed, ResolvedPublic


System Information
Linux openSUSE 13.1 x64, KDE 4.14.1. Radeon HD 6870, FOSS video driver (Gallium / Mesa).

Blender Version
Broken: 2.71

Short description of error
Key frames on some properties of image / video / audio strips are not respected when the scene is rendered by another scene through a scene strip. I noticed this with the "volume" and "pitch" options of a wav sound strip in a scene, as it was rendered from another scene meant to export multiple scenes in order.

Exact steps for others to reproduce the error
1 - Make sure you have two scenes. Let's say Scene.1 and Scene.2, both starting at frame 1 and ending at frame 250.

2 - Open up a Video Sequence Editor window. In Scene.1, go to Add -> Sound and add a sound strip using any audio file on your drive.

3 - Now key the volume of the sound strip you just added, within the properties sidebar (N key). For example, to make a simple fade in / out effect: Frame 1 = Volume 0.0, Frame 50 = Volume 1.0, Frame 200 = Volume 1.0, Frame 250 = Volume 0.0.

4 - While still in the Video Sequence Editor window, switch over to Scene.2. In this scene, go to Add -> Scene and select Scene.1.

5 - In the Render panel, click the Audio button (previously called Mixdown Audio) and export the scene's audio to a wav file. Do this for both scenes to compare.

Issue - If you export the audio of Scene.1 (where the sound strip is located), the volume will change according to how it was key framed. But if you render the audio of Scene.2 (which renders Scene.1), the volume of the sound strip in Scene.1 will not change according to how it was keyed, and appears to use the value detected at the first frame.

Event Timeline

Mircea Kitsune (mirceakitsune) raised the priority of this task from to Needs Triage by Developer.
Mircea Kitsune (mirceakitsune) updated the task description. (Show Details)

The way that the sequencer interacts with the animation system and the dependency graph is shaky at best. What's probably going on here is that the updated animation isn't getting flushed to the sound system for whatever reason (since we can rule out the animation not getting evaluated due to some other crippling bugs around here).

Sergey Sharybin (sergey) lowered the priority of this task from Needs Triage by Developer to Normal.Sep 22 2014, 1:40 PM

Argh, wrong commit number, reopening

Sergey Sharybin (sergey) closed this task as Archived.EditedJul 29 2016, 12:42 PM
Sergey Sharybin (sergey) claimed this task.

Oops, replied to a wrong report...