VSE: In Speed strip's multiply mode is the last frame getting "stuck". #90920

New Issue

tintwotin · 2021-08-25T16:44:16+02:00

tintwotin commented

2021-08-25 16:44:16 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 462.59

Blender Version
Broken: version: 3.0.0 Alpha, branch: master (modified), commit date: 2021-08-25 08:10, hash: 452cc01932
Worked: (newest version of Blender that worked as expected)

Short description of error

Add a speed strip.
Add a keyframe at ex. 1, then later at 4, then later at -4 then later at 4.
Notice when the curve is dropping that when lower than ex. -1 is reached it should start playing reverse, but it keeps frozen for some time until the curve starts climbing again.
The expected behaviour is that that should play reverse immediately on negative values, no matter how long it has been stuck at the last frame(< is this somehow related to the duration of the dead zone?).
{F10325121,size=full}

Run this test file to quickly see the "dead zone":
Speed_strip_test.blend

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce RTX 2060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 462.59 **Blender Version** Broken: version: 3.0.0 Alpha, branch: master (modified), commit date: 2021-08-25 08:10, hash: `452cc01932` Worked: (newest version of Blender that worked as expected) **Short description of error** - Add a speed strip. - Add a keyframe at ex. 1, then later at 4, then later at -4 then later at 4. - Notice when the curve is dropping that when lower than ex. -1 is reached it should start playing reverse, but it keeps frozen for some time until the curve starts climbing again. The expected behaviour is that that should play reverse immediately on negative values, no matter how long it has been stuck at the last frame(< is this somehow related to the duration of the dead zone?). {[F10325121](https://archive.blender.org/developer/F10325121/deadzone1.gif),size=full} Run this test file to quickly see the "dead zone": [Speed_strip_test.blend](https://archive.blender.org/developer/F10325124/Speed_strip_test.blend)

tintwotin commented

2021-08-25 16:44:16 +02:00

Added subscriber: @tintwotin

tintwotin changed title from ~~VSE: Speed strip multiply mode freezes~~ to VSE: In Speed strip's multiply mode is the last frame getting "stuck".

2021-08-25 17:01:34 +02:00

Richard Antalik commented

2021-08-26 04:34:14 +02:00

Added subscriber: @iss

Richard Antalik commented

2021-08-26 04:34:14 +02:00

Changed status from 'Needs Triage' to: 'Archived'

Richard Antalik closed this issue

2021-08-26 04:34:14 +02:00

Richard Antalik commented

2021-08-26 04:34:14 +02:00

Speed effect in this mode assumes infinite strip duration and therefore this is expected behavior. I don't think, that changing this behavior would be good idea.

tintwotin commented

2021-08-26 07:56:28 +02:00

I remember you mentioning complaints concerning unreliable results. This is the only unreliable result I've come across in the speed strip so far.

How are users to know that their source material should be "infinite"? How are users to know that they are not supposed to let it "run out of frames", because it makes it impossible to predict when it'll start again?

For users this will be considered a bug, making it very difficult or in some cases impossible to work in the multiply mode.

If this is something you're not able to fix, then consider marking it as Known Issue instead.

I remember you mentioning complaints concerning unreliable results. This is the only unreliable result I've come across in the speed strip so far. How are users to know that their source material should be "infinite"? How are users to know that they are not supposed to let it "run out of frames", because it makes it impossible to predict when it'll start again? For users this will be considered a bug, making it very difficult or in some cases impossible to work in the multiply mode. If this is something you're not able to fix, then consider marking it as Known Issue instead.

Sergey Sharybin commented

2021-08-26 11:02:44 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2021-08-26 11:02:44 +02:00

The speed effect "just" remaps current frame to a new one and renders underlying strip with that new frame. The new frame will be clamped to the strip frame range at that strip render time (at least how I remember it). This means that if the original strip doesn't have enough frames to remap to you will have the clamping behavior you observed: it takes a bit for the frame calculated by the speed effect to fall back into the original strip's frame range.

This is how the speed strip is implemented. Is far from ideal, we do want it to be much better and more user friendly, but this is not something we can resolve as part of a bug tracker work. Bug tracker is for fixing bugs within the current design. Changing weak design with something new happens as more of a project work which requires its time planning, design work, and other things.

As for making it a Known Issue think you are correct: is a known shortcoming from a weak design.

The speed effect "just" remaps current frame to a new one and renders underlying strip with that new frame. The new frame will be clamped to the strip frame range at that strip render time (at least how I remember it). This means that if the original strip doesn't have enough frames to remap to you will have the clamping behavior you observed: it takes a bit for the frame calculated by the speed effect to fall back into the original strip's frame range. This is how the speed strip is implemented. Is far from ideal, we do want it to be much better and more user friendly, but this is not something we can resolve as part of a bug tracker work. Bug tracker is for fixing bugs within the current design. Changing weak design with something new happens as more of a project work which requires its time planning, design work, and other things. As for making it a Known Issue think you are correct: is a known shortcoming from a weak design.

tintwotin commented

2021-08-26 11:09:15 +02:00

@Sergey Thank you for your comment, however I'm afraid marking it as a know issue doesn't matter much, if the issue is still left closed, was that by intent?

Sergey Sharybin commented

2021-08-26 12:00:25 +02:00

Changed status from 'Archived' to: 'Confirmed'

Sergey Sharybin reopened this issue

2021-08-26 12:00:25 +02:00

Sergey Sharybin commented

2021-08-26 12:00:25 +02:00

I've just changed the subtype, didn't pay much attention to the status. Indeed non-resolved known issues should have open status.

tintwotin commented

2021-08-26 19:59:24 +02:00

@Sergey With this lhis line inserted does make the curve actually make sense - it'll play backwards on negative values - and forward on positive values - but does it break anything?

diff --git a/source/blender/sequencer/intern/effects.c b/source/blender/sequencer/intern/effects.c
index d4adad9a34d..de5c8c3a402 100644
--- a/source/blender/sequencer/intern/effects.c
+++ b/source/blender/sequencer/intern/effects.c
@@ -3153,6 +3153,7 @@ void seq_effect_speed_rebuild_map(Scene *scene, Sequence *seq)
   float target_frame = 0;
   for (int frame_index = 1; frame_index < effect_strip_length; frame_index++) {
     target_frame += evaluate_fcurve(fcu, seq->startdisp + frame_index);
+    CLAMP(target_frame, 0, seq->seq1->len);
     v->frameMap[frame_index] = target_frame;
   }
 }

{F10329688,size=full}

My test file:
Multiply_broken.blend

@Sergey With this lhis line inserted does make the curve actually make sense - it'll play backwards on negative values - and forward on positive values - but does it break anything? ``` diff --git a/source/blender/sequencer/intern/effects.c b/source/blender/sequencer/intern/effects.c index d4adad9a34d..de5c8c3a402 100644 --- a/source/blender/sequencer/intern/effects.c +++ b/source/blender/sequencer/intern/effects.c @@ -3153,6 +3153,7 @@ void seq_effect_speed_rebuild_map(Scene *scene, Sequence *seq) float target_frame = 0; for (int frame_index = 1; frame_index < effect_strip_length; frame_index++) { target_frame += evaluate_fcurve(fcu, seq->startdisp + frame_index); + CLAMP(target_frame, 0, seq->seq1->len); v->frameMap[frame_index] = target_frame; } } ``` {[F10329688](https://archive.blender.org/developer/F10329688/speed_fix.gif),size=full} My test file: [Multiply_broken.blend](https://archive.blender.org/developer/F10329707/Multiply_broken.blend)

Richard Antalik commented

2021-08-27 01:49:26 +02:00

I don't necessarily agree, that this issue caused by weak design, maybe this should be investigated within scope of particular workflows.

You could apply same question to animation of image position - why, when it goes off screen, it doesn't return immediatelly when curve value goes back from it's maximum? Obviously if you change image size, it would break whole animation. Issue here is bit different, because curve value is integrated, but currently media interchangability is preserved at least partially.

I don't necessarily agree, that this issue caused by weak design, maybe this should be investigated within scope of particular workflows. You could apply same question to animation of image position - why, when it goes off screen, it doesn't return immediatelly when curve value goes back from it's maximum? Obviously if you change image size, it would break whole animation. Issue here is bit different, because curve value is integrated, but currently media interchangability is preserved at least partially.

tintwotin commented

2021-08-27 07:17:55 +02:00

The suggested change: https://developer.blender.org/T90920#1212134 above will make a positive multiply value play forwards and a negative value play backwards.

It is working the same way as hitting the speeder in a car will increase speed(positive value) and hitting the brakes(negative value) will decrease the speed. This should be an easy to comprehend cause and effect for most users.

To me this seem more logic than the current design, where you hit the breaks, but the point of actually decreasing the speed of the car is dependant on how long time you have been driving at max speed.

If you have been driving a little less than max speed it'll decrease the speed immediately after you hit the brakes, but if you have been driving at max speed for ex. 5 minutes, hit the brakes and then you need to wait for 5 minutes for the car to decrease the speed. My guess is that for most users this concept is very hard to grasp, and is likely to result in bug reports.

The suggested change: https://developer.blender.org/T90920#1212134 above will make a positive multiply value play forwards and a negative value play backwards. It is working the same way as hitting the speeder in a car will increase speed(positive value) and hitting the brakes(negative value) will decrease the speed. This should be an easy to comprehend cause and effect for most users. To me this seem more logic than the current design, where you hit the breaks, but the point of actually decreasing the speed of the car is dependant on how long time you have been driving at max speed. If you have been driving a little less than max speed it'll decrease the speed immediately after you hit the brakes, but if you have been driving at max speed for ex. 5 minutes, hit the brakes and then you need to wait for 5 minutes for the car to decrease the speed. My guess is that for most users this concept is very hard to grasp, and is likely to result in bug reports.

Sergey Sharybin commented

2021-08-27 10:39:50 +02:00

One immediate drawback of the proposed change is that it will not work properly when combining two speed effects. Can also see that it might turn problematic when speed is applied on a scene strip (possibly, indirectly via a meta strip).

The fundamental issue I've got with the speed effect is that its effect and controls are so hidden from users. One never knows where re-timing takes affect, what's the final media duration in scene time and so on.

In general I'd say:

It would help a lot to see a practical example of what you're trying to achieve. There are always ways to break system with synthetic tests. Dealing with them is not a very good investment, since it takes time with not much actual outcome. If there is a clear real-world example then it makes you more motivated to work towards solution!
If the stakeholders in VSE project are fine with the proposed change, and are aware of consequences, and things are well-tested, I wouldn't mind this short-term solution.
If the solution is not something obvious and requires time for analysis and such, consider working on a better design for the re-timing tool which will give much better artists control and visual feedback.

One immediate drawback of the proposed change is that it will not work properly when combining two speed effects. Can also see that it might turn problematic when speed is applied on a scene strip (possibly, indirectly via a meta strip). The fundamental issue I've got with the speed effect is that its effect and controls are so hidden from users. One never knows where re-timing takes affect, what's the final media duration in scene time and so on. In general I'd say: - It would help a lot to see a practical example of what you're trying to achieve. There are always ways to break system with synthetic tests. Dealing with them is not a very good investment, since it takes time with not much actual outcome. If there is a clear real-world example then it makes you more motivated to work towards solution! - If the stakeholders in VSE project are fine with the proposed change, and are aware of consequences, and things are well-tested, I wouldn't mind this short-term solution. - If the solution is not something obvious and requires time for analysis and such, consider working on a better design for the re-timing tool which will give much better artists control and visual feedback.

tintwotin commented

2021-08-27 14:36:40 +02:00

Added subscriber: @mano-wii

tintwotin commented

2021-08-27 14:36:40 +02:00

@Sergey I've tried to add a speed strip on top of a speed strip with that line added, and it seems to be working as expected.
speed_on_speed.blend

I've also tried to add a scene with the speed strip, in another scene and add a speed strip there too, and also tried inside meta strips both places, and I do not see anything unexpected.
speed_on_scene_meta.blend

I hope you're aware of the work @mano-wii and I have put into improving the UX of Speed strips by exposing the speed strip options in the sidebar D11856 and the f-curve drawing D6110 on the strips?

I'm not sure what real world example you're after, but a clear connection between when playing backwards and forwards and negative and positive values, will make it much more intuitive to work with the multiply mode of the speed strip.

This is a "real world" example without the line(not working as expected):
{F10336097,size=full}

With that line added(where it is working as expected):
{F10336037,size=full}

Add ToS to this strip:
real_world.blend

@Sergey I've tried to add a speed strip on top of a speed strip with that line added, and it seems to be working as expected. [speed_on_speed.blend](https://archive.blender.org/developer/F10335784/speed_on_speed.blend) I've also tried to add a scene with the speed strip, in another scene and add a speed strip there too, and also tried inside meta strips both places, and I do not see anything unexpected. [speed_on_scene_meta.blend](https://archive.blender.org/developer/F10335928/speed_on_scene_meta.blend) I hope you're aware of the work @mano-wii and I have put into improving the UX of Speed strips by exposing the speed strip options in the sidebar [D11856](https://archive.blender.org/developer/D11856) and the f-curve drawing [D6110](https://archive.blender.org/developer/D6110) on the strips? I'm not sure what real world example you're after, but a clear connection between when playing backwards and forwards and negative and positive values, will make it much more intuitive to work with the multiply mode of the speed strip. This is a "real world" example without the line(not working as expected): {[F10336097](https://archive.blender.org/developer/F10336097/Speed_real_world_without.gif),size=full} With that line added(where it is working as expected): {[F10336037](https://archive.blender.org/developer/F10336037/Speed_real_world.gif),size=full} Add ToS to this strip: [real_world.blend](https://archive.blender.org/developer/F10336116/real_world.blend)

Sergey Sharybin commented

2021-08-27 15:41:44 +02:00

Added subscriber: @fsiddi

Sergey Sharybin commented

2021-08-27 15:41:44 +02:00

Thanks for tests! Good to know things worked for you. I've also run some tests locally (although, didn't have much time) and couldn't fault this specific change.

To me it does seem to be more expected behavior with the clamp. Especially in the world with weak user feedback on what's going where.
@fsiddi, @iss, do we really win from the "accumulation" manner of the current code?

As for D6110, don't think it goes far enough to really improve convenience of speed effect. But lets not go into this discussion in this bug report.

Thanks for tests! Good to know things worked for you. I've also run some tests locally (although, didn't have much time) and couldn't fault this specific change. To me it does seem to be more expected behavior with the clamp. Especially in the world with weak user feedback on what's going where. @fsiddi, @iss, do we really win from the "accumulation" manner of the current code? As for [D6110](https://archive.blender.org/developer/D6110), don't think it goes far enough to really improve convenience of speed effect. But lets not go into this discussion in this bug report.

tintwotin commented

2021-08-27 17:26:04 +02:00

(@Sergey A lot of hours have gone into D6110 and D11856 since work on that started in oct 2019, if you think that it is going in the wrong direction, it would have been nice to share that a bit earlier).

(@Sergey A lot of hours have gone into [D6110](https://archive.blender.org/developer/D6110) and [D11856](https://archive.blender.org/developer/D11856) since work on that started in oct 2019, if you think that it is going in the wrong direction, it would have been nice to share that a bit earlier).

Francesco Siddi commented

2021-08-27 19:38:23 +02:00

Had a look at this and also discussed with Sergey. Makes sense to me, go for it!

Richard Antalik commented

2021-08-31 02:00:40 +02:00

In #90920#1212504, @Sergey wrote:
@fsiddi, @iss, do we really win from the "accumulation" manner of the current code?

I did use this feature in practice to smoothly slow playback speed to 0, leave it there for a while, then restore speed back to normal. Technically this can be achieved by animating displayed frame number, but it is not as simple and user friendly. I heared other users use this effect to "freeze" time too.

Also to clarify, reversing playback with negative values is recent change implemented in 929d7597b3, so this can be reverted if such behavior is inappropriate.

> In #90920#1212504, @Sergey wrote: > @fsiddi, @iss, do we really win from the "accumulation" manner of the current code? I did use this feature in practice to smoothly slow playback speed to 0, leave it there for a while, then restore speed back to normal. Technically this can be achieved by animating displayed frame number, but it is not as simple and user friendly. I heared other users use this effect to "freeze" time too. Also to clarify, reversing playback with negative values is recent change implemented in 929d7597b345, so this can be reverted if such behavior is inappropriate.

tintwotin commented

2021-08-31 07:18:35 +02:00

! In #90920#1213677, @iss wrote:
I did use this feature in practice to smoothly slow playback speed to 0, leave it there for a while, then restore speed back to normal.

This can also be done with the suggested change:
{F10355751,size=full}

The suggested change do only have an effect on on what value it'll start playing reverse. With the change this point is a at 0, without the change, and if the user has run out of frames this point of reverse playing is unknown.

>! In #90920#1213677, @iss wrote: > I did use this feature in practice to smoothly slow playback speed to 0, leave it there for a while, then restore speed back to normal. This can also be done with the suggested change: {[F10355751](https://archive.blender.org/developer/F10355751/hold_strips_super_slow.gif),size=full} The suggested change do only have an effect on on what value it'll start playing reverse. With the change this point is a at 0, without the change, and if the user has run out of frames this point of reverse playing is unknown.

tintwotin commented

2021-09-03 18:31:31 +02:00

Removed subscriber: @tintwotin

tintwotin commented

2021-10-26 08:48:08 +02:00

Changed status from 'Confirmed' to: 'Archived'

tintwotin closed this issue

2021-10-26 08:48:08 +02:00

tintwotin commented

2021-10-26 08:48:08 +02:00

As I do not have anymore time or motivation for a continued investment in the Blender project, I'm giving up on this report for now.

Philipp Oeser commented

2021-10-26 09:22:38 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-10-26 09:22:38 +02:00

Changed status from 'Archived' to: 'Confirmed'

Philipp Oeser reopened this issue

2021-10-26 09:22:38 +02:00

Philipp Oeser commented

2021-10-26 09:22:38 +02:00

Sorry to hear (thx again reporting). In my opinion we should not sweep this under the carpet (esp. since this already been confirmed), there is still a chance to get this fixed in the future and others might be affected by this issue as well.
Feel free to unsubscribe though.

Sorry to hear (thx again reporting). In my opinion we should not sweep this under the carpet (esp. since this already been confirmed), there is still a chance to get this fixed in the future and others might be affected by this issue as well. Feel free to unsubscribe though.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

VSE: In Speed strip's multiply mode is the last frame getting "stuck". #90920