Dear All, right now we are working toward a 2.5 release, and I am very aware of the fact that we have to get things out the door. "Real artists ship" and all that. I just want to share some thoughts on the future of the VSE, post-2.5. I apologize if these thoughts have been brought up earlier and been shot down.
I've used Blender for video editing for about a year, and I find it to be clearly superior to any other solution. In parallel with using Blender I have developed my own little suite of video editing tools (timelapse, anti-shake, motion interpolation, etc.), and lately I have started to think about putting these tools into Blender. I found them useful, so I'm assuming others will, too. Looking at the code for the VSE it appears solid, but not very modular, nor suitable for effects that need access to more than the current frame. Since the tools I have fall into that category – the anti-shake, for example, needs to compute the optical flow for each pair of frames – it is currently near-impossible to port them over in a way that would give a good user experience or remain modular enough to be maintainable. Per-Strip Rendering ------------------- Looking at the code, it looks to me that the assumption is that: a movie is a sequence of frames that can be rendered independently. In other words, a movie is a sequence of stills. At first sight, this seems correct – after all, a movie is a sequence of still images. But it ignores the fact that these frames are highly related to each other. It isn't just a random list of pictures. I think that the VSE's architecture must include that must more: We are not operating on independent images, we're operating on sequences. Right now, the VSE works like this: For each frame, it renders all strips at that frame, taking inter-strip dependencies into consideration, then composites the frames. What if we turned that around? Render all frames of all strips to a temporary space, then composite them. That is: for each frame: for each strip: render composite gets turned into: for each strip: for each frame: render composite This way, we could do frame rate conversion naturally. We could do speedup/slowdown, interpolation, anti-shake, and everything easily. Effects that only require access to the current frame would still work as a kernel inside a strip. Render Farm Issues ------------------ An entire strip is too big of an object. Consider, for example, a Scene strip. If we have a render farm, we want to split the rendering of that strip over the nodes in the farm. Any Strip abstraction would have to include the ability to only render a part of itself. If each strip could signal the minimum recommended chunk size, the VSE could ensure that the strip is split according to that. A rendered scene would have a chunk size of 1 – that is, each frame can be rendered independently. A frame rate conversion could have a variable chunk size depending on the rate difference. Next Steps ---------- For now, I just want to know if I'm completely wrong, retreading old ground, or if there is enough merit in this to warrant further experimentation, once 2.5 is out. I'll do all development on my own, so unless I'm successful, you probably won't hear a thing. /LS _______________________________________________ Bf-committers mailing list Bfemail@example.com http://lists.blender.org/mailman/listinfo/bf-committers