sequencer improvements: opengl scene strips

I am osx and it blinks and does all kinds of strange things.

here:
https://projects.blender.org/tracker/?func=detail&aid=21578&group_id=9&atid=498

hi, Ill try get around to looking into the bugs this week,

thanks ideasman42 - you are a gem!

What I was suggesting was being able to import strips through the VSE, pipe certain frame sequences through different node groups and get the result in the timeline and/or use a node group as a generator of an effect, then apply that above a strip in the VSE but not be limited to one ‘Render Result’ per scene. :slight_smile:

How would I go about doing a colour hold on a section a strip in the VSE or a fake shallow DOF etc etc without coded VSE plugins? Feed the video in through a noodle in one scene then onto the VSE, painful for lots of clips and only certain frame sequences and frame sequences that may change, painful because it’s not fluent.

Being able to cook up node groups as generators and filters, which could be stored in a separate library blend even and linked in for a project when needed onto the VSE would be good I think.

With 2.5 once a video or image sequence is in the blend it’s available anywhere it can be used, so in theory shouldn’t it be quite easy to assign a node group to a VSE strip and blender be able to pipe that sequence in and out of the node group behind the scenes.

Wiith a linked node group we’d not even have to connect it up in the node editor, blender knows it exists, it has an input and an output, we’d be using the node editor initially maybe in the library blend file as a visual filter/plugin editor like GraphEdit. Without coding in C.

Some of the node group parameters could be exposed in the VSE N Key panel to control each instance of a certain node group on a certain strip.

Result would be ability to visually create simple VSE plugins rather than code in C and be able to reuse those node groups multiple times with different parameters and different video strips rather than a rats nest of a node tree or multiple scenes of node editors. The linked node groups wouldn’t even need connecting up in the node editor.

One last VSE thought. :slight_smile: I use the vfapi (on linux compiled with mingw) feature to frame serve out to various encoders but what would be involved making blender except feeds from frameservers like AVISynth, VirtualDub, DGIndex, DGAIndex etc they all offer vfapi I think, so there would be the ability to assign a frameserver ‘node’ / ‘plugin’ to a VSE strip pipe it out to AVISynth and back to blender’s VSE strip above the feed so as to multiply or alpha over etc. The vfapi works on Linux as well as windows and AVISynth / VirtualDub work well (but not multithreaded) via wine.

Wow!!!
I just tried this out and It is awesome.Just made a lot of work easier.
Thanks Devs.

Yellow, cool proposal :slight_smile: , no field render for nodes tho’:frowning: sad for me stuck in the dark ages.

@ yellow

Yeah, another simpel but very powerful addition to Blender would be if they would use an Avisynth enabled Ffmpeg when they make the Blender builds, so Avisynth scripts could be imported into the sequencer.

My Open GL preview dies from time to time, but here is an example of the coolness of VSE these days.
http://blenderartists.org/forum/showthread.php?p=1592838#post1592838

a quick demo of VSE as a 2D simple compositor, 2 cameras 1 scene!

Windows only regarding compiling ffmpeg with AVISynth due to dependencies on certain windows libraries I think.

The damage is already done regarding video into blender as blender appears to be convert video to RGB on import, with arbitrary luma scaling 16-235 and a not so good conversion.

AVISynth would only kick in after that. I prefer to use AVISynth before video gets near blender and convert to RGB nicely first.

I’ve asked on Graphicall to see if anyone would do ffmpeg with .avs support. Enabling AVISynth would be good but I still think you’d be limited to RGB filters unless you do conversions to YV12 / YUY2 but then as soon as you apply a blender filter / colour balance etc I’d assume blender converts it back to RGB, and not too well and so on back and forth.

Yes, Avisynth is Windows only(so far). There was an Avisynth enablede FFmpeg+Blender build some time ago:

And an older one:

And a thread on those builds:
http://www.blender.org/forum/viewtopic.php?t=13019&highlight=&sid=a27185a9ca41d3e6566aeba7f3c42c68

@tin2tin

So far but been waiting along time for v3. :slight_smile:

I use it very happily on Linux with Wine though, can’t seem to get the multithreaded build working though, guess Wines not multithreaded.

Yes, remember seeing you on those threads, gave them a go at the time, thinking about it, that’s when I started using AVISynth. :slight_smile:

Now blender has moved away from a custom FFMPEG and making blender compile with system one instead, which I always had difficulty with, in fact still do as there’s a problem with scons + 2.5 + FFMPEG (localised build) then it should be easier for builders to use a custom ffmpeg I guess.

Hopefully new builds will appear.

Yellow, as an Ot I notice that the Canon codecs for the DSLRs they make, have issues when routing thru’ Quicktime. Apparently it also does a bad job of colou space conversion for exports too. So it seems that Blender is in good company (for bad bugs).

3point, here’s a couple of interesting links that might relate:

Then after further investigation the author corrects some of the conclusions:

Do you have a link to the Canon codec issues?

So the sequencer camera switcher is going to change the compositor camera or are we going to end up also having a override in the compositor also? This seems like it’s going to get messy. :confused:

There must be a elegant way we could just make setting the active camera object animate-able in the 3D view instead (which would also allow us to interpolate between them). Or maybe a special Timeline marker for camera switching?

There are several scripts that already achieve this horrible horrible way of working. You can still use them if you want.

The idea behind this feature is twofold:

  1. the openGL preview part makes scene strips in the VSE actually usuable in real time, instead of having blender try to render every frame as you drag the time slider.
  2. for previz, to make it easier to set up sequences in a non linear environment.

Shortly after posting I realised animating the active camera object wasn’t really a option.

Indeed and it’s awesome. I’m only thinking about the camera override that needs to integrate with the compositor/render-layers. I just wanted to brainstorm with the community to see if we could come up with something more elegant/flexible/usable.

There must be a elegant way we could just make setting the active camera object animate-able in the 3D view instead (which would also allow us to interpolate between them). Or maybe a special Timeline marker for camera switching?
Have you seen this way of using markes for camera swiching?
http://www.youtube.com/watch?v=kq0wtgekSyA

I guess when the API is ready it would be possible to code up some script to convert back and forth between the two metods.

Nope I hadn’t, seems ideasman has already thought about this quite a bit.

looked into fixing rendering opengl view but this and its not so simple,
opengl cant be called within a thread, so Ill need to figure out a way to have it stay threaded but let opengl be called outside the thread.

Its a real shame as I find that the GL render fails quite often in recent builds, but its got me sucked in! I went back to 2.49 to lay out some VSE stuff because it was driving me mad. I soon relented and headed back to 2.5, it was like driving a scooter!