[vlc-devel] [PATCH] Phosphor deinterlacer, reworked++

[Juha Jeronen]

Hi again,

I'm working on updating the patch.

Two semi-obvious things about the dimmer that I missed yesterday:

1) In the uint8 format for YUV, black is at (0, 128, 128).

This means that luma and chroma need different handling. Vectorization
of the chroma requires MMX (or similar), since the operation is more
complicated than a shift + bitwise AND.

This is not a serious problem, but it makes the dimmer function more
complicated than the original was.

2) With 4:2:0 chroma, it is impossible to change the chroma of just one
field. For 4:2:2, it is possible to dim one field only for the chroma, too.

Thus, at the very least we need to handle 4:2:2 and 4:2:0 input
differently. For 4:2:0, the original solution (dim luma only) is the
best that can be done, since both fields have the same chroma. For U
and/or V far away from the center, this will distort colours in the dark
field if the dimmer strength is high.

At this point, the complicating issue of what to do with 4:2:0 input
rears its head again. For this function to become a general-use helper,
both "upconvert" and "ignore" modes would be needed. (Upconvert: produce
4:2:2 output, first copying the original chroma into both fields and
then dimming one field. Ignore: dim luma only, and copy chroma planes
as-is.)

Another viewpoint is whether anything but Phosphor will ever need a
field dimmer. Probably not. In this case, we can assume that the
function is only fed stuff from ComposeFrame(). Note that when requested
to, ComposeFrame() will upconvert even if both fields come from the same
frame. This is handy.

In this design, we can rely on ComposeFrame() to do the upconversion if
needed. Then, the dimmer needs only two modes: process all planes for
4:2:2 (luma and chroma differently!), and ignore chroma for 4:2:0.

I'm going with this second design for now.

Updated patch probably tomorrow night.

 -J


On 03/01/2011 03:00 PM, Juha Jeronen wrote:
> Hi again,
>
> On 02/28/11 23:10, Laurent Aimar wrote:
>>  By the way, why not doing the same processing for the luma and chroma?
> Now that you asked, just after posting the previous message I'm no
> longer sure that the filter does the right thing.
>
> Maybe all planes should be processed, after all, since black maps to the
> origin. I'll try this out, and keep the version that produces
> better-looking output.
>
> Thanks for asking :)
>
>  -J
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel