[Bf-committers] Large sequencer cleanup

[James Ruan]

HI Peter!
It's very good to hear about the improvement about sequencer code.
This part of blender is what I use mostly, sequencing and color
correction. And I find the speed effect is working less unintended.

What I hope to be integrated into the speed effect is not just frame
blending
(It's better than none, of course, but not that perfect), but a method to
estimate the missing frames after speed change from the known frames by
applying the calculation of optical flow.

Here is an introduction about the technique:
http://www.fxguide.com/article333.html
That is how the bullet time in The Matrix is made. And if that method can be
applied
to Blender, we would be able to create such a 'bullet time'.

And I did some search on the algorithm and find this:
 http://www.cs.toronto.edu/~fleet/research/Papers/ijcv-94.pdf
We need algorithm which can produce a 100% dense optical flow results with
higher
accuracy and the modified version of Horn and Schunck serves that well.
Since we can't do the frame blending in real time, why not do some thing
 grater that takes more time?

And something about the hash function in your patch.
I think this hash algorithm doesn't distributes well, there might be a high
rate of hash collision. Because the value of key->seq varies mostly on LSBs
while the key->cfra also varies mostly on LSBs. Maybe a left shift of either
 one would make the MSBs varies more thus make the hash better.

Regards,
2010/7/23 neXyon <nexyon at gmail.com>

>  Hi Peter!
>
> I haven't tried out your patch yet, but the improvements sound really
> nice! The sequencer definitely needs some love.
>
> About the grandma understanding the code, there's one thing that's
> pretty confusing: all that startofs, anim_startofs, startdisp,
> startstill attributes, all with end instead of start also and length and
> so on. So it would be nice to drop some (most) of these attributes from
> the structs to the least minimum and calculate the dropped ones on the
> fly (as far as I have noticed calc_sequence and calc_sequence_display
> are called so often that the attributes can definitely be calculated
> when they're needed without getting a real performance loss). And then
> it would be nice to have a clear documentation what value/function
> returns what at some place (wiki?).
>
> As part of that recode of cfra to float I wonder if it would be better
> to change cfra to a time value that holds seconds? I guess that's a
> general discussion topic that can even be considered for the whole
> blender code. Well it's just a quick idea, I have no clue what problems
> could arise from that.
>
> One more thing is if you could have a look at the drawseqwave function
> in sequencer_draw.c, you see there that sound_read_sound_buffer is
> called and everytime a quite huge buffer is alloced and freed again.
> Although that's only done for sounds where the raw PCM samples are
> already loaded into RAM it's quite slow and makes it nearly impossible
> to use with even one music strip of 3 minutes length, so I wondered if
> you would be as kind as to add a caching mechanism here too.
>
> Regards,
> neXyon
>
> > Hi,
> >
> > the last three days, I cleaned up / rewrote large parts of the sequencer
> > code, to accomplish the following things:
> >
> > * make cfra a float internally to enable sub-frame precision rendering
> >     with speed effects and make the code a lot clearer
> > * remove the whole TStripelem mumbo jumbo (is necessary, since cfra is a
> >     float now, right?)
> > * replacing it with a hashtable based caching system
> > * thereby dropping memory usage of the sequencer to a fraction of it's
> >     current usage (80 MB without using any caches to approximately 5 MB
> on
> >     a 3 hour timeline)
> > * thereby making the cache limitor drop the full imbufs (no more clicking
> >     on refresh from time to time anymore)
> > * thereby make cutting a lot snappier, since freeing up the imbufs is
> just
> >     about dropping the contents of the current hashtable and not
> traversing
> >     really large arrays of null pointers...
> > * prepare the code for multi-core usage (threaded rendering is disabled
> >     right now, but the old code was limited to two cores anyways, because
> of
> >     this TStripElem hell)
> > * and: make the code so easy to understand, that your grandma will get
> >     hold of it (hopefully)
> >
> > I did some test editing, nothing crashes, no memory leaks, everything
> > seems happy, but: can I commit or should I wait some days to let Blender
> > 2.53 settle?
> >
> > Patch is here for reference:
> > http://peter.schlaile.de/blender/seq_cache_rewrite.diff
> >
> > Only thing missing is frame blending in Movie and Image strips on speed
> > effect input (which is still largely broken, so most people won't really
> > notice...)
> >
> > This will come back shortly as an option for Movie and Image strips.
> > (Which will be able to adapt to different frame rates directly for free
> > on the way, since, cfra is now a float :) ...)
> >
> > Cheers,
> > Peter
> >
> > ----
> > Peter Schlaile
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
James Ruan