[Bf-committers] S-DNA and Changes

[Peter Schlaile]

Hi Leo,

> Then you can have one strip with an fcurve to map from VSE output frames
> to scene frames:
>
> Strip 1: Scene, frames 1-20, with an fcurve that maps from VSE frames
> (iterated over using next()) to scene frames. It covers frames 1-219 in
> the VSE.
>
> If I may modify your code a little:
>
> class scene_iterator : public iterator {
> public:
> 	Frame next () {
>                // fcurves go in map_vse_frame_to_cfra
>                float cfra = map_vse_frame_to_cfra (nextFrame);
> 		setup_render(cfra);
>                ++nextFrame;
> 		return render();
> 	}
>    int nextFrame;
> }

and again, that doesn't work with fcurves and gets really nasty 
with stacked speed effects.

map_vse_frame_to_cfra() is *really* a non-trivial function!

> VSE only sees a sequence of discrete frames

uhm, why is that exactly the case? In fact, currently it renders 
internally with floats.

> - which is precisely what its domain model should look like,
> because video editing is about time-discrete sequences, not continuous.

again, why? The point behind making cfra continous was, that the *input* 
strip can make it's best afford to do inter-frame interpolation or do 
in-between rendering.

It depends heavily on the *input* strip, how that is done best.

So: no, I *strongly* disagree with your opinion, that the "VSE sees a 
sequence of discrete frames". In fact, it doesn't!

> The Blender scene is a  continuous simulation - having a float cfra 
> makes sense, because time is continuous there. In the VSE the domain 
> objects are discrete in time. Having a float cfra makes no sense.

as stated above, I disagree.

>> Which brings me to the point: what was the sense in dropping the random
>> access interface again?
>>
>> The imbuf reader has also a random access interface, but internally keeps
>> track of the last fetched frame and only reseeks on demand.
>
> It is always possible to wrap a sequential interface in a random-access
> interface, or vice versa. The purpose of dropping the random access
> interface was to be able to write code that didn't have to deal with two
> cases - you'd know that you'll always be expected to produce the next
> frame, and can code for that. Less to write, less to go wrong.

uhm, you always will need a fetch() and a seek() function, so where 
exactly does your idea make things simpler?

> Clients of the code know that they can iterate over *every* frame in the
> sequence just by calling next(). With a random access interface -
> especially one that uses floats for indexing - you'll always worry if
> you missed a frame, or got a duplicate, thanks to rounding errors.

uhm, as stated above, next() isn't really defined in your sense.

You can define a version, that does CFRA + 1 if you like. If that is 
really helpfull is another question.

In fact, the next cfra for a given track will be defined by the topmost 
speed effect fcurve and then calculated down the stack. That won't break 
your initial idea of changing the order in which frame calculation takes 
place, it only reflects the fact, that next() isn't that easy to calculate 
if you do retiming in a creative way.

So: yes, next() won't be easy to calculate in advance for a given track, 
but yes: that is a fundamental problem, if we allow stacked retiming with 
curves. Even if you do retiming with simple factors, you will run into the 
problem, that if the user speeds up a track with say a factor of 100 you 
probably don't want to blend *all* input frames into the output frame but 
limit the sampling to say 10 inbetween frames. (That's the way Blender 
2.49 does it and Blender 2.5 will do it soon using the new SeqRenderData 
parameters.)

Cheers,
Peter

----
Peter Schlaile