[Bf-committers] S-DNA and Changes

[Peter Schlaile]

Hi Leo,

> Ah, ok.
>
> I'd still try to stick with integer frames and a parameterless next().
> Allowing the client to specify the advance in the next() method makes it
> too much of a random-access method (there is no guarantee that the
> advance is to the "next frame", which is the whole purpose of the
> iterator interface).
>
> I'd do it this way:
>
> Suppose we have a scene where we want normal speed for frames 1-10, an
> extreme slowdown for 11-12 and normal speed from 13-20.
>
> Strip 1: Scene, frames 1-10. This strip covers frames 1-10 in the VSE.
> Strip 2: Scene, frames 11-12, with a framerate of 1/100th of the output
> framerate. This strip covers frames 11-211 in the VSE.
> Strip 3: Scene, frames 13-20. This strip covers frames 212-219 in the VSE.

sorry, that won't work. One can retime using fcurves. 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.

So you get: fast output, if you fetch the next frame and a slow reseek if 
you don't, which will work nicely in all relevant cases, since your code 
will be optimized to work on consecutive frames as much as it can.

Cheers,
Peter

Just do it internally like this on a movie strip which has a fixed 
framerate:

class movie_iterator : public iterator {
public:
 	Frame fetch(float cfra) {
 		if (cfra == last_cfra + 1) {
 			return next();
 		}

 		seek(cfra - preseek);

 		for (int i = 0; i < preseek; i++) {
 			next();
 		}

 		return next();
 	}
private:
 	Frame next() {
 		return next_frame using and updating last_frame_context;
 	}
 	void seek(float cfra) {
 		...
 	}

 	float last_cfra;
 	context last_frame_context;
}

where as a scene strip does:

class scene_iterator : public iterator {
public:
 	Frame fetch(float cfra) {
 		setup_render(cfra);
 		return render();
 	}
}


----
Peter Schlaile