More Blender VSE tidbits · Aras' website

Here&rsquo;s a bunch of random things that happened in Blender Video Sequence Editor (VSE) since the<br>previous blog post.

For the full picture check out VSE related release notes of Blender 5.1,<br>5.2 and upcoming 5.3.<br>Below I&rsquo;m mentioning only the things that I have done, or was somewhat adjacent to the things being done.

Compositor ❤️ VSE

Blender 5.0 added compositor based strip modifiers:<br>in addition to a handful of existing modifiers for visual strips (mostly various color adjustments), you<br>can now make completely custom modifiers that are driven by a compositor node tree. So now you can do anything<br>that Blender compositor nodes allow you to do. Nice!

However, that was only the initial glimpse of the things to come, and it required quite some follow-up work<br>in order for it to be actually useful :)

Compositor based transitions

Strip modifiers work on a single strip, and they alter the image produced by it. &ldquo;Effects&rdquo;, on the other<br>hand, can have multiple strips as inputs, and produce an image based on the inputs and often some sort<br>of &ldquo;time factor&rdquo;. The most common case is transition effects: two inputs, and a 0..1 range number indicating<br>how far into the transition we are. Blender had only very simple built-in transition strips: &ldquo;cross fade&rdquo;<br>and &ldquo;wipe&rdquo;.

Now, starting with 5.2, you can have compositor based effects<br>(PR #150694), and one could implement a ton<br>of custom transitions.

Transitions are perhaps the most common, but you can also have effect strips that do not have any inputs, and just generate an image<br>completely procedurally. This would be useful for any sorts of noise, patterns or other procedural textures.

Custom inputs for compositor based modifiers & effects

While having a node tree to drive a modifier or effect is nice and very flexible, it is of limited use if you<br>need to hardcode every tweakable parameter directly in the node tree. It would be way more useful if you<br>could prepare a node tree once, turn it into an asset, and expose whatever parameters a user might want<br>to tweak as custom inputs. Right? Right.

So that&rsquo;s what Falk implemented for compositor modifiers in Blender 5.2 (PR #156706),<br>and I did the same for compositor effects in upcoming 5.3 (PR #161026).

More performance around compositor

The initial implementation of compositor modifiers in 5.0 was always using the CPU based compositor. This works,<br>but is not the fastest way of doing large amounts of pixel operations :) And so I spent some time improving various<br>aspects of it:

The obvious one is, let it use the GPU compositor, when the user has selected the GPU compositor (the GPU compositor has been<br>recently made the default option, by the way). PR #154629

While at it, also allow using half precision data across the GPU compositor. PR #154914

Do all colorspace conversions &ldquo;lazily&rdquo; (right before they are needed) across the whole VSE rendering stack. Previously,<br>some cases were doing too many &ldquo;back and forth&rdquo; conversions, especially when scene linear & display colorspaces are intermixed.<br>This helps compositor use cases (the compositor in Blender always uses scene linear space), but also cases like having sequences<br>of EXR images inside VSE, and so on. PR #156281

While at it, do compositor colorspace conversions on the GPU, when using the GPU compositor.<br>PR #156640

Automatically detect when the resulting image of a compositor modifier or strip is fully opaque. The initial implementation<br>used to be conservative, and assumed the result might contain transparency. Which also means that visual strips<br>that are fully beneath the current strip could not be &ldquo;culled away&rdquo;, since we did not know if the strip is fully<br>opaque or not. Not anymore! Now it detects any non-opaque-alpha presence (via parallel reduction) and properly<br>marks the result as opaque or not. PR #158600

Did various optimizations for Mask strips. PR #155853,<br>PR #156518, PR #156622.

There&rsquo;s still more things to do on the performance front. The most obvious ones being: 1) more of the whole VSE rendering stack being able to use the GPU,<br>and 2) hardware accelerated video encoding/decoding. These (and more) are on the 2026 roadmap,<br>but given how fast time seems to be going, we&rsquo;ll see how much will actually get implemented this year.

More thumbnails for more things

Image, Movie and Sound strips already had thumbnails, but some other strip types did not. One of the unique features of Blender VSE<br>is that you can directly use other scenes as strips in your timeline, without first rendering them to a video or image sequence.<br>This seems to be used all the time at Blender Studio for storyboarding, for example. Alas, scene<br>strips did not have thumbnails. Well, they will in Blender 5.3 (PR #160322)!

Text, Mask and MovieClip strips also learned how to have thumbnails (PR #151042).

Reduce frame drops around video...