[MPlayer-dev-eng] [PATCH] new video filter : vf_deflicker

[alexandre]

On 16/05/2010 12:37, Reimar Döffinger wrote:

> IMO just use
> if (!vf->priv->buffer) instead of requiring a state.

> A
> if (vf->priv->nFrames<  vf->priv->wSz) { // buffer fill-in
> } else {
> ...
> }
>
> Seems more obvious to me.
>

Fixed.

> This scales horrible with wSz (which btw. is not a good variable name).
> First, you should be using a ring-buffer so you don't have to move the
> data around on each new frame, and secondly if you keep the means buffer
> unscaled by wSz you can just subtract the values of each frame when
> it leaves the buffer and add the values of the new frame when it comes in.
> Since in a ring-buffer the "incoming" frame will be at the same location
> as the "outgoing" one that also should be quite cache-friendly and cut
> down on address calculations.

Fixed, thanks for the suggestion.

> There's a memcpy_pic copy function that does the stride handling that
> you should probably use.

Fixed.

> Also I think the whole desing would be much nicer if this filter just
> calculated some adjustment values and then passed this on to another
> filter or even directly to the vo.
> Of course this only works well if we have a filter that does the right
> adjustment, haven't checked what exactly you do, but basically you'd
> have to settle with only doing a simple brightness+contrast adjustment
> (where supported gamma would be possible, too).

My luma correction is neither linear nor power, and may not fit in the 
simple adjustement framework you are talking about, if I understood 
correctly.

A
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vfdeflicker.txt
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100516/b62be1de/attachment.txt>