Testbuilds up https://builder.blender.org/download/patch/

CCing @Campbell Barton (campbellbarton) only for the case of ED_autokeyframe_property being called from a gizmo

I have split this up in multiple reports (claimed the first three related to autokeying for now), see
T98429: VSE autokeying transforms in preview only creates keyframes for rotation/scale if rotating/scaling around cursor (should keyframe position as well)
T98430: VSE autokeying transforms in preview only creates keyframes if there is an FCurve already
T98431: VSE autokeying transforms in preview does not work during animation playback
T98432: VSE unkeyed transforms in preview persist in cache
T98433: VSE keyframed transforms in preview persist in cache after keyframes have been cleared

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

@Richard Antalik (ISS): you also have not commented on the "persting-after-clearing-animation" issue (if this is a duplicate of the mentioned report)

I think it makes sense to split this report up in multiple reports (will do that).

But I can reproduce difference in color strip animation when scene strip is enabled/disabled, so I guess this would be enough to investigate.

@forceengine Yes I can check on Linux, but not really debug at least easily. But since you report different OS to be working correctly which implies different settings, can you check if you have disk cache enabled on Linux installation and if issue will happen when you disable it?

Ah right that's correct. Not sure what would be good solution. Sounds to me that in case when property is animated, cache entry should be created only when keyframe is inserted, but even that is not quite enough - it would have to check if all properties that were changed were keyed. Looks quite complicated to handle this.

In T98287#1363806, @Richard Antalik (ISS) wrote:

I don't understand how can I see the issue from provided still frame in comment above - what frame number is that? Looks like frame 61, which is what I see in preview. Is that incorrect?

If I can reproduce on windows, it would help a lot, because I don't have linux machine with dev environment set up.

In T98015#1364664, @Richard Antalik (ISS) wrote:

In T98015#1364264, @Philipp Oeser (lichtwerk) wrote:

However, I am not sure how to prevent the "hop" when transforming (but not actually setting a keyframe)

If I understand this correctly, the "hop" frame from report was the only correct frame, since it was rendered after transformation was done. So I would say if keyframes would be set this would not happen.

Yes, if you would set a key there, this would be fine.
But if you dont set a key there [which is totally fine], this is wrong. And this has nothing to do with autokey or the cursor rotation (see my previous example/comment).
Once you change frames, the unkeyed change needs to vanish (but atm. it remains in the cache).

In T98015#1364264, @Philipp Oeser (lichtwerk) wrote:

However, I am not sure how to prevent the "hop" when transforming (but not actually setting a keyframe)

In Blender 2.x I could export any video resolution I wanted and it did the business, now in 3.x a project seems to be stuck at whatever resolution it was started in. Is there a work around for this?

I just investigated a bit and it seems like this bug was introduced by @Sergey Sharybin (sergey) in rB89946834a17 with an improper fix for the issue of a Camera strip playing audio. I assume he never tested setting it back to Sequence afterwards. @Sergey Sharybin (sergey) can you fix this please?

Well, theoretically you only have to call BKE_sound_add_scene_sound[_defaults] when the sound of a scene should be played and call BKE_sound_remove_scene_sound when you want to remove that sound again using the handle you got as return value from the first call. So all you should have to do is to make sure that for a scene strip with input Camera this is not called at all or removed if it is changed and vice versa for the input Sequencer.

@Richard Antalik (ISS): I have most of the autokeyframing improvements done (will clean up the patch and post tomorrow)

Also noticed this should probably respect autokeying setting which relate to Keyingsets (will also check on that) as well as Replace / Add & Replace -- not sure about Layered Recording (but is worth checking also.

Also noticed that autokeying image transforms in preview only works if you have a keyframe already (this is inconsistent with auto keyframing elsewhere, will also check on that)

@Richard Antalik (ISS): what about the persistence thing then? should we split that off of this report?

I can reproduce the issue. What seems to be happening is that the red color strips have animations that sometimes gets evaluated at the active scene frame and sometimes gets evaluated at the frame of the scene of the scene strip of the clock.
While they should always be evaluated at the frame of the active scene as far as I can tell.

Seems to happen with many files, but here is this particular one.

Can you provide video file? I can't reproduce still. Could be ffmpeg issue as well.

Ah sorry I did rotation around strip pivot point, not 2D cursor. So I can reproduce and indeed I think that position should be keyframed in this case.

I am checking on Windows, so this could be the reason for me not being able to reproduce. From videos in description it looked to me that issue is flickering of animated color strip. I don't understand how can I see the issue from provided still frame in comment above - what frame number is that? Looks like frame 61, which is what I see in preview. Is that incorrect?

In T69444#1363761, @Joerg Mueller (nexyon) wrote:

In T69444#1363251, @Richard Antalik (ISS) wrote:

There are developers that seem to be able to implemet features in audaspace though so hopefully.

How is this an issue in audaspace? For me it sounds this issue has to do with the blender side of things? I wonder if this is one of the issues introduced with the depsgraph?

In T69444#1363251, @Richard Antalik (ISS) wrote:

There are developers that seem to be able to implemet features in audaspace though so hopefully.

In T98287#1362823, @Omar Emara (OmarSquircleArt) wrote:

It seems the file does not include the images necessary to make the clock, so I can't exactly replicate the sequence. Can you pack into the file or attach the necessary images?

I am not sure how useful restriction of cache used for only short audio. It is not uncommon to work on a montage of multiple longer videos files: things like reels, tutorials, etc.

I can confirm (both the persistence after clearing the animation as well as the "hop").

In T69444#1363251, @Richard Antalik (ISS) wrote:

In T69444#1362516, @gilad (giladf11) wrote:

Hi, is this bug going to be fixed anytime soon? is there any workaround for the meantime?

Anytime soon I can't tell. I am not sure if there exists infrastructure to handle this issue. There are developers that seem to be able to implemet features in audaspace though so hopefully. For workaround, I would think that duplicating scene and using one solely for sound and another for image would work?

Adjusting any property invalidates the cache and also fixes the issue.

Reopening the file fixes the issue, so it seems to be a cache issue indeed.

Disk cache is not enabled.

In T69444#1362516, @gilad (giladf11) wrote:

Hi, is this bug going to be fixed anytime soon? is there any workaround for the meantime?

I often see errors mentioned above, but these do not affect image output.

I agree that this was not great change, so will consider this as a bug.

I just wanted to mention, that I will accept whatever solution you and @Joerg Mueller (nexyon) will agree on, and sequencer stuff looks mostly reasonable. Only thing that stands out a bit for me is soundeqs field of Sequence. It's not really bad to have this separated from image modifiers, but if there should be more sound modifiers, I think, that these should be wrapped in more generic struct(similar to image modifiers), but this is probably detail compared to actual sound stuff.

This doesn't quite look like one of issues above, cache should be cleared since strip property was changed. I can't reproduce this issue with steps provided.

In T98168#1360793, @Pratik Borhade (PratikPB2123) wrote:

Yes, can confirm with meta strips.
I found a few reports which are probably related to this-
T71723: VSE (2.81): Copy-pasted meta strips lose all key frames
T68160: Keyframes lost when copy-pasting strips
I'm not sure if behavior is same since these reports (haven't tested myself on older builds).
@Richard Antalik (ISS), Is this a known issue?

@Omar Emara (OmarSquircleArt) @Melan Meilsheim (Deckelmouk) I can't reproduce this issue, can you provide .blend file where this happens?

@Evan Wilson (EAW) Seems very similar indeed, I will merge. Thanks!

This report reminds me of T60947: FFMpeg color offset. Possible duplicate?

I can replicate the difference in MPV even with lossless output. But I am not sure if this difference is expected, so tagging the module for more information.

If I hold split a sequence at frame 22, the start of the second strip will have frame 18 as its first frame, then it continues normally starting from 22.

It seems the file does not include the images necessary to make the clock, so I can't exactly replicate the sequence. Can you pack into the file or attach the necessary images?

Looks like the defaults were broken when the new socket builder was used: rB5ef5a9fc2466. I tried going through the diff again to spot other differences but this seems like the only node that got lost in translation.

Hi, is this bug going to be fixed anytime soon? is there any workaround for the meantime?

This looks better already.

Well, you could add a setting to automatically enable caching, when the audio files are shorter than a specific length. Another option instead of using caching is to use proxies like done for video. I.e., convert the audio streams of the video file to PCM/wav/uncompressed audio for immediate seeking without performance issues.

Was this fixed? I don't want to deal with update just to find out its still not working, thanks!

i noticed also that if we set rotation 600° as preset then rotate using shortcut 'R' 'without any change'we can notice that the value will go to between 0° and 360°.
so there is a modulo by 360° which it will miss with any animation that was done .....

I can confirm.
Although the header and transform values are inverted, maybe they could match a little better.

Thanks for the report, but it's not a leak. It's just the caching system.

thank you

If you switch on View Caching, you'll see that it is caching the individual frames when moving the playhead. And the cache is flushed when moving a clip.

Though the issue here can be fixed by changing blend mode, it is very likely other users will encounter the same problem and report it again as a bug. If the ambition of the VSE is that "it should just work", then the default blend mode for Adjustment Layer should probably be Replace. IMO, @Sergey Sharybin (sergey) or @Richard Antalik (ISS) should reflect on this report before it is closed.

Good to hear.
Since this have no performance implications and multiple options are given, we can archive this.

In T98057#1357410, @Omar Emara (OmarSquircleArt) wrote:

@hamza.SMA (hamza.elbarmaki) Actually, can't you just change the blend mode of the adjustment strip to be Replace?