[mythtv-users] New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source

[Paul Gardiner]

Tom Dexter wrote:
> On Fri, Apr 10, 2009 at 1:52 PM, Tom Dexter <digitalaudiorock at gmail.com> wrote:
>> On Sun, Mar 29, 2009 at 2:58 PM, Paul Gardiner <lists at glidos.net> wrote:
>>
>>> I think I've just sussed what is causing this. The deinterlacer gets
>>> given each frame twice. Each time it overwrites the bottom field,
>>> but leaves the top field unchanged. After each call the OSD will
>>> be rendered over the frame. The fact that I don't update the
>>> top field in the second call to the deinterlacer means the OSD gets
>>> rendered over the top of a previous rendering. That doesn't matter
>>> for a solid OSD, but if translucent the top field will be
>>> darker than the bottom.
>>>
>>> Should be easy to fix:
>>>
>>> Change
>>>
>>>   if (y & tff)
>>>   {
>>>       if(parity)
>>>       {
>>>           /* Second call: put back the second field to its previous state */
>>>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_c][i][y*refs], w);
>>>       }
>>>       else
>>>       {
>>>           /* First call: replace second field by that of the previous frame
>>> */
>>>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_p][i][y*refs], w);
>>>       }
>>>   }
>>>
>>> to
>>>   if(parity)
>>>   {
>>>       /* Second call: put back the whole frame to its previous state.
>>>        * Although we have not altered first field, we need to overwrite
>>>        * it because the OSD will have been rendered to the copy passed
>>>        * in. */
>>>       memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_c][i][y*refs], w);
>>>   }
>>>   else
>>>   {
>>>       /* First call: replace second field by that of the previous frame */
>>>       if (y & tff)
>>>       {
>>>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_p][i][y*refs], w);
>>>       }
>>>   }
>>>
>> Paul...a quick question about this OSD flicker fix.  Can you think of
>> any reason that this fix could affect overall clarity of 1080i in any
>> way?  I'm probably just getting cross-eyed from all this testing :D,
>> but I almost thought the version without this fix may have been
>> slightly clearer.  It's too bad I have no way to test one right after
>> the other...I can only switch after a one hour re-compile.
>>
>> Just curious.  If there is in fact any difference it's extremely
>> subtle, and may be only with those NBC shows.
>>
>> Tom
>>
> 
> Never mind on that one.  After watching several shows in proper
> lighting etc (using the original patch with the OSD flicker fix but
> not the bottom-field-first fix), everything looks really
> spectacular...even the Law and Order SVU that was one of the problem
> recordings.
> 
> That bottom-field-first change, for whatever reason, really was
> causing problems with those NBC shows.

Thanks. That's useful to know. Not sure of the solution. Theoretically
the bottom-field-first change is an improvement, and certain types
of content would not display correctly without it. Funny isn't it?!
I used the test "y & tff" in my version by mistake. I always intended
Mark's logic. Lucky mistake in this instance!

One more version worth trying if you at some stage have the time:

where you replaced

    ((y ^ tff) & 1) == 0

by

    y & tff

could you try

    (y & 1) != 0

?


First version is "apply algorithm correctly for all frame types"

Second is "apply algorithm only for top-field-first frames"

Third is "always apply algorithm, but assume top-field-first
even if flag says otherwise"

Cheers,
	Paul.