Re: Deinterlacing proposal

Bj|rn Englund wrote:

> > It's not only better than nothing. It's probably the fastest mode
> > possible, as there is no extra load on the CPU for deinterlacing. So I
> > think this should be kept as "Fast deinterlacing".
>
> Yes, I agree.

I'll try to make a final form, based on your patch and subsequent discussion, 
today.

> > int deinterlace_init (int x, int y, int d_mode);    this will be the init
> > procedure; x and y show the image size; d_mode is the "deinterlace mode"
> > which the user will be able to define in the config fle, but in early
> > versions just hardcode this to 0. Returns 0 if initialization has failed,
> > 1 on success.
>
> Keep in mind that the size of the picture can change at any time
> so make it easy to reinit.

OK, a new call to this function will reinit flawlessly. But the buffered 
images will be flushed at the moment, so they have to be retrieved and shown 
before the reinit. More on that below.

> And the deinterlace mode should also be possible to change on the fly,
> either from a user override, or from information from the mpeg decoder.

The user mode is just that - user mode. MPEG information should be another 
parameter. (This is because different user modes can use the information in 
different ways).

> Each picture has flags that tells if it is a progressive or an interlaced
> picture. 

Could you tell me more on these flags? (Or point me to a doc?) I have heard 
somewhere that they also show if it's really interlaced or telecined, and if 
telecined, they mark some frames specially. If you can provide these flags in 
a nice struct, this would be helpful.

But the user mode should only ever be modified by the user.

> So for each picture that comes from the mpeg decoder I call
> deinterlace_frame() and then directly deinterlace_frame_frombuf() which
> might return
> a picture or not. 

I had a different idea in mind, but yours has mich merit (and besides may 
allow the use of some code from mplayer).

I'll spend more time thinking of the API details. Here are the points that we 
have to consider together:

- When frame N is put into the deinterlacer, you immediately get back frame 
N-LAG. But what if playback is stopped/changed (paused, or the film ends, or 
the size changes)? In this case, ogle needs to retrieve and play back the 
lagged frames before stopping the playback, or before reiniting the 
deinterlacer. I thought it would just call deinterlace_frame_frombuf() until 
that returns 0 (no more pictures).

- As the thing is to be CPU intensive, we need graceful degradation if it 
takes too long and misses the timestamp. The natural solution is to drop 
frames, but somehow we need to inform the deinterlacer that frames were 
dropped before this one (this affects the inverse telecine case). 

> Can I call deinterlace_frame several times to buffer up pictures
> before frombuf is called or only one time per frombuf?

This is probably something to consider, but you'll need to check the return 
value to see if the buffers are full. I'll not allocate buffers for every 
call, this would be too slow.

>Also as a note, input frames mustn't be changed, only read from,
> because they are used for prediction if they are I or P pictures.
> If the input is a B picture you may change the data, this might reduce
> the need for copying data in some cases perhaps.

Oops, this was important. My previous idea did not take this into account. 
Thanks.

> Yes, they might need some small changes to handle the timestamps.

OK, so what is the timestamp format? Is there already a type for the 
timestamp, so it can be passed with every frame?

> > If so, I can send you stub deinterlace.h and deinterlace.c files .
> > Unfortunately I don't understand autotools, so I'll have to ask you to
> > include them in the build process. (This can be a one-time custom version
> > if you don't want the unfinished stuff in CVS; I just need to be able to
> > compile it all). After that I'll be able to work on the deinterlace code.
>
> 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).

-- 
Yours, Mikhail Ramendik