Re: Deinterlacing proposal

I wrote:

> > Maybe we should make a branch in CVS?
>
> Would be OK, but will later merging be easy enough? The main code (not the
> deinterlacer itself) will need to include, apart from the calls, a way to
> configure deinterlacing (switch key, fast/slow [fast is the Xv patch],
> default user deinterlacing mode [just an int for now], whether
> deinterlacing is on or off at startup).

On second thought, while the deinterlacer is in development, most of this is 
not needed. Just a fixed key to turn slow deint on/off, and another key to 
turn fast deint on/off. (Fast should probably go into HEAD soon enough 
anyway). Startup deint on/off can be hardcoded. 

But the user deinterlace mode (the int value) has to be changeable, 
preferrably from the command line; recompiling each time I want to try a 
different mode would be a serious hassle. 

So yes, a branch with the version that calls the deinterlacer (and the 
deinterlacer itself of course) is probably a good solution. Configuration can 
be handled at the time deint works stable enough to go into HEAD. As soon as 
we work out the APIs, I'll send you the stub deinterlacer.h/.c files for 
inclusion into that branch

-- 
Yours, Mikhail Ramendik